5 ms·

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

by xxpor 4y ago

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

userbinator 4y ago
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.
- xxpor 4y ago
  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.
- rfoo 4y ago
  > 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 https://en.wikipedia.org/wiki/Option_ROM
wolletd 4y ago
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?
- garblegarble 4y ago
  I think that's handled by the graphics card's EFI Graphics Output Protocol[1][2] driver 1: https://wiki.osdev.org/GOP https://wiki.osdev.org/GOP
culopatin 4y ago
Why can’t we move on from the old boot modes?
- xxpor 4y ago
  People have an expectation of backwards compatibility. Why can't we get rid of MMX instructions?

by xxpor 4y ago

userbinator 4y ago

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.

xxpor 4y ago
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.
rfoo 4y ago
> 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 https://en.wikipedia.org/wiki/Option_ROM

wolletd 4y ago

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?

garblegarble 4y ago
I think that's handled by the graphics card's EFI Graphics Output Protocol[1][2] driver 1: https://wiki.osdev.org/GOP https://wiki.osdev.org/GOP

culopatin 4y ago

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

xxpor 4y ago
People have an expectation of backwards compatibility. Why can't we get rid of MMX instructions?