Am Do., 11. Nov. 2021 um 16:31 Uhr schrieb Andy Shevchenko <andy.shevchenko@xxxxxxxxx>: > > On Thu, Nov 11, 2021 at 4:33 PM Hans-Gert Dahmen > <hans-gert.dahmen@xxxxxxx> wrote: > > Am Do., 11. Nov. 2021 um 14:55 Uhr schrieb Andy Shevchenko > > <andy.shevchenko@xxxxxxxxx>: > > > On Thu, Nov 11, 2021 at 2:56 PM Hans-Gert Dahmen > > > <hans-gert.dahmen@xxxxxxx> wrote: > > > > Am Do., 11. Nov. 2021 um 13:46 Uhr schrieb Andy Shevchenko > > > > <andy.shevchenko@xxxxxxxxx>: > > > > > On Thu, Nov 11, 2021 at 1:46 PM Richard Hughes <hughsient@xxxxxxxxx> wrote: > > > > > > On Thu, 11 Nov 2021 at 10:33, Mika Westerberg > > > > > > <mika.westerberg@xxxxxxxxxxxxxxx> 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
