OSDev.org

The Place to Start for Operating System Developers
It is currently Mon May 22, 2017 1:25 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 5 posts ] 
Author Message
 Post subject: UEFI or Legacy BIOS Bootloader?
PostPosted: Mon Mar 13, 2017 10:40 am 
Offline
Member
Member

Joined: Thu May 28, 2009 2:41 pm
Posts: 70
Location: Germany
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?


Top
 Profile  
 
 Post subject: Re: UEFI or Legacy BIOS Bootloader?
PostPosted: Mon Mar 13, 2017 11:11 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 7892
Location: At his keyboard!
Hi,

Cjreek wrote:
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

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: UEFI or Legacy BIOS Bootloader?
PostPosted: Mon Mar 13, 2017 4:23 pm 
Offline
Member
Member

Joined: Thu May 28, 2009 2:41 pm
Posts: 70
Location: Germany
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.


Top
 Profile  
 
 Post subject: Re: UEFI or Legacy BIOS Bootloader?
PostPosted: Mon Mar 13, 2017 5:19 pm 
Offline
Member
Member

Joined: Mon Feb 02, 2015 7:11 pm
Posts: 228
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.

_________________
https://github.com/kiznit/rainbow-os


Last edited by kzinti on Mon Mar 13, 2017 5:48 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: UEFI or Legacy BIOS Bootloader?
PostPosted: Mon Mar 13, 2017 5:44 pm 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 7892
Location: At his keyboard!
Hi,

Cjreek wrote:
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.

Cjreek wrote:
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

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot] and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group