Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's a genuinely complex problem. Booting x86-64 with arbitrary hardware attached while maintaining compatibility with boot modes from 30+ years ago is quite a feat.

https://en.wikipedia.org/wiki/Das_U-Boot + https://en.wikipedia.org/wiki/Devicetree is an alternative, but it's a massive pain because you lose PnP.



It's only complex if you want to make it so.

Load the first sector of the chosen boot device into memory at 7c00h, and jump to it.

That's how all PCs booted before the monstrosity known as UEFI came into existence.


That's like saying the only thing that actually makes a car move is the spark from the spark plug.

Yeah, that's the literal handoff, but a LOT of things need to happen before that.

Even before UEFI, you still have to deal with ACPI and friends.


> and jump to it

After CPU setup, memory training, dealing with ACPI shit, loading (and executing! [1]) Option ROM, and others?

There are things called "BIOS" doing this before UEFI came into existence.

[1] https://en.wikipedia.org/wiki/Option_ROM


On some devices, I see the line "EFI stub: load initrd from command line option" (or similar) as just another line on the same text screen that prints early UEFI messages.

And I'm still wondering about that and how text-mode/console output works.

I get it when I'm attached via a serial port, but... how many console rendering implementations for VGA output are on my system?


I think that's handled by the graphics card's EFI Graphics Output Protocol[1][2] driver

1: https://wiki.osdev.org/GOP


Why can’t we move on from the old boot modes?


People have an expectation of backwards compatibility.

Why can't we get rid of MMX instructions?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: