[coreboot] About Paging, Realmode and what is going on

[Zoran Stojsavljevic]

Hello Philipp,

There are lot of confusion you have created with your naming convention...
So we need here to "Divide and Concur", since this thread really remains me
of Spaghetti Bologneze.

Here is the partial picture how x86 operates:

[image: Inline image 1]

So you see here three modes, you are talking about. Every INTEL CPU starts
in Real Mode, and then switches to the protected mode.

So, you have some legacy you MUST maintain for the backward HW
compatibility.

As Patrick Georgi very correctly mentioned, let me recap what he said, with
my additions, to be much clearer with the picture I have provided.

[1]  Every x86 CPU starts in Real Mode, for the legacy reasons. the Lecacy
mode must be maintained (Real Mode replicates with the VERY first PC XT far
back to 1980, with some first 1MB memory mapping improvements). The
BackWard HW compatibility was maintained for years, and it went too far
that it can be changed over the nite. I am not going to explain why: too
long it takes.

[2] CB operates in Protected Mode, WITHOUT Paging/Virtual Mode switched on,
since this mode is ONLY used with MMU (which is HUGE HW extention to create
Virtual use of the Memory), which is managed by true OS (like Linux, WIN,
QNX, MAC OS, VMS, you name it). CoreBoot, U-Boot, BIOS boot-loaders: they
all operate from the flat/Protected Mode, and Patrick explained this very
well/excellent. In addition, I must say that this first 4GB MUST be
assigned to the benefit of the underlying HW (PCIe, GFX, SMM mode, Flash
region, ACPI tables, and so on). This assignment is done strictly
Physically, with the CPU HW helping for some regions for remapping them
(since CPU does see what CB does for it as Physical memory assignment, but
MMU [when OS runs] sees it quite differently)!

[3] As for payloads (also working in Protected Mode), there are some which
will make their own definitions of the memory, some/most which will work
deeper (as SeaBIOS, for example) on the CB Physical memory definition. As
well as these payloads (depending upon what the usage is) will add more
drivers for the certain devices, CB did not add in the first place. For
example, SeaBIOS adds IDE (maybe even AHCI, not sure) driver to this set.
Some people can define their own payloads with the set of specific drivers,
depending upon what the HW platform is intended for.

[4] Once the OS boot loader takes over (Like GRUB), it'll start OS, which
will switch from the Protected to the Virtual Mode (using MMU), Then paging
will take places, and each process will have its own set of tables, and its
own initial value for CR3 (when process context switches). I warmly suggest
to you to inspect (bit by bit) CR1 register, since this one is
crucial/essential for introducing these modes.

I really hope this helps (I've tried to develop some systematic approach to
the topic). The booting process will go to stages, and once CPU abandons
Real Mode, it'll (generally) not return to it (only in some special cases
such as SMM Mode). Once It abandons Protected Mode, it'll stay in Virtual
Mode, and so on. But backward transitions are possible, as you see from the
picture.

Zoran

On Mon, Jul 31, 2017 at 10:52 AM, Philipp Stanner <stanner at posteo.de> wrote:

> Dear folks and techpriests,
>
> the more I want to contribute and learn about low-level-code the less I
> understand, it seems.
>
>
>    1. cb switches the CPU immediately to Protected Mode, yet Payloads
>    like seaBIOS work in Real Mode. Does coreboot switch the CPU always back to
>    RM before jumping to the payload?
>    2. When CB switches to PM - who generates and administrates the Page
>    Tables and where?
>    3. Gustavo Duarte writes
>    <http://duartes.org/gustavo/blog/post/how-computers-boot-up/> that
>    GRUB switches from protected mode to real mode and vice versa all the time
>    to address >1MiB of RAM and also use the BIOS-calls. If this is true using
>    GRUB as payload would not work, as GRUB needs to call the non-existent
>    BIOS, right?
>    4. Once CB is in PM it can't access physical addresses anymore? It
>    doesn't need to, too?
>    5. PM means RAM-access is only possible through virtual addresses
>    which are translated by the MMU using the Page Tables. This question is
>    similar to [2.]: If coreboot generates the Page Tables and the payload
>    would start in PM as well (is this even possible? At least the Linux-Kernel
>    has entry points for RM and PM) this would mean the payload needs to use
>    the Page Tables generated by CB. That wouldn't be a problem as they're
>    linked in the register CR3 anyways?
>
> And an unimportant bonus question:
>
>    - Why does every modern CPU still start in RM? I do get the
>    compatibility problem, but on the other hand: Do you need it for anything
>    beside booting MS-DOS on your Ryzen? Is it really impossible for AMD and
>    Intel to create a new CPU-generation with the x86-instruction set without
>    RM, 16-bit-registers and 20-bit-mode registers like CS, SS etc. No modern
>    OS uses bios calls. No CPU is ever switched to RM again after booting up.
>    They should get rid of this old stuff.
>
> Would be cool if someone could put this in its true light.
>
> Thanks,
>
> Philipp
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20170802/2024144d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 22590 bytes
Desc: not available
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20170802/2024144d/attachment.png>