OSDev.org

Is there someway how to boot both BIOS and UEFI-based operating systems from one bootloader?
I think answer will be no, but maybe some magic?

Edit:Windows Managment Instrumentation seems to be able to switch between the UEFI/legacyBIOS options. How to do that?

If a computer with a UEFI bios can't find a UEFI loader on the disk, it will load ann EFI application which emulates a traditional bios, and attempts to load the operating system that way. Provided it can find a boot sector of course.

Obviously a UEFI loader will have the EFI system table available to it, as well as the EFI services, and a loader based upon a traditional BIOS won't.

I think I need some clarification, are these statements true:
BIOS booting: Computer loads BIOS. BIOS loads and executes MBR.
UEFI booting: Computer loads UEFI and it loads default EFI application, which resolves GPT.
UEFI with legacy BIOS: Computer loads UEFI and it loads EFI application, which switches settings and does BIOS booting
UEFI with legacy BIOS: Computer loads UEFI and it loads EFI application, which emulates BIOS booting

BIOS booting: Computer loads BIOS. BIOS loads and executes MBR.
UEFI booting: Computer loads UEFI and it loads default EFI application, which resolves GPT.

The computer has no need to load them, because they are permanently stored in non volatile RAM. When the computer boots up, the processor is guaranteed to start executing at 0xF000:0xFFF0, and that is where the first instruction inthe bios is to be found. Usually it is a jump instruction. UEFI can boot from either a GPT or mbr. For some reason Windows refused to install a GPT on my hard disk, even though it has a UEFI bios. So now I have a UEFI bios booting an mbr.

UEFI with legacy BIOS: Computer loads UEFI and it loads EFI application, which emulates BIOS booting

A UEFI bios will load an EFI application to emulate a traditional bios, if, and only if, it cannot find an EFI loader on the disk. The loader has a predefined name. An EFI loader is an ordinary executable file, and is essentially the traditional boot sector and second stage loader rolled into one.

Casm wrote:When the computer boots up, the processor is guaranteed to start executing at 0xF000:0xFFF0, and that is where the first instruction inthe bios is to be found. Usually it is a jump instruction.

x86 machines boot from 0xFFFFFFF0 since circa the Pentium. This is in a crazy unreal mode state

A UEFI bios will load an EFI application to emulate a traditional bios, if, and only if, it cannot find an EFI loader on the disk. The loader has a predefined name. An EFI loader is an ordinary executable file, and is essentially the traditional boot sector and second stage loader rolled into one.

A UEFI application can't emulate a BIOS. The BIOS "Compatbility Support Module" has to be built in and takes control from the UEFI implementation.

Hi,

Think of it as 3 different types of computers. The first is "BIOS only", where there's no support for UEFI at all and you must use a boot loader designed for BIOS. These are common (there's lots of old computers still being used) but no new computers are "BIOS only" and eventually (maybe 5 years?) "BIOS only" will be very rare.

