UEFI boot handles the real->protected (and ->long) transitions, so it's no longer necessary for the OS to handle it. EFI executables run in protected mode, with a memory mapping set up by the runtime.
> Another thing I wonder about, is if it's possible to have the CPU come online directly in protected mode or long mode after POWER_OK has settled and the motherboard releases the reset line.
No. The BIOS needs to perform some touchy, hardware-specific initialization -- like detecting and calibrating RAM -- before releasing control to user code. It's not something you'd want the OS to be responsible for.
>> Another thing I wonder about, is if it's possible to have the CPU come online directly in protected mode or long mode after POWER_OK has settled and the motherboard releases the reset line.
> No. The BIOS needs to perform some touchy, hardware-specific initialization -- like detecting and calibrating RAM -- before releasing control to user code. It's not something you'd want the OS to be responsible for.
I think you misunderstood me. I didn't mention, and wasn't even thinking about the OS yet. As you said, UEFI handles the real->protected->long transitions. While the OS isn't loaded yet, and hardware initialization is being done, the CPU is still executing. What I'm talking about is setting the CPU's default power-on state, how it is before it begins executing even the boot firmware to initalize hardware and prepare to hand over execution to the OS.
By my understanding, when the power comes on, the motherboard waits for the PSU to assert POWER_OK. Once the PSU has done so, and POWER_OK has settled, then the mobo releases the CPU's RESET line, allowing the CPU to begin executing. At this point, the CPU is in real mode. What I am wondering is if the hardware can be configured so that once the motherboard releases RESET, the CPU is already in long mode, and begins executing the boot firmware. Is there something about the nature of pre-OS hardware initializtion that requires the CPU to be in real-mode to do this?
If CPUs could be coming online directly in long-mode, then perhaps the UEFI firmware could be simplified, since it doesn't need to handle the real->protected->long transitions anymore.
> No. The BIOS needs to perform some touchy, hardware-specific initialization -- like detecting and calibrating RAM -- before releasing control to user code. It's not something you'd want the OS to be responsible for.
I don't feel like the person you're responding to suggested that the OS should be responsible for it; he/she just wondered if it is possible to have the CPU not have to jump through 16-bit real mode and 32-bit protected mode just to get to 64-bit.
I see no fundamental reason why it should be impossible for the BIOS to do its initialization work in 64-bit mode. There's the issue of paging and the page-table perhaps, but it seems trivial enough to suggest that the CPU could initialize with a very basic 1:1 mapping between virtual memory and RAM.
That said, I don't know if such a thing would ever actually happen, since I imagine that it would suggest re-writing a lot of code.
meh. since the memory controllers are part of the CPU proper this is a pita, but not clearly super magic that only contractors of motherboard manufacturers should touch either.
I worked someplace where we ran AMD chips with no bios. someone who had better uses for his time had to probe the ram modules and configure the controller. it wasn't the end of the world.
same with pci tree discovery (waste of time, not the end of the world)
interacting with EFI is a little more sane than the old bioses, and less proprietary - but i dont think there as clear a line as you imply
> Another thing I wonder about, is if it's possible to have the CPU come online directly in protected mode or long mode after POWER_OK has settled and the motherboard releases the reset line.
No. The BIOS needs to perform some touchy, hardware-specific initialization -- like detecting and calibrating RAM -- before releasing control to user code. It's not something you'd want the OS to be responsible for.