OK Ron,
I needed some time to reconcile my thoughts. So,as Aaron pointed, it is impossible to do any long mode paging in ROM stage.
And here we come to the Mystery of CB Organism (hmmmm... It is very close to some other term). ;-)
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).
Why RON? Ready Or Not, that is the question!
So RON stage = RAM1 stage + RAM2 stage.
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.
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).
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).
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).
Now, after you've done this, what is the next step, somebody will ask? [A] Reverting to Protected Mode prior Payload stage? [B] Proceeding with the Long Mode passing thread of execution to payloads... Which need to operate in Long Mode!? Really??? [C] Reverting to Virtual x86 Mode??? [D] Reverting to Real Mode???
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???
Or you would like to skip kernel MMU init while booting 64b kernel. Letting kernel to pick up (already) hot MMU, on fly?
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!
(Mysteries of CB organisms) ;-)
Zoran
On Wed, Aug 2, 2017 at 9:45 PM, ron minnich rminnich@gmail.com wrote:
right, Aaron, you keep reminding me of that and I keep forgetting it :-)
so, ok, ramstage it is for paging. The x86 is so darned annoying. We had paging in the bootblock for PPC on linuxbios.
On Wed, Aug 2, 2017 at 12:43 PM Aaron Durbin adurbin@google.com wrote:
On Wed, Aug 2, 2017 at 1:36 PM, ron minnich rminnich@gmail.com wrote:
On Wed, Aug 2, 2017 at 12:08 PM Zoran Stojsavljevic zoran.stojsavljevic@gmail.com wrote:
So, turning on the Virtual Mode (paging ON), you'll also imply that Coreboot will initialize and use MMU, don't you?
sure.
Am I correct, or you can use paging without MMU?!
MMU must be on.
I doubt that, perhaps. So, then, I would like to see this code in
Coreboot
where MMU is initialized. And how it is initialized (maybe there is a
some
over-simplified mode of operation using 2MB pages).
yep.
And my question is: what for? Or I did not get the idea... Who really needs to use paging in boot-loaders? Even INTEL, which (on purpose)
makes
things way over-dimensioned and over-complicated, does NOT use paging
in
UEFI BIOSes, so far???
it's trivial to turn on paging. In harvey I've got it down to 160 lines, including comments and white space. I made it much more compact in my CL from 1/2014.
If you turn on paging you can capture null pointer derefs, and all
other out
of range address references. And relocatable modules are much easier..
My question is, why not do it? I don't see any harm. All the other
platforms
in coreboot use paging. What's so special about x86 that it should not
use
paging?
You can't use it for CAR so that sorta throws out romstage and before. It's up to the implementation of how CAR works within the hierarchy, but with hardware page walkers that pull things through the cache things can go badly. So then you could enable paging for ramstage. Need to locate storage for the page tables, but that's not an impossible thing either.
ron
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
-
Zoran Stojsavljevic