OSDev.org

If I want to learn how to develop an operating system and have it be UEFI-based, is it still worth first learning to program it with BIOS and real-mode assembly or is it a waste of time and should I go straight for UEFI?

Why do people keep conflating BIOS and OS development? I cannot figure it out. In any case, the difference is the starting point, yes, but before long, your OS is supposed to be independent of the firmware interface. I would suggest you let your kernel be loaded by a bootloader for now and start from there. Then, once you have your feet wet, you can go back and implement a bootloader for your kernel if you still want to. And making a bootloader for a BIOS based system now is just a futile effort, in my opinion. There are no new BIOS based systems coming out.

nullplan wrote:And making a bootloader for a BIOS based system now is just a futile effort, in my opinion. There are no new BIOS based systems coming out.

While I agree with the use an existing bootloader suggestion, I don't think I buy this as an argument.

There's still plenty of old BIOS systems out there, and frankly they're probably the ones other people are more likely to be willing to run your hobby OS on - so it can be valuable to target them. Personally, my main test rig is still a BIOS-only machine - a ThinkPad T410 from the very last line before they had EFI - and it's also still an entirely capable machine (if a bit heavy... but it was heavy when it was new, too).

And perhaps there's a bit of value for some people to "check the box" of having done some traditional realmode assembly - especially if they care enough to bother writing their own bootloader. Some people enjoy studying history!

I agree with klange. I see some educational value too in writing a BIOS bootloader. It's just cool. Also, even if all physical machines sold in the last 10+ years have UEFI, legacy boot is still widely used in VMs. For example, with QEMU it's just faster to boot with the legacy bootloader than with the UEFI bootloader, because the whole OVMF has to be loaded first and that takes a few seconds.

But yeah, overall it's not something strictly necessary to do/know nowadays. It's something extra. Also, is not really OS-dev. It's somehow related, but it's a different thing. The OS should not care about how has been loaded.

Hi,

Somewhat in agreement with everyone here but I always have the stance that the boot loader is a component of the completed operating system. Whether it is custom or not is dependent on what your design needs and goals are. If, for example, GrUB meets or exceeds what you need, you might as well use it and not worry about the boot process. If you want to support UEFI only firmware, go for it -- nothing is stopping you if it satisfies what you want.

In our boot loader, firmware specific calls are hidden behind interfaces so it can in theory support any firmware type (current builds for Legacy BIOS and UEFI.) No other code in the loader or outside is dependent on the firmware.

Seasoft wrote:If I want to learn how to develop an operating system and have it be UEFI-based, is it still worth first learning to program it with BIOS and real-mode assembly or is it a waste of time and should I go straight for UEFI?

You'd better go straight for UEFI, but I think it's worth knowing about BIOS and real-mode assembly
And your operating system shouldn't care about how it has been loaded.You should design a general boot specification so that your operating system can be loaded by several ways.

If your hobby includes hardware and you look further afield than the Raspberry Pi, you'll find x86/BIOS SBCs. You can also find them in industrial installations.

It is lot easier to start out this way and learn a lot in the process. I believe it is worth it.

I may be confused but I always thought that the uefi insulates you from the hardware in a way that bios doesn't. If I'm right, then you would want to learn how to use bios hardware for the sake of experience?

rnd0 wrote:I may be confused but I always thought that the uefi insulates you from the hardware in a way that bios doesn't. If I'm right, then you would want to learn how to use bios hardware for the sake of experience?

EFI does not "insulate" from the hardware in any meaningfully different way from BIOS.

Both BIOS and EFI offer abstractions over reading from unspecified block storage devices, abstractions for reading keyboard input, abstractions over text output to a display, and abstractions over setting video modes. The way these abstractions are provided is very different, yes, but they offer the same fundamental functionality.

BIOS loads your payload in real mode, EFI loads your payload in protected mode or long mode (depending on the system) and a minimally-specified flat memory layout. Both install interrupt handlers and initialize devices themselves, and both will happily sit on the sidelines as you trash memory, install your own interrupt tables, switch execution modes, and so on, only guaranteeing their abstractions work so long as you stick to their interfaces.

But I get that reading and writing the disk with uefi aswell as many other tasks are way much faster than the BIOS, UEFI Loads my OS instantly and easily where the BIOS stands ahead by seconds.