Ditching legacy BIOS in favor of UEFI

[StudlyCaps]

I'm starting to develop a hobby OS, and I was wondering if there were any good reasons not to just target UEFI and avoid interacting with the legacy BIOS APIs at all. What I have read suggests that everything you can do with the BIOS API you can do with UEFI and you ditch things like the crazy array of semi-compatible BIOS interrupts and dropping back to real mode to setup VGA modes.

I realize legacy hardware compatibility is one concern but other than that are their any hidden problems or gotcha's which make UEFI less than perfect for a new OS targeting modern hardware?

[BrightLight]

I think it's better to write a boot loader for both UEFI and BIOS. This ensures better compatibility. Specifically, the BIOS is required to set VBE modes; VGA can be easily achieved by tweaking a few (20 or something) registers. Anyway BIOS is coming to an end and UEFI is supported on all current PCs.

[StudlyCaps]

After doing some more reading, I think you're right that it's not really feasible to ignore the BIOS as long as you still need the VESA VBE. UEFI does appear to offer something similar, but it can't be used once you finish booting and want the OS to take over so you either need a proper driver, or to drop back to real mode and use VBE.
Is that right?

[Combuster]

If you use the BIOS for booting that way, you set a graphics mode using VESA, then go to protected mode to set up the kernel after which you can't sanely return to set a different graphics mode.
If you use UEFI for booting that way, you set a graphics mode using the GOP interface, then exit boot services to set up the kernel after which you can't sanely return to set a different graphics mode.

The main difference in practice is that VESA allows more modes and is more forgiving to hacks.

Additionally, if you use GRUB you can get both platforms and a graphics mode pre-set for free.

[bluemoon]

IMO VESA/VBE is not that important issue.

The only time you want to to use VESA/VBE is to switch video mode when you detected a change in monitor setup, otherwise you should keep it at native resolution and do software(or hardware-accelerated) scaling on the UI elements.

If you are at that stage of polishing you probably have native driver anyway.


BIOS supports brings a lot of trouble with it as well, especially when it comes to QA - old board's BIOS are sometime buggy, while new boards don't care since most users boots straight to EFI.

Alternatively, you can use 3rd party boot manager like GRUB/uboot and forget these.

[Antti]

Is it really necessary to target your OS to some specific firmware? You may start with UEFI but if your OS does not rely on some really firmware-specific features, nothing prevents you from implementing a boot loader for BIOS if you change your mind and have time to do it. After all, having an option for BIOS booting could make the system better, i.e. not too much dependent on the firmware, even if the boot loader for BIOS were never implemented.

The real challenge here is the specification that defines the computer state just before the boot loader exits. Static data structures, e.g. memory map, might be enough but to make it more advanced you could provide your own firmware-independent boot services. In this case the boot loader does not necessarily exit immediately but the kernel (or its initializer) calls something like ExitMyOwnBootServices().

I cannot give you a complete solution to this because I am still struggling with this challenge.

[StudlyCaps]

Thanks guys for your responses .

I think that I was approaching this problem from the wrong angle, I was looking to make a design decision based on what firmware would provided the most convenient shortcut. A much better way would be, as Antti said, to look at the what I want the system state to be when my bootloader passes control to the kernel and then design my bootloader as a black-box which provides the right environment regardless of what firmware functionality is available.
Then, if I want to change graphics settings after boot, I just write a graphics card driver!

[rdos]

At the moment, I think BIOS booting is more stable than UEFI booting. I have bootloaders for both BIOS and 32 and 64 bit UEFI, but I still find bugs in UEFI implementations that require me to modify the EFI code. Sometimes the UEFI will not load files properly, and sometimes it will fail to return a memory map (an Intel UEFI BIOS).

In addition to that, some UEFIs will initialize the hardware in strange ways which makes them malfunction if you don't do all the right intializations yourself. For instance, one AMD UEFI will setup AP cores in strange ways that makes them fault on Interrupts. Also, an Intel UEFI had manipulated with processor control registers so I couldn't return to 32-bit mode without additional initialization (managed to fix that).

Also, at the moment, all new PCs still appear to boot correctly with BIOS. Still, it is getting more and more buggy, so you will want to move to UEFI eventually.

Another drawback is that with UEFI, you can no longer change video mode dynamically (unless you have as native video driver), and will need to emulate text mode within a video mode which is painfully slow compared to a real text mode.

[Nable]

...and will need to emulate text mode within a video mode which is painfully slow compared to a real text mode.

It's just wrong since.. I don't remember exactly but somewhere near the end of 90s. It looks like newer video cards don't have real text modes in hardware. It's emulated via VGA BIOS or some internal firmware and it's really slow as nobody cared to optimize such functions that are almost never used. If you try measuring text mode performance you'll find out that it's awful unless you are using some ancient card such as S3. Good implementation of character blitting in graphic mode works much better. And don't forget about non-ASCII users, please. And about underlining, strike-through, italic, tons of colors, etc...

[~]

At the moment, I think BIOS booting is more stable than UEFI booting. I have bootloaders for both BIOS and 32 and 64 bit UEFI, but I still find bugs in UEFI implementations that require me to modify the EFI code. Sometimes the UEFI will not load files properly, and sometimes it will fail to return a memory map (an Intel UEFI BIOS).

In addition to that, some UEFIs will initialize the hardware in strange ways which makes them malfunction if you don't do all the right intializations yourself. For instance, one AMD UEFI will setup AP cores in strange ways that makes them fault on Interrupts. Also, an Intel UEFI had manipulated with processor control registers so I couldn't return to 32-bit mode without additional initialization (managed to fix that).

Also, at the moment, all new PCs still appear to boot correctly with BIOS. Still, it is getting more and more buggy, so you will want to move to UEFI eventually.

