<div dir="ltr">OK Ron,<div><br></div><div>I needed some time to reconcile my thoughts. So,as Aaron pointed, it is impossible to do any long mode paging in ROM stage.</div><div><br></div><div>And here we come to the Mystery of CB Organism (hmmmm... It is very close to some other term). ;-)</div><div><br></div><div>Now, here is how it will play for you and Coreboot, after ROM stage (I'll call it RON stage, since it is RAM stage, divided in two sections).</div><div><br></div><div>Why RON? Ready Or Not, that is the question!</div><div><br></div><div>So RON stage = RAM1 stage + RAM2 stage.</div><div><br></div><div>RAM1 stage: Since some RAM Physical mapping (AFTER CRB) MUST be done at the beginning of the RAM stage, lookalike BIOS one (in PEI phase, I assume), CB will proceed with the usual activities, set in Protected Mode. And, as we know so far how it works, it'll finish this phase, looking for Payload.</div><div><br></div><div>Now, instead of payload stage, here we go with the RAM2 stage. Now the CB will switch to the Long Mode (flat x86_64), addressing at maximum of 48 bits of the physically available CPU address memory bus - 256 TB of DDRAM memory (I'll drop here 64 bit PAE extension (additional 4 bits of physical address space), for clarity).</div><div><br></div><div>Here, you'll start initializing MMU, with 4 TLB tables: CR3 -> PML4 (512 entries) -> PDTP (512 entries) -> PDT (512 entries) -> PT (512 entries + last 12 bits freed for the MMU attributes). So, if your HW have in average 8GB of memory, you'll need ONLY 1 entry in PML4, 8 entries in PDTP -> and full tables for these 8 entries. I see that you'll do NOT a Virtualization, rather a logical address shift for the constant address offset. With proper init of the attributes in the PE tables, per 4KB page - your finest granularity).</div><div><br></div><div>And, YES, you'll have your memory protection in full swing (just for the de-referencing the NULL pointers), since you do NOT have more that one process working, in linear mode (so the bus error will appear ONLY for NULL pointers).</div><div><br></div><div>Now, after you've done this, what is the next step, somebody will ask?</div><div>[A] Reverting to Protected Mode prior Payload stage?</div><div>[B] Proceeding with the Long Mode passing thread of execution to payloads... Which need to operate in Long Mode!? Really???</div><div>[C] Reverting to Virtual x86 Mode???</div><div>[D] Reverting to Real Mode???</div><div><br></div><div>Seems that you will do scenario [A]. But if you choose to have payload as 64b Linux [B], then I see where you are pointing/going with this approach... To fast Server (?!) boot-ups, but you need to reconsider, since 64b Linux still will reconfigure MMU, doesn't it???</div><div><br></div><div>Or you would like to skip kernel MMU init while booting 64b kernel. Letting kernel to pick up (already) hot MMU, on fly?</div><div><br></div><div>As far, it'll be: Boot stage + ROM stage + RON stage (RAM1 stage in Protected Mode, + RAM2 stage in 64b Long Mode) + 64b kernel payload. Solely out of FLASH (smells as DOD MIL RT applications, drones, unmanned planes, missiles)... Interesting scenario, anyway!</div><div><br></div><div>(Mysteries of CB organisms) ;-)</div><div><br></div><div>Zoran</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 2, 2017 at 9:45 PM, ron minnich <span dir="ltr"><<a href="mailto:rminnich@gmail.com" target="_blank">rminnich@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">right, Aaron, you keep reminding me of that and I keep forgetting it :-)<div><br></div><div>so, ok, ramstage it is for paging. The x86 is so darned annoying. We had paging in the bootblock for PPC on linuxbios.</div></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 2, 2017 at 12:43 PM Aaron Durbin <<a href="mailto:adurbin@google.com" target="_blank">adurbin@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Aug 2, 2017 at 1:36 PM, ron minnich <<a href="mailto:rminnich@gmail.com" target="_blank">rminnich@gmail.com</a>> wrote:<br>
><br>
><br>
> On Wed, Aug 2, 2017 at 12:08 PM Zoran Stojsavljevic<br>
> <<a href="mailto:zoran.stojsavljevic@gmail.com" target="_blank">zoran.stojsavljevic@gmail.com</a><wbr>> wrote:<br>
>><br>
>><br>
>><br>
>> So, turning on the Virtual Mode (paging ON), you'll also imply that<br>
>> Coreboot will initialize and use MMU, don't you?<br>
><br>
><br>
> sure.<br>
><br>
>><br>
>><br>
>> Am I correct, or you can use paging without MMU?!<br>
><br>
><br>
> MMU must be on.<br>
><br>
>><br>
>> I doubt that, perhaps. So, then, I would like to see this code in Coreboot<br>
>> where MMU is initialized. And how it is initialized (maybe there is a some<br>
>> over-simplified mode of operation using 2MB pages).<br>
><br>
><br>
> yep.<br>
><br>
>><br>
>><br>
>> And my question is: what for? Or I did not get the idea... Who really<br>
>> needs to use paging in boot-loaders? Even INTEL, which (on purpose) makes<br>
>> things way over-dimensioned and over-complicated, does NOT use paging in<br>
>> UEFI BIOSes, so far???<br>
>><br>
><br>
> it's trivial to turn on paging. In harvey I've got it down to 160 lines,<br>
> including comments and white space. I made it much more compact in my CL<br>
> from 1/2014.<br>
><br>
> If you turn on paging you can capture null pointer derefs, and all other out<br>
> of range address references. And relocatable modules are much easier..<br>
><br>
> My question is, why not do it? I don't see any harm. All the other platforms<br>
> in coreboot use paging. What's so special about x86 that it should not use<br>
> paging?<br>
<br>
You can't use it for CAR so that sorta throws out romstage and before.<br>
It's up to the implementation of how CAR works within the hierarchy,<br>
but with hardware page walkers that pull things through the cache<br>
things can go badly. So then you could enable paging for ramstage.<br>
Need to locate storage for the page tables, but that's not an<br>
impossible thing either.<br>
<br>
><br>
> ron<br>
><br>
> --<br>
> coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>
> <a href="https://mail.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://mail.coreboot.org/<wbr>mailman/listinfo/coreboot</a><br>
</blockquote></div>
</div></div></blockquote></div><br></div>