R.I.P BIOS. Your thoughts on UEFI over BIOS?

[HeXploiT]

I'd like to hear opinions on unified extensible firmware interface over basic input output system.

Sofar as I can tell the biggest difference between UEFI over BIOS is that it will have a GUI.
I have to admit when I first started reading about UEFI I was fearful that this might be a way to start robbing hardware enthusiasts of power over their PC but after thinking about it I realize it's not the platform that's dangerous but the engineer behind it.
If one looks at dell or other low-end/generic motherboard manufacturers there are many BIOS' that offer little to no control whatsoever over system hardware. On the other end of the spectrum are the high-end motherboards utilizing bios powers built for overclocking that have the ability to slow the earths rotation if one wishes.
Personally I'm looking forward to UEFI and am hopeful that it offers all the low-level power of BIOS plus a friendly, attractive & mouseable GUI.

 

[mfenn]

Actually newer Dell Optiplex's have a pretty fancy BIOS with a GUI and mouse support. I don't think it is UEFI though (if it is I guess there is a BIOS emulation layer).

 

[phait]

I'm looking forward to it, but I don't mind BIOS as it is. Here's an Asus vid on their's http://www.youtube.com/watch?v=EUvrXJ2fT_M&hd=1

 

[StrangerGuy]

Take an already simple-to-use BIOS by adding unneeded complex features...What can possibly go wrong?!

 

[HeXploiT]

Take an already simple-to-use BIOS by adding unneeded complex features...What can possibly go wrong?!

My original thought was, take windows 98 and add XP and what can possibly go wrong?

It may seem different but the bios IS an OS. In fact it is THE low level OS.

 

[ahenkel]

its cool for sure but to quote Garth "We fear change"

 

[yinan]

I dont like it. It makes the boot times for our servers really long. When we originally ordered our blade servers last year it took them 20 minutes to boot, and they didnt have all that much hardware in em.

 

[Fayd]

its cool for sure but to quote Garth "We fear change"

this.

 

[Mark R]

I think it's a very important, and badly needed innovation.

The problem with the BIOS is that it is deeply limited. It can only operate in 16 bit mode, and supports a maximum of 1 MB of RAM. There is a very limited support for BIOS extensions (e.g. used by LAN cards and RAID cards - so that they can boot).

While many LAN and RAID cards do support booting, their flexibility is limited - because the BIOS only has 1MB with which it has to initialize the hardware, load the LAN boot extension, start a TCP stack, mount the image, etc.

There are other problems too - Historically BIOS has only supported 2 TB drives. While it would be possible to make an extension to support > 2TB, it would be a big redesign of an obsolete concept. However, with EFI, > 2TB drive support is a simple driver add on (and in fact, is now a standard feature of a base EFI).

