A number of people have asked me why they should care about EFI. What does EFI bring to the table that BIOS-based systems currently don't have? It's a good question, because no one seems to be clearly answering this. Most whitepapers and presentations talk up EFI like it's the greatest thing ever, but don't say what it actually gives the end user.
At my employer, we have been discussing EFI as a development platform for future CPU projects. I actually work on BIOS source code as part of my daily life. I've had long talks with engineers at two major BIOS vendors about EFI. I have also seen EFI in action.
EFI brings some advantages to the table, but they're mostly meaningless from a typical end-user point of view. EFI is really for the benefit of the BIOS engineer and the hardware maker (people like me). Your average user (and even most power users) would never be able to tell the difference between a BIOS-based or EFI-based system.
EFI tries to make PC firmware development and evolution a collaborative effort between vendors. A lot of current BIOS components were implemented by one vendor, and then turned into a standard much later. This lead to a lot of BIOSes with buggy or incompatible implementations.
EFI is written in C instead of x86 assembler. The source tree for a typical PC BIOS is tens of thousands of lines of x86 assembler. One of the BIOS source trees I work with has 671 .ASM files.
As time goes on, the BIOS codebase gets more and more unwieldy. Also, it's getting harder and harder for BIOS companies to find employees who know x86 assembler. Some BIOS vendors have actually implemented their own higher-level languages, which auto-generate x86 assembly at run-time.
EFI allows for platforms other than x86. EFI can also work on Itanium and XScale systems. The idea being that Intel can use the same firmware across all of it's different platforms.
EFI makes it possible to have CPU-independent firmware inside a peripheral board. Say you buy a SCSI controller today. It has some Option ROM firmware onboard. If you try to put that same board inside an IA-64 system, the firmware won't load. The SCSI vendor has to sell two versions of the board, one with x86 BIOS firmware, and one with IA-64 firmware.
Under EFI, add-on cards use a bytecode-based firmware. It is Just In Time compiled for your CPU during boot. This means that one firmware can work on any platform.
EFI establishes a consistent, modular structure for supporting new hardware. What does that mean? Well, suppose SMSC comes out with a new Super I/O chip. Now, BIOS vendors need to add support for the new Super I/O into their codebases. The internal BIOS structure is totally different between a Phoenix, Award, AMI, General Software, and Insyde BIOS. This means each BIOS vendor has to implement their own Super I/O support module.
Under EFI, the Super I/O vendor can release an EFI "driver" for their new chip. Now, all of the BIOS vendors can simply grab that driver and drop it into their codebase.
The same thing applies to new chipsets from Intel, AMD, Via, etc. Firmware support for new chipsets can be done by the chipset maker instead of the BIOS vendor.
The end user can load EFI drivers into the motherboard firmware. Using the SCSI controller example from earlier. Instead of putting an option ROM on the SCSI controller, they can give you a disk with the EFI driver on it. You can take this disk and load the EFI driver into your motherboard.
By not having to put an option ROM on the board, the hardware maker can cut down on costs. However, this seems to make thing more inconvenient for the end user.
It also means you aren't solely dependent on your motherboard maker for BIOS updates. Say Intel discovers a bug in the EFI driver for one of their chipsets. Well, they can put the updated driver on their web site, and customers can download and install the update without having to worry about the motherboard vendor. (Personally, I think this will make support issues a lot more complicated.)
EFI has a command shell. The EFI shell replaces some of the functionality of the DOS prompt and the Windows Recovery Console.
You can use the EFI shell to reformat and repartition your drives before you can install. You can also use it to recover files from a failed OS install. You can do things like verify the filesystem.
One little gotcha: Out of the box, EFI only supports FAT32 partitions. So, good luck getting data from your NTFS or EXT3 partitions. In theory, someone can develop and EFI driver for those filesystems. To date, I haven't seen one though.
EFI has a built in web browser. Say you want to install Windows onto your new computer with an SATA RAID controller. Unfortunately, you need to download some drivers before Windows can see the RAID controller. Great, how do you download them? You have a computer with a blank hard drive.
Today, you have to go to another computer to get the drivers you need. Under EFI, you can just download those drivers using the EFI browser. And since EFI understands filesystems, you can save them right to the hard drive.
The EFI web browser can also be useful in web terminal boxes, where all you need is a web browser. You don't even need to install an OS on the system.
EFI allows you to develop your own firmware applications. For a simple embedded system where you don't need a full OS, you can just write your app in EFI.
Previous Topic
