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.
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot