in the akaros virtual machine code, we set up a simple 1:1 map and start linux at the 64-bit entry point, at which point it builds its own page tables. So entering a payload in long mode is certainly possible and IMHO ought to be the standard on amd64 -- not that anyone cares what I think anyway :-)
Anyway, I'm going to be working on replacing ramstage with linux again, so I'm not as concerted with coreboot ramstage just now ;-) On Thu, Aug 3, 2017 at 9:16 AM Zoran Stojsavljevic < zoran.stojsavlje...@gmail.com> wrote: > 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 <rminn...@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 <adur...@google.com> wrote: >> >>> On Wed, Aug 2, 2017 at 1:36 PM, ron minnich <rminn...@gmail.com> wrote: >>> > >>> > >>> > On Wed, Aug 2, 2017 at 12:08 PM Zoran Stojsavljevic >>> > <zoran.stojsavlje...@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 >>> >> >
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot