Forgot your password?
typodupeerror
Intel Hardware

Demystifying UEFI, the Overdue BIOS Replacement 379

Posted by timothy
from the first-how-do-you-pronounce-your-name dept.
An anonymous reader writes "After more than 30 years of unerring and yet surprising supremacy, BIOS is taking its final bows. Taking its place is UEFI, a specification that begun its life as the Intel Boot Initiative way back in 1998 when BIOS's antiquated limitations were hampering systems built with Intel's Itanium processors. UEFI, as the article explains, is a complete re-imagining of a computer boot environment, and as such it has almost no similarities to the PC BIOS that it replaces."
This discussion has been archived. No new comments can be posted.

Demystifying UEFI, the Overdue BIOS Replacement

Comments Filter:
  • Re:Slashdot (Score:5, Informative)

    by Quantum_Infinity (2038086) on Thursday September 22, 2011 @10:19AM (#37479550)
    There's nothing wrong with Slashdot "articles" contradicting themselves, because they are not articles written by Slashdot staff. They are stories submitted by users and there's nothing wrong in contradiction arising out of two stories (which are basically opinions based on some facts) submitted by two different people.
  • Re:Slashdot (Score:5, Informative)

    by afidel (530433) on Thursday September 22, 2011 @10:23AM (#37479592)
    You seem to be missing the difference between UEFI and UEFI systems defaulting to only running signed boot loaders (possibly without a way for the end user to change the setting, though if I had to guess that won't be happening in anything but some tablets from companies like say Sony). As to EUFI being a complete re-imagining, not really. It's more of a proprietary implementation of the ideas from Sun's OpenBoot.
  • Re:Slashdot (Score:4, Informative)

    by l_bratch (865693) <l_bratch@yahoo.co.uk> on Thursday September 22, 2011 @10:23AM (#37479596) Homepage

    It seems that EFI may not be the brilliant thing that it is supposed to be. Somebody doing a lot of work involving it blogs here - http://mjg59.dreamwidth.org/ [dreamwidth.org] - and there are lots of depressing things to read there. To quote from the page:

    > It's an awful thing and I've lost far too much of my life to it. It complicates the process of booting for no real benefit to the OS. The only real advantage we've seen so far is that we can configure boot devices in a vaguely vendor-neutral manner without having to care about BIOS drive numbers. Woo.

  • Re:I don't know... (Score:5, Informative)

    by guruevi (827432) <evi@@@smokingcube...be> on Thursday September 22, 2011 @10:34AM (#37479724) Homepage

    BIOS has a LOT of limitations. >2TB hard drives, network boot, disk controllers, GPU's, IPMI, ... everything has to subvert the BIOS in some way which makes it mightily slow. My iMac boots with Lion in 7 seconds. My Linux machine takes 15 seconds just getting to Grub, my servers take up to 45 seconds to get to the boot loader.

    BIOS is ALWAYS hooked into 8086 mode (real mode) so at boot time you are limited by it's calls (such as 13h for disks) and that's hard and expensive to emulate on a non-x86 system (such as most Intel/AMD processors).

  • UEFI is good. (Score:4, Informative)

    by sgt scrub (869860) <saintium@yahoo.cMENCKENom minus author> on Thursday September 22, 2011 @10:35AM (#37479748)

    Secure boot is bad. What is mysterious about that? If you want to understand more, related to booting Linux, read these. UEFI secure booting [dreamwidth.org] x86 EFI boot stub [lwn.net]

  • I read the articles attached to this Slashdot story [slashdot.org], and my impression was that Microsoft could use UEFI secure booting to make it much harder for PC owners to install Linux alongside or in place of Windows. Red Hat develoer Matthew Garrett explains [dreamwidth.org]: "Microsoft requires that machines conforming to the Windows 8 logo program and running a client version of Windows 8 ship with secure boot enabled. [...] A system that ships with only OEM and Microsoft keys will not boot a generic copy of Linux."
  • Re:Slashdot (Score:5, Informative)

    by Bert64 (520050) <bertNO@SPAMslashdot.firenzee.com> on Thursday September 22, 2011 @11:29AM (#37480522) Homepage

    OSX uses GPT partition maps on x86 machines, they only had their own partition map on PPC systems. Current OSX running on x86 macs can still read disks which use the PPC partition map (as can linux), but can't boot from them.

    Linux has supported EFI for a long time, and Intel have been pushing EFI for a long time.... We would have had EFI many years ago, only MS never bothered to support it until very recently.

  • by Anonymous Coward on Thursday September 22, 2011 @11:31AM (#37480540)

    I've been dealing with UEFI-based servers for the past couple of years - IBM System x specifically - and while I see the potential for UEFI, it's still got a lot of teething pains in the Enterprise space as far as I am concerned. IBM was the first to basically put their entire x86 product line on UEFI-only hardware.

    However, I have actually encountered machine configurations that BIOS was unable to deal with (add-in PCIe cards utilizing all of the ROM memory space and bringing the machine to a halt, amount of RAM beyond what BIOS can handle natively, etc...) so I can see the requirement for a BIOS replacement.

    In its current incarnation in the servers I deal with, the architecture is essentially booting two full-blown microprocessors running code *BEFORE* the machine will even attempt to POST. The service processors in the current IBM machines (IMM - Integrated Management Module) are the first thing to fire up when power is applied to the server - since IMMs are small microprocessors in their own right (can't remember the make, but I remember hearing 100MHz speeds) loading what I believe is a micro-Linux kernel it takes time for these things to fire up. This process can take up to two (sometimes more) minutes before the power button stops blinking rapidly and goes to a normal "power off" blink. At this point you can turn the server on, which is when it will fire up the UEFI microprocessor and begin to load all of that code into the system. UEFI goes and "talks" to all of the internal hardware, loads profiles for devices, etc... during this phase. That can take up to another four minutes or so (it has gotten faster over the last two years) at which point the actual POST screen will display and you can either enter SETUP or allow the server to boot - note that add-in cards will have to load their own ROM as normal (if in Legacy Mode, which most of our server are due to OS limitations). Note that the more cards you put in a machine and more boot options you leave enabled, the longer this pre-POST initialization takes. I've seen reboot cycle times of over ten minutes in some instances, whereas the BIOS-based systems would complete that cycle in under two minutes.

    So here's a brief summary of the current state-of-the-art in server UEFI:
    PROS:
    * Allows configuration of peripheral devices from the SETUP screen.
    * Allows up to 1TB (much smaller in practive) of Option ROM space for add-in cards.
    * Allows for huge amounts of memory, and very large disk sizes.
    * In theory, allows for additional software to execute before the primary OS kicks in. Not really utilized in these machines.

    CONS:
    * Horribly slow boot cycles. Length of boot cycle dependent on amount of hardware in server. Had an IBM ATS Engineer tell me they had a machine in the lab that they plugged so much stuff into that it took 23 hours to POST.
    * Corrupt firmware or firmware updates is the kiss of death for many of these machines. While there are backup firmware spaces and the appropriate jumpers to recover, this does not always work as intended. We've had quite a few brand-new systems that had to have complete system planar replacements because the code wasn't executing right.
    * As these are actual mini-OSes running there are all kinds of strange quirks and odd behavior from the servers. Lots of troubleshooting involves resetting the service processors and praying they reboot properly in order to just get the server to POST normally.
    * Speaking of quirks, there are lots of situations where hardware failures are either false-positive failures or not indicated as an issue when they actually have faults. Troubleshooting on these machines becomes guesswork based on intuition rather than having a solid grip on what component is doing what.
    * Example: As the UEFI handles all of the components on the server, we have run into issues where bad code for the UEFI causes the Operating Systems to malfunction in strange ways, only to find the OS was reacting to thousands of repeated error messages being

  • Re:Slashdot (Score:3, Informative)

    by khraz (979373) on Thursday September 22, 2011 @11:35AM (#37480620)
    Some old P90s that I worked on had an Award or American Megatrends BIOS, which had a graphical (640x480x16) environment and supported a PS/2 mouse. I like UEFI, especially for the ability to boot external software directly (such as bios updaters or OS installers), but the bells and whistles could be done in BIOS, at least to a certain extent.
  • by SuricouRaven (1897204) on Thursday September 22, 2011 @12:01PM (#37480962)
    Other unavoidable delays:
    - Memory test. Well, you could avoid it, but you shouldn't.
    - Hard drive spin-up. You can detect the drives before this, but you can't read the partition table.
    - USB device detection. You need this for keyboards and bootable USB devices. And with the increasing use of tablet form factors, possibly in future for touchscreens.
    - Storage peripherals. A lot of storage controllers, espicially those of a RAIDy or networky nature (hardware-supported iSCSI, fibre channel) will need their own time to ready themselves and check connectivity and device integrity.
    Add all those together, and you're up to about what it takes for the BIOS today to run POST and hand over to the bootloader.

Nobody said computers were going to be polite.

Working...