Hey Ron,
> You can't enter long mode (x86-64) mode without enabling paging. you need
long mode if you need to operate on more than 2^36 bytes
> of memory. That's coming everywhere. Hence,* the future of coreboot is
unambiguously one in which paging is on and at least*
*> in my case** I found it's possible to make that happen in the boot block
*-- albeit a bigger boot block than we have today.
So, turning on the Virtual Mode (paging ON), you'll also imply that
Coreboot will initialize and use MMU, don't you?
Am I correct, or you can use paging without MMU?! 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). Since... You know,
32bit OSes use physical pages to map them via MMU to be virtual contiguous
space (0-4GB space per process). And since CB is still 32bit creation... In
other words, you would like to have ONLY one uninterruptible "process" in
CB running all the time (no threading at all) to be virtualized???
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???
Zoran
On Wed, Aug 2, 2017 at 7:15 PM, ron minnich <rminn...@gmail.com> wrote:
> I'll try not to mess this explanation up too much, but it's partly from
> the docs and partly what we've learned over the years. I am assuming that
> you've at least looked at the coreboot boot block and read some of the x86
> docs, although from this note and previous notes you have written I'm still
> not sure. Have you done some of your homework :-)
>
> The architecture definition of x86 is that power on reset starts up at
> 0xffff0 in what looks to me like big real mode (a.k.a. "unreal mode" among
> many other names). From using JTAG debuggers over the years it's been clear
> to me anyway that it's not exactly classic x86 16-bit mode. Coreboot, like
> most firmware, does a classic 16-bit longjmp with segment:offset to get to
> the coreboot bootblock. This longjmp does flip us into classic x86 mode (as
> is very apparent from JTAG debuggers). Coreboot in about 12 instructions
> flips to 32-bit protected mode (no paging however). Then we go to C.
>
> FWIW, many vendors told us at the time it was impossible to write firmware
> in C, as we did in 2000, so it was nice to show it could be done.
>
> As for paging: we've had several platforms, starting in 2000, that used
> paging (which does not always imply page tables). Alpha comes to mind: we
> had a basic PALCode that implemented 1:1 mapping. Most coreboot platforms
> use paging.
>
> I note that some amount of paging is now in coreboot for x86 and maybe
> someone can let us know where and when it's used.
>
> But as for real mode, no, starting from POR in protected mode has never
> been an option intel was willing to support. We've asked ("we" not being
> Google, but from my earlier life in HPC). There's no technical reason it
> could not work (it's microcode, after all) but it would be a pretty big
> change from the "party like it's 1978" model of the x86.
>
> Note that many CPUs, such PPC starting ca. 2008, can not run with paging
> off; they start up with default entries in the TLB and paging is on from
> power on reset.
>
> You can't enter long mode (x86-64) mode without enabling paging. you need
> long mode if you need to operate on more than 2^36 bytes of memory. That's
> coming everywhere. Hence, the future of coreboot is unambiguously one in
> which paging is on and at least in my case I found it's possible to make
> that happen in the boot block -- albeit a bigger boot block than we have
> today.
>
> ron
>
--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