The second type is a "hybrid mixture", where the firmware includes both BIOS and UEFI. In this case you can tell the firmware to use UEFI or BIOS; and (for at least for some computers) if they can't find a usable UEFI boot loader they'll automatically switch to BIOS and attempt to find a suitable BIOS boot loader. These are common (e.g. most new computers are like this); but they only exist to allow the industry to make a gradual transition from "BIOS only" to "UEFI only". Eventually (e.g. when nobody cares about Windows XP and it's not worth the hassle of providing BIOS anymore) they will become rare.

The third type is "UEFI only", where there's no support for BIOS at all and you must use a boot loader designed for UEFI. These are currently rare but they do exist. This is what the industry is heading towards; and eventually (maybe 10 years?) all new computers will be like this.

Please note that a lot of pieces of hardware are designed to be "legacy OS compatible" (including A20 gate, PIC chips, PS/2 controller, PIT chip, etc), or are designed to support "legacy OS compatibility modes" (including PCI bridges, disk controllers, USB controllers, video cards, etc). For the second type of computer (the "hybrid mixture") all this obsolete/legacy hardware still has to exist in case the user wants to use BIOS. For the third type of computer (the "UEFI only") all of this obsolete hardware doesn't need to exist at all. Basically; the third type of computer (the "UEFI only") will start out as "UEFI only with legacy hardware" but will gradually move towards "legacy free UEFI".

I also think that (for computers in general) manufacturers used to compete on performance (making faster and faster computers), but there's very little demand for faster computers now. In response to this manufacturers will compete on power consumption and price (making computers cheaper to buy and cheaper to run, instead of making them faster). The easiest way to do this is to rip out all the legacy stuff. Basically; once "UEFI only" becomes common, I think the move from "UEFI only with legacy hardware" to "legacy free UEFI" will happen fast.

As a summary, here's my predictions for 80x86 desktop/server:

• for the next 8 years "hybrid mixture" will dominate
• in about 8 years "UEFI only with legacy hardware" will dominate
• in about 12 years "legacy free UEFI" will dominate

And here's my predictions for 80x86 small mobile/tablet:

• in about 3 years "UEFI only with legacy hardware" will dominate
• in about 5 years "legacy free UEFI" will dominate

Laptops will be somewhere between these.

What does this mean to us? As a (very rough) estimate it takes about 10 years to get an OS from "idea" to "actually usable". Someone starting an OS today could support UEFI and not bother with BIOS at all, and by the time the OS is usable none of the users will care that it doesn't support old BIOS systems. This makes perfect sense.

Alternatively; you could write several BIOS boot loaders (e.g. one for booting from hard disk, one for booting from network, one for booting from "no emulation El Torito" CD, etc) and write a UEFI boot loader. You can design it so that all boot loaders (for both BIOS and UEFI) hide the firmware from the rest of the OS and boot the same kernel, etc. You can even have (e.g.) "hybrid GPT/MBR" hard disks, and "hybrid UEFI/BIOS boot CDs" (where there's 2 or more boot loaders, the firmware boots whichever boot loader is suitable and all boot loaders start the same kernel/OS). This makes perfect sense too.

What doesn't make sense is writing an OS that can only be booted with boot loader/s designed for BIOS - it's very likely that the OS will be obsolete before it's actually usable.


Cheers,

Brendan

Brendan wrote: I also think that (for computers in general) manufacturers used to compete on performance (making faster and faster computers), but there's very little demand for faster computers now. In response to this manufacturers will compete on power consumption and price (making computers cheaper to buy and cheaper to run, instead of making them faster). The easiest way to do this is to rip out all the legacy stuff. Basically; once "UEFI only" becomes common, I think the move from "UEFI only with legacy hardware" to "legacy free UEFI" will happen fast.

As a summary, here's my predictions for 80x86 desktop/server:

• for the next 8 years "hybrid mixture" will dominate
• in about 8 years "UEFI only with legacy hardware" will dominate
• in about 12 years "legacy free UEFI" will dominate

And here's my predictions for 80x86 small mobile/tablet:

• in about 3 years "UEFI only with legacy hardware" will dominate
• in about 5 years "legacy free UEFI" will dominate

Laptops will be somewhere between these.

What does this mean to us? As a (very rough) estimate it takes about 10 years to get an OS from "idea" to "actually usable". Someone starting an OS today could support UEFI and not bother with BIOS at all, and by the time the OS is usable none of the users will care that it doesn't support old BIOS systems. This makes perfect sense.

You are probably somewhat right about that. As Windows 8 is pre-installed on most new computers today, there is additional hazzle with installing alternative operating systems as all of these are configured for UEFI-booting. The Sony Ultrabook I recently bought had Windows 8, and booted with UEFI. In order to provide interoperability between Windows and RDOS I had to wipe-out Windows 8 and install Windows 7 in BIOS legacy boot mode. While this is probably possible to do on many of the new laptops today, it will become rarer in the future. I think that as soon as customers are content with the shipped OS, manufacturers will no longer care to support installing older OSes. What is hindering this process is that many customers don't like Windows 8 and prefer Windows 7.

So, yes, OSes must support UEFI booting in order to run on new machines in the "near" future.

Brendan wrote: Alternatively; you could write several BIOS boot loaders (e.g. one for booting from hard disk, one for booting from network, one for booting from "no emulation El Torito" CD, etc) and write a UEFI boot loader. You can design it so that all boot loaders (for both BIOS and UEFI) hide the firmware from the rest of the OS and boot the same kernel, etc. You can even have (e.g.) "hybrid GPT/MBR" hard disks, and "hybrid UEFI/BIOS boot CDs" (where there's 2 or more boot loaders, the firmware boots whichever boot loader is suitable and all boot loaders start the same kernel/OS). This makes perfect sense too.

That is not possible. The advantages (mostly speed-wise) of using text-mode instead of emulating text-mode in a graphics mode is so large that I don't see my OS running text-mode in a graphics mode when booting with BIOS. That means different graphics drivers will be needed depending on boot-mode. The organisation information on existing video modes will also be different, using VBE for BIOS and being fixed (but still dynamic) in UEFI.

rdos wrote:You are probably somewhat right about that. As Windows 8 is pre-installed on most new computers today, there is additional hazzle with installing alternative operating systems as all of these are configured for UEFI-booting. The Sony Ultrabook I recently bought had Windows 8, and booted with UEFI. In order to provide interoperability between Windows and RDOS I had to wipe-out Windows 8 and install Windows 7 in BIOS legacy boot mode. While this is probably possible to do on many of the new laptops today, it will become rarer in the future. I think that as soon as customers are content with the shipped OS, manufacturers will no longer care to support installing older OSes. What is hindering this process is that many customers don't like Windows 8 and prefer Windows 7.

Windows 7 (64-bit) is fully UEFI compatible. Hell, Vista 64-bit is fully UEFI compatible (not that I can see anyone intentionally installing that...)

Its' XP thats keeping th BIOS alive. Microsoft end XP's life support next year. We'll see how long its' oxygen lasts after that...

Hi,

rdos wrote:

Brendan wrote:Alternatively; you could write several BIOS boot loaders (e.g. one for booting from hard disk, one for booting from network, one for booting from "no emulation El Torito" CD, etc) and write a UEFI boot loader. You can design it so that all boot loaders (for both BIOS and UEFI) hide the firmware from the rest of the OS and boot the same kernel, etc. You can even have (e.g.) "hybrid GPT/MBR" hard disks, and "hybrid UEFI/BIOS boot CDs" (where there's 2 or more boot loaders, the firmware boots whichever boot loader is suitable and all boot loaders start the same kernel/OS). This makes perfect sense too.

That is not possible.

It's entirely possible, and every modern OS (Windows, Linux, FreeBSD, etc) already does this; except for OS X (which simply doesn't bother with BIOS at all).

rdos wrote:The advantages (mostly speed-wise) of using text-mode instead of emulating text-mode in a graphics mode is so large that I don't see my OS running text-mode in a graphics mode when booting with BIOS.

If you insist on inflicting horrifically ugly text mode on unsuspecting victims; and if your code is so bad that emulating text mode makes a noticeable difference to performance; and if you aren't smart enough to just ask UEFI for a text mode in the first place; then I really do doubt that it's fair to blame anyone except yourself.

rdos wrote:That means different graphics drivers will be needed depending on boot-mode.

No, the exact same native video drivers work fine regardless how the OS booted. What is different is the code in the boot loader that sets up a default video mode in case there isn't any native video driver.

rdos wrote:The organisation information on existing video modes will also be different, using VBE for BIOS and being fixed (but still dynamic) in UEFI.

So when I said "design it so that all boot loaders (for both BIOS and UEFI) hide the firmware from the rest of the OS" you thought I meant "don't hide the differences from the rest of the OS, and then complain that there's differences"?


Cheers,

Brendan

Owen wrote: Windows 7 (64-bit) is fully UEFI compatible. Hell, Vista 64-bit is fully UEFI compatible (not that I can see anyone intentionally installing that...)

Yes, Windows 7 is UEFI compatible, but the installations I've seen use BIOS, not UEFI. The problem (from my perspective) is that Windows 8 only boots in UEFI-mode, which means you cannot easily dual-boot it with BIOS boots.

Owen wrote: Its' XP thats keeping th BIOS alive. Microsoft end XP's life support next year. We'll see how long its' oxygen lasts after that...

I don't think it matters a lot if Microsoft end XP support. It would be a good thing as they only introduce new bugs with their updates anyway. The problem rather is new hardware that has no XP drivers.

Brendan wrote: If you insist on inflicting horrifically ugly text mode on unsuspecting victims; and if your code is so bad that emulating text mode makes a noticeable difference to performance; and if you aren't smart enough to just ask UEFI for a text mode in the first place; then I really do doubt that it's fair to blame anyone except yourself.

I think you misunderstand the problem. I don't use text-mode exclusively, rather this is for command line and a few other utilities. Applications usually run in a graphics mode. Therefore, I cannot ask UEFI for a text mode as then I'm unable to run graphical applications. The issue instead must be solved by asking for a high-resolution graphics mode and then emulating text mode using TTF-fonts, something that is real slow, especially if the resolution is high.

Brendan wrote: No, the exact same native video drivers work fine regardless how the OS booted. What is different is the code in the boot loader that sets up a default video mode in case there isn't any native video driver.

No, because the video driver isn't loaded in the boot loader, but as the kernel boots. If there is UEFI, the kernel must load a text-mode emulation driver that uses graphics mode to emulate the text-mode API. There also must be an interface to communicate video-mode settings, as I'm not likely to write any native video drivers, rather a generic one per bit organisation.

Thus here are the differences:

BIOS boot:
1. System comes up in text mode
2. When an application requests a graphics mode, the video driver will call VBE to change video mode
3. The application focus switcher need to be aware of different video modes, calling VBE when focus is switched to an application that uses another video mode

UEFI boot:
1. The bootloader needs to set some specific resolution that matches the display
2. For debugging boot, there needs to be an emulation API that can write text in graphics mode without a TTF driver (must be self-contained)
3. When an application requests text mode, there need to be an API that can write text in graphics mode using the TTF driver
4. Switching will be a nop in regards to setting modes, but video memory content still must be saved/restored

I have no idea how Brendan thinks this can be transparent. I suspect he will offer his customers only a single graphics view (in the absense of multiple monitors).

rdos wrote:The issue instead must be solved by asking for a high-resolution graphics mode and then emulating text mode using TTF-fonts, something that is real slow, especially if the resolution is high.

So all the OSes running the terminal emulators in the graphics mode using TTF fonts must be very slow. I do not see that. Can it be so that your implementation of font rendering is to blame?

dozniak wrote:

rdos wrote:The issue instead must be solved by asking for a high-resolution graphics mode and then emulating text mode using TTF-fonts, something that is real slow, especially if the resolution is high.

So all the OSes running the terminal emulators in the graphics mode using TTF fonts must be very slow. I do not see that. Can it be so that your implementation of font rendering is to blame?

I don't see how one word memory accesses (text mode) could ever be slower (or not substantially faster) than font rendering and a huge amount of video output. BTW, I use FreeType for font rendering.

In other words, you just epically failed at science.

Not testing your assumptions.

rdos wrote:The application focus switcher need to be aware of different video modes, calling VBE when focus is switched to an application that uses another video mode

If you had a graphical program and a console program and you switch focus between them, I would not like the constant video mode switches. It surely has some overhead too. By keeping the "emulated" text mode, you only need to have that graphical video mode. The efficiency should not be a problem today. You would also have much more freedom to do font rendering in a way you like.

If not writing native video drivers (and even then because no one is going to support all the video cards), it would be very elegant to set graphical video mode in boot (BIOS or UEFI) and stick to it. As a bonus, you would not need to have BIOS calls (as far as I know, UEFI does not support run-time video mode switches) for setting the video mode when your OS is running.

A monitor's native resolution and LFB access -> Perfect. Sadly, the native resolution is not usually available for "non-standard" sizes without native video drivers.