EFI is very important because it is a completely scalable and modular system. Instead of the BIOS (which is a single program customised to the hardware), the EFI contains a basic loader, and a series of modular drivers corresponding to the hardware. This means that an EFI system can install, boot and load an OS, from any EFI compliant RAID card (even if the OS doesn't have drivers). No assing around with the 'press F6 to install drivers' trick, to get your RAID card detected when installing Windows - basic level drivers will already have loaded during the EFI POST - and should run well enough to get the OS to the point where you can get the proper drivers.

Similarly, when installing an OS, the installer could download updates during the install - even if your LAN card isn't supported out of the box - because the EFI would already have loaded your LAN card's drivers.

A much hyped, but IMO, a much less useful feature - is the fact that your graphics card can load basic drivers during POST, so that the configuration app can run with a windowed/mouse GUI. However, this may also be useful for OS installers, or for low-level diagnostic tools (e.g. memory testing)

There is also flexibility to the boot process. BIOS can only boot a 'drive', by which it can load the boot sector on a specified drive, and start the OS (or OS multi-boot manager, if it has one). EFI can be configured to load any bootloader file from any partition, and specify parameters. E.g. if you need to tweak your linux boot settings (instead of editing the grub.cfg file and rebooting - you could just specify the parameters in the EFI console).

Basically, EFI brings plug-and-play to boot-up time - providing that chipset and add-on card manufacturers support it.

 

[mmntech]

Apple's been using EFI for four years now on all their systems. No issues there. BIOS works but it is severely outdated. Today's 3.33ghz Core i7 behemoths are basically still using the same booting technology as a 16mhz Intel 486 system from 1989.

It doesn't offer any advantages right now but it's more flexible in the future as Mark R pretty much summed up.

 

[Fox5]

EFI will be faster to boot than bios too since it'll hopefully eliminate a lot of device probing.

 

[yinan]

EFI is slow as shit to boot. I will take my 1 min startup thank you, and half of that is my RAID controller starting.

 

[Mark R]

EFI is slow as shit to boot. I will take my 1 min startup thank you, and half of that is my RAID controller starting.

It depends on the system. There are some HP systems with buggy UEFI startup which can take ages - but that isn't really a problem with EFI.

However, in an optimally configured system, an EFI boot should be dramatically faster than a BIOS boot (because EFI tells the OS exactly what hardware is available, the OS doesn't have to probe the hardware, which is very time consuming - and on modern systems, especially with SSDs, is the longest single part of the boot process).

There are problems when running EFI in a non-optimal way. The easiest way to do this is to run a non-EFI compatible OS. In this case, the EFI has to fall back to BIOS mode. The EFI has to unload all the drivers it loaded, and then go through the normal BIOS configuration process, before loading the OS. IBM claim that their UEFI cuts 60% off boot-time on their servers.

This gets worse if you have add-on cards (particularly HBAs) which have UEFI and BIOS firmware on them. During POST, the UEFI driver loads, causing the HBA to detect its drives. Then the UEFI initialisation takes place. Then the system has to fall back to BIOS mode - the UEFI HBA driver is unloaded, and the BIOS HBA firmware is loaded, which triggers another drive scan, before the OS boot process can commence. There are ways to improve this (e.g. disable the UEFI drivers for the HBA but leave the HBA BIOS enabled), if you have to run a non-EFI aware OS.

 

[yinan]

IBM is lying. That is the brand of server I am talking about.

 

[frostedflakes]

I dont like it. It makes the boot times for our servers really long. When we originally ordered our blade servers last year it took them 20 minutes to boot, and they didnt have all that much hardware in em.

I thought if anything it was supposed to reduce boot times. The issue must have been something else.

 

[Fox5]

I thought if anything it was supposed to reduce boot times. The issue must have been something else.

I could see it slowing down boot if it loads a bunch of drivers pre-boot. What's the point in probing devices and loading drivers in an environment that's just skipped right by 99% of the time?

Ideally, the UEFI should probably be as minimal as possible and just pass off control to the OS asap.

 

[Mark R]

I could see it slowing down boot if it loads a bunch of drivers pre-boot. What's the point in probing devices and loading drivers in an environment that's just skipped right by 99% of the time?

Ideally, the UEFI should probably be as minimal as possible and just pass off control to the OS asap.

There should be minimal device probing - because for UEFI, because the integrated devices will have their drivers integrated into the firmware ROM - so they can load instantly without the need to probe. Similarly, add-on cards can be queried and their drivers loaded. This has virtually no overhead.

The main drivers (keyboard, HDD, CPU, etc.) all have to load, so that the UEFI can find your drives, and find the OS boot code. BIOS does something similar.

The advantage of EFI is that the list of loaded drivers is passed to the OS - so that the OS knows the exact hardware configuration, and knows exactly what drivers to load, and which drivers not to load. So a UEFI compatible OS can skip the most time consuming step in the boot process.

With BIOS, the OS has to try to load every driver in its library - and see if it loads, or if it fails. If it fails, it tries the next driver, until its run out of drivers to try to load. Vista and Win 7 have tried to optimise this, by either not supporting these devices, or not attempting to scan for them unless the drivers are known to be required (because the device has been detected during installation - or has been manually installed since).

You're right, though. EFI has been criticized because it is basically a whole OS (albeit a stripped down OS) with its own driver model - and the amount of work that the OS does is relatively small. (Even if it does get skipped past, it does a modest amount of useful work - initializing all the hardware devices and starting the OS load process).