Another drawback is that with UEFI, you can no longer change video mode dynamically (unless you have as native video driver), and will need to emulate text mode within a video mode which is painfully slow compared to a real text mode.

When things are so buggy, it's clear that they are just patches.

UEFI is just a fast patch to try to obliterate the existence of the BIOS, which would in turn put an end to the standard PC platform and would leave us with tablet-like machines.

That's why I say that the BIOS should always be the base and have it load UEFI on top of it as a boot manager. The 16-bit BIOS could load another 32 or 64-bit BIOS, and from there we could load UEFI stably.

The BIOS is optimal for the x86 CPU and its peripherals. It's extremely optimized down to a mathematical point, whereas UEFI feels like a random application implemented using only badly-understood legacy pieces of low-level code. It has no mathematical-grade calibration or optimizations for the CPU registers, memory, I/O, etc.

That's why I say that it would be best implemented as something secondary to the BIOS.

[Octocontrabass]

UEFI is just a fast patch to try to obliterate the existence of the BIOS, which would in turn put an end to the standard PC platform and would leave us with tablet-like machines.

I've seen a lot of servers with UEFI firmware, but none of them looked very much like tablets.

The BIOS is optimal for the x86 CPU and its peripherals. It's extremely optimized down to a mathematical point, whereas UEFI feels like a random application implemented using only badly-understood legacy pieces of low-level code.

Have you ever looked at BIOS code? It feels like a random application implemented using only badly-understood legacy pieces of low-level code...

All of your complaints about UEFI apply equally to BIOS, except BIOS is crippled by the limitations of real mode.

[~]

UEFI is just a fast patch to try to obliterate the existence of the BIOS, which would in turn put an end to the standard PC platform and would leave us with tablet-like machines.

I've seen a lot of servers with UEFI firmware, but none of them looked very much like tablets.

The BIOS is optimal for the x86 CPU and its peripherals. It's extremely optimized down to a mathematical point, whereas UEFI feels like a random application implemented using only badly-understood legacy pieces of low-level code.

Have you ever looked at BIOS code? It feels like a random application implemented using only badly-understood legacy pieces of low-level code...

All of your complaints about UEFI apply equally to BIOS, except BIOS is crippled by the limitations of real mode.

The BIOS could be implemented as a loadable 32 or 64-bit image too to work natively in those modes equally well. Then make UEFI run on top of it optionally. It would be more stable and it would only implement the high level services, easier and cleaner to do if UEFI is actually being implemented by programmers who don't know as much about the BIOS and PC as previous generations, as I suspect by the fact of trying to implement a whole different system instead of just porting the BIOS to 32 and 64-bit.

The base firmware looks like tablet software. It has no real accessible low level interfaces to base it on that are almost as optimized as the CPU microcode, as is the case of the BIOS.

A tablet could also look like a decent server past the boot process if we install Linux. But it's still and is already in a deplorable state from the point of view of having a standard computer platform and decently standardized hardware.

I have seen the BIOS code, I have the specification books from Phoenix (BIOS, ABIOS, CBIOS). It looks like CPU microcode. It's hard to understand because it tries to reuse every single effect of CPU instructions without making mistakes or colliding. Of course it doesn't look like OOP code but you can't expect that from CPU microcode either and expect it to be lightening fast and still maintainable.

OOP code without real low-level code or interfaces in a whole computer system will always seem unreasonable to me as it degrades the way the hardware is managed by its implemented firmware.

[Octocontrabass]

It has no real accessible low level interfaces to base it on that are almost as optimized as the CPU microcode, as is the case of the BIOS.

The firmware is not there to give you a low-level interface. It's there to boot your operating system. If you want a low-level interface, write a driver.

BIOS code is not optimized for speed. It's not really optimized at all - there's no point in optimizing something that will only be used for a few seconds before the OS finishes loading.

[rdos]

The firmware is not there to give you a low-level interface. It's there to boot your operating system.

That's the basic problem. When you boot an operating system not built on PE or ELF flat binaries of the right bitness, the UEFI loader (and GRUB) is just creating problems with no benefits. First, I both need a 64-bit and a 32-bit EFI, and the 64-bit EFI needs to switch back to 32-bit protected mode in order to be compatible. Then I need to turn-off paging as this is setup in a different way in the OS. Basically, leaving control in 64-bit "flat paged mode" has no benefits at all for me. I'd rather be in real mode instead.

BIOS code is not optimized for speed. It's not really optimized at all - there's no point in optimizing something that will only be used for a few seconds before the OS finishes loading.

It should be optimized for reliability, but many UEFI BIOSes are notoriously unstable, and especially when not booted the "typical" way with Windows. In addition to that, a machine installed with Windows 10 has turned-off the possibility to boot anything else by default. This never happened with the ordinary BIOS.

[rdos]

It's just wrong since.. I don't remember exactly but somewhere near the end of 90s. It looks like newer video cards don't have real text modes in hardware. It's emulated via VGA BIOS or some internal firmware and it's really slow as nobody cared to optimize such functions that are almost never used.

It's still faster than writing 4 bytes per pixel times 8 pixels wide times 19 lines per character. I mean, a typical "hobby" OS will not have a native graphics driver, rather relies on LFB.

If you try measuring text mode performance you'll find out that it's awful unless you are using some ancient card such as S3. Good implementation of character blitting in graphic mode works much better. And don't forget about non-ASCII users, please. And about underlining, strike-through, italic, tons of colors, etc...

A typical console needs to output the right ASCII characters otherwise, it is be broken. After all, text-mode apps assume they can draw boxes and similar. You also need to emulate the blinking cursor by regularly updating the LFB.