lkml.org 
[lkml]   [2021]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] firmware: export x86_64 platform flash bios region via sysfs
Am Do., 11. Nov. 2021 um 16:31 Uhr schrieb Andy Shevchenko
<andy.shevchenko@gmail.com>:
>
> On Thu, Nov 11, 2021 at 4:33 PM Hans-Gert Dahmen
> <hans-gert.dahmen@immu.ne> wrote:
> > Am Do., 11. Nov. 2021 um 14:55 Uhr schrieb Andy Shevchenko
> > <andy.shevchenko@gmail.com>:
> > > On Thu, Nov 11, 2021 at 2:56 PM Hans-Gert Dahmen
> > > <hans-gert.dahmen@immu.ne> wrote:
> > > > Am Do., 11. Nov. 2021 um 13:46 Uhr schrieb Andy Shevchenko
> > > > <andy.shevchenko@gmail.com>:
> > > > > On Thu, Nov 11, 2021 at 1:46 PM Richard Hughes <hughsient@gmail.com> wrote:
> > > > > > On Thu, 11 Nov 2021 at 10:33, Mika Westerberg
> > > > > > <mika.westerberg@linux.intel.com> wrote:
> > > > >
> > > > > > it's always going to work on x64 -- if the system firmware isn't available at that offset then the platform just isn't going to boot.
> > > > >
> > > > > Well, it's _usual_ case, but in general the assumption is simply
> > > > > incorrect. Btw, have you checked it on Coreboot enabled platforms?
> > > > > What about bare metal configurations where the bootloader provides
> > > > > services to the OS?
> > > >
> > > > No it is always the case. I suggest you go read your own Intel specs
> > > > and datasheets
> > >
> > > Point me out, please, chapters in SDM (I never really read it in full,
> > > it's kinda 10x Bible size). What x86 expects is 16 bytes at the end of
> > > 1Mb physical address space that the CPU runs at first.
> >
> > So you do not know what you are talking about, am I correct?
>
> Let me comment on this provocative question later, after some other
> comments first.
>
> > Starting
> > from 386 the first instruction is executed at 0xFFFFFFF0h. What you
> > are referring to is the 8086 reset vector and that was like 40 years
> > ago.
>
> True. The idea is the same, It has a reset vector standard for x86
> (which doesn't explicitly tell what is there). So, nothing new or
> different here.
>
> > Please refer to SDM volume 3A, chapter 9, section 9.1.4 "First
> > Instruction Executed", paragraph two. Just watch out for the hex
> > number train starting with FFFFF... then you will find it. This is
> > what requires the memory range to be mapped. Modern Intel CPUs require
> > larger portions, because of the ACM loading and XuCode and whatnot.
>
> Thanks. Have you read 9.7 and 9.8, btw?
> Where does it tell anything about memory to be mapped to a certain
> address, except the last up to 16 bytes?
>

It doesn't, except that the FIT, ACM, BootGuard, XuCode stuff rely on
their binaries to be there, this just sets the upper address limit of
the window.

> > Please refer to the email [1] from me linked below where I reference
> > all PCH datasheets of the x64 era to prove that 16MB are mapped
> > hard-wired. Note that the range cannot be turned off and will read
> > back 0xFF's if the PCH registers are configured to not be backed by
> > the actual SPI flash contents.
>
> And as I said it does not cover _all_ x86 designs (usual != all) .
> Have you heard about Intel MID line of SoCs? Do you know that they

No and a quick search didn't turn up anything. Can you point me to
resources about those SoCs? Also my module is targeting x86_64, that
is only a subset of x86 designs.

> have no SPI NOR and the firmware is located on eMMC? Do you know that
> they can run Linux?

It doesn't matter where the firmware is coming from, as long as it is
_mapped_. And something has to be mapped there, even if it is just a
loader that gets eMMC going.

>
> So, maybe it's you who do not know what you are talking about, am I correct?
>
> > [1] https://lkml.org/lkml/2021/6/24/379
>
> --
> With Best Regards,
> Andy Shevchenko

\
 
 \ /
  Last update: 2021-11-11 17:08    [W:0.140 / U:0.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site