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

[Philipp Stanner]

Dear Patrick, dear Zoran & List,

thank you, this was *very* helpful. I had some misunderstandings
regarding function and features of the CPU-modes.

Let me sum it up again and feel free to correct further mistakes.

  * 16-Bit-Real Mode: No virtual memory, no segmentation. 2^20 addresses
    of memory.
  * Protected Mode (flat mode?): CPU is in Protected Mode, Paging is
    off. The primary difference to Real Mode is that 2^32 Bytes of
    memory are available. Coreboot + Payloads use this mode, because
    they need >1MiB of memory due to various reasons
  * Virtual Mode: Paging is on, the MMU is on. Memory can only be
    accessed by using virtual addresses. Details are specified in the GDT.
  * Long Mode: Paged virtual 64-Bit mode. Standard mode of modern
    operating systems (while I presume Protected Virtual Mode is the
    Standard for any OS on i386)


Am 02.08.2017 um 18:20 schrieb Zoran Stojsavljevic:
>
>
> [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.
Thanks, I will do that. I intend to play around with QEMU and maybe have
a closer look to Intel's Programmer Manuals.

But I hope at least one assumption is right: Once coreboot jumped into
the payload no coreboot-code will be executed anymore. And once the
payload jumped into Linux no payload-code will be executed anymore?
Meaning the payload takes complete control over RAM and CPU.

Traditional BIOS (so I very much expect SeaBIOS to do the same) stays
somewhere within the 16-bit-address-space, even when Windows or Linux
are running, with it's Interrupt Service Rutines ready to do stuff.

Greetings
P.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20170802/8f7db297/attachment.html>