UEFI or Legacy BIOS Bootloader?

[Cjreek]

I might return to OS development with a slightly higher goal of making an OS that is somehow useable instead of being just "whatever".

I'm developing on Windows and I always found it laborious to work with GRUB on Windows. So I'd like to make my own bootloader.
I'm not planning on targeting ancient hardware that no one in the real world ever uses anymore.
So I'm going to make an 64-Bit OS (instead 32-Bit) and now I'm thinking about whether I should make an UEFI bootloader or an Legacy BIOS bootloader.

Are there any major disadvantages? Does virtually every laptop/desktop pc from 2010+ on support UEFI?
Or should I rather stay with BIOS?

[Brendan]

Hi,

I might return to OS development with a slightly higher goal of making an OS that is somehow useable instead of being just "whatever".

I'm developing on Windows and I always found it laborious to work with GRUB on Windows. So I'd like to make my own bootloader.
I'm not planning on targeting ancient hardware that no one in the real world ever uses anymore.
So I'm going to make an 64-Bit OS (instead 32-Bit) and now I'm thinking about whether I should make an UEFI bootloader or an Legacy BIOS bootloader.

Are there any major disadvantages? Does virtually every laptop/desktop pc from 2010+ on support UEFI?
Or should I rather stay with BIOS?

I'd recommend designing your own specification that describes the state of everything when the boot loader passes control to the kernel; and ensuring that nothing in the kernel depends on firmware of any kind. That way anyone can create a boot loader that complies with your specification (and works for your kernel/OS); and your kernel/OS won't have any reason to care what the boot loader is (or if the boot loader happened to use BIOS or UEFI or OpenFirmware or CoreBoot or something else).

In this case, it becomes "which boot loader should you implement first", where the only thing that really matters is your own personal convenience.

Note: Eventually (not soon), I'd want:

• A boot loader for "BIOS, MBR partitioned disk"
• A boot loader for "BIOS, GPT partitioned disk"
• A boot loader for "BIOS, PXE/network boot"
• A boot loader for "BIOS, no emulation El Torito CD"
• A boot loader for "64-bit UEFI"
• Code for something like "kexec()" (where your kernel is started by a previous instance of your kernel)

Cheers,

Brendan

[Cjreek]

Hi Brendan,

So you wouldn't recommend implementing the Multiboot specification?
Also: In which way would the OS even be able to care or even depend on the firmware? (if it's not a real mode OS)

I guess it's about which kind of bootloader to prioritize the highest for modern x86 environments.

[kzinti]

I agree with Brendan about having your own protocol and write a bootloader for each type of firmware you want.

That said, instead of writing 'x' bootloaders for the BIOS, I just wrote one using multiboot (grub). Nothing prevents me from adding a real BIOS bootloader down the road if I want to.

The downside of multiboot is that you can't call the BIOS easily to retrieve EDID monitor data, change resolutions, and so on. But it's totally doable.

Another problem is that if you are loaded by the multiboot protocol, you don't even know if the BIOS exists at all.

[Brendan]

Hi,

So you wouldn't recommend implementing the Multiboot specification?

If the Multiboot specification suits your OS, then it can act as a "specification that describes the state of everything when the boot loader passes control to the kernel" (even if you do write your own boot loader).

Beyond that, it depends on the nature of your OS and its design. For examples; Multiboot specification won't suit your OS if you want to do things like:

• Use digital signatures for security
• Setup long mode/64-bit in the boot loader (to avoid an ugly linker mess for the kernel)
• Setup paging in the boot loader (to avoid an ugly "kernel initialisation" mess)
• Let "kexec()" leave CPUs running (instead of shutting them all down before and then starting them all again after)
• Allowing boot loader to set up 2 or more framebuffers (for 2 or more monitors) that the kernel can use
• Get boot loader to tell your kernel the address of ACPI tables (so your kernel doesn't need to search for them on UEFI systems that give you the address)
• Get boot loader to tell your kernel the IP address of the computer (if it was booted from network) to avoid kernel having to use DHCP to get the same IP address a second time

Of course this is not an exhaustive list - there's no way to guess what you might want that Multiboot doesn't support.

Also: In which way would the OS even be able to care or even depend on the firmware? (if it's not a real mode OS)

This includes things like:

• Assuming that VBE exists and can be used to set a video mode after boot (it doesn't exist on UEFI)
• Assuming that values from the BIOS Data Area exist and can be used (they don't exist on UEFI)
• Assuming anything at all about the physical memory map (e.g. that there's usable RAM at 0x00100000 - UEFI makes no guarantees)
• Assuming that various legacy devices exist (PS/2 controller, PIC chips, PIT chip - these may not exist and may not be emulated via. SMM on UEFI)
• Assuming that various devices are in any kind of legacy emulation mode (video card, hard disk controller, etc)
• Assuming that you can use any "UEFI run-time service" (these don't exist for BIOS)

Cheers,

Brendan