6 comments

[ 2.8 ms ] story [ 23.7 ms ] thread
What an ironic choice of header image --- phone SoCs vary widely in how they boot, and the details are often not publicly documented, making them very easily become e-waste far sooner than x86/PC's legacy of backwards compatibility and (relative) openness.

This is because on reset, the system is in a “special” Real Mode, where the first 12 address lines are asserted.

To be precise, it's in real mode but with the descriptor caches loaded such that the physical address generated is at FFFFFFF0.

http://www.rcollins.org/ddj/Aug98/Aug98.html

These 12 address lines remain asserted until a long JMP is executed, after which they are de-asserted and normal Real Mode addressing calculations resume.

...because such a jump reloads the segment descriptor caches with real-mode-compatible values.

Also from a comment there:

Prior to UEFI, protected mode and long mode were not enabled by firmware but rather by the OS loader.

All BIOSes since the 286 PC/AT will enter protected mode shortly after the reset vector. UEFI boot is what starts the OS in protected mode, while legacy/compatibility boot returns back to realmode before executing the boot sector.

See also https://news.ycombinator.com/item?id=3559674, which has a reference to this in its comments.
Where are the microcode patches persistently stored and loaded from? The article didn’t go into much depth there.