<div dir="ltr">Hello Philipp,<div><br></div><div>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.</div><div><br></div><div>Here is the partial picture how x86 operates:</div><div><br></div><div><img src="cid:ii_15da3976a09e66e4" alt="Inline image 1" width="245" height="206"><br></div><div><br></div><div>So you see here three modes, you are talking about. Every INTEL CPU starts in Real Mode, and then switches to the protected mode.</div><div><br></div><div>So, you have some legacy you MUST maintain for the backward HW compatibility.</div><div><br></div><div>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.</div><div><br></div><div>[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.</div><div><br></div><div>[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)!</div><div><br></div><div>[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.</div><div><br></div><div>[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.</div><div><br></div><div>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.</div><div><br></div><div>Zoran</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 31, 2017 at 10:52 AM, Philipp Stanner <span dir="ltr"><<a href="mailto:stanner@posteo.de" target="_blank">stanner@posteo.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
Dear folks and techpriests,<br>
<br>
the more I want to contribute and learn about low-level-code the
less I understand, it seems.<br>
<br>
<ol>
<li>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? <br>
</li>
<li>When CB switches to PM - who generates and administrates the
Page Tables and where?</li>
<li><a href="http://duartes.org/gustavo/blog/post/how-computers-boot-up/" target="_blank">Gustavo
Duarte writes</a> 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?</li>
<li>Once CB is in PM it can't access physical addresses anymore?
It doesn't need to, too?</li>
<li>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?<br>
</li>
</ol>
<p>And an unimportant bonus question:</p>
<ul>
<li>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.<br>
</li>
</ul>
<p>Would be cool if someone could put this in its true light. <br>
</p>
<p>Thanks,</p>
<p>Philipp<br>
</p>
</div>
<br>--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br>
<a href="https://mail.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://mail.coreboot.org/<wbr>mailman/listinfo/coreboot</a><br></blockquote></div><br></div>