| vid, 2008-10-24 | Revision: 1.1 |
In the beginning, there was BIOS (I assume reader knows what BIOS is). Back in those times, processors were running in 16-bit mode, and RAM was architecturally limited to 1 megabyte. As the evolution went forth, came 32-bit, and later 64-bit x86 CPUs, amount of RAM was increasing, and new ways of accessing it were being developed. But BIOS remained same. This situation was far from ideal, since BIOS code was very limited, and operating system loader had to load kernel just with using the most basic BIOS services, from 20 years ago. Creating new standard seemed impossible on such diverse market. But it was done anyway.
It all has begun when Intel decided to develop 64-bit CPU. They made decision which was very good logically, but unfortunately not as good market-wise: to get rid of all ancient x86 features, drop entire x86 backward portability, and create completely new CPU architecture, named Itanium (IA64). That also meant that old BIOSes won't be running on it, and so opportunity opened for new standard interface between OS and hardware/firmware. This is how first steps took place in the half of 90s, to replace BIOS by new standard, called Extended Firmware Interface (EFI).
EFI is very different from old BIOS: it offers wide range of functionality even before OS starts loading, it is modular (you can add custom code or drivers), runs on various platforms, applications and drivers for it can be written in C not in Assembly, thus they are more portable, etc. Besides native CPU code, EFI supports custom byte–code, so drivers can be compiled so that they are portable between CPU architectures without need for recompilation.
First EFI specification (EFI 1.02) was published in 2000, but it was quickly withdrawn due to legal troubles. Next version (EFI 1.10) was published in 2002. Thanks to some already mentioned features, this specification wasn't limited just to Itanium architecture. It supported 32-bit x86 architecture as well.
To prevent undesireable diversity, and to keep EFI as sole BIOS replacement standard, all biggest market players joined together, adopted EFI 1.10 standard, and continued to develop it. This is how Unified EFI Forum was born. It includes Intel, AMD, AMI, Apple, Dell, HP, IBM, Microsoft, Phoenix, among others. These continue to develop United EFI (UEFI) standard, publish it, and support its spread over the market. However, you can often see term EFI used, when referring to UEFI standard.
Later, AMD created its own 64-bit architecture called AMD64, which unlike Itanium was backward compatible with x86. Intel called it EM64T or IA32e, later Intel 64, Microsoft calls it x64, usually it is called x86-64. Support for this architecture was included in UEFI 2.0 standard. In april 2008, ARM joined Unified EFI Forum, so we expect support these CPUs coming too.
At the time this article is written, latest version of standard is UEFI 2.1, which has few minor changes and features compared to UEFI 2.0. But overally, all versions of standard are very backwards compatible, so software and drivers written for very first version of EFI still run on latest boards.
Specifications for these standards can be found on Unified EFI Forum site (you have to fill small form in order to get access to them).
Next important thing for UEFI to become real standard, besides specification, is some implementation on real hardware. Intel had his own implementation of EFI 1.10 standard, called Platform Innovation Framework, or The Framework in short, or Tiano by project name. From this, in 2005 Intel released core part dubbed TianoCore, or EFI Development Kit (EDK). This project became open-sourced, and is now developed by companies and volunteers from all over the world. TianoCore only includes general code for implementing various version of UEFI standard, but it doesn't include any hardware-specific code, or code for initial booting phases.
Except TianoCore, there are few commercial implementation (based on TianoCore) which offer extra functionality and hardware support. EFI is default for Itanium-based platforms, so I won't mention these, and will only discuss situation on x86 market.
First, Intel is still developing its Tiano, and as far as I know, they were first company to release motherboard with x86-64 CPU and UEFI 2.0 support. Motherboards with UEFI 2.0 support I know about are DQ35JO, DQ35MP, DP35DP, DG33TL, DG33BU, DG33FB. Likely there are many boards with 32-bit UEFI support, but I wasn't interested in these, so I don't know any.
First company besides Intel to implement EFI was Insyde. They offer their implementation called InsydeH20, or lightweight version of it called InsydeDIY. It seems these only support UEFI 1.x standards, as Insyde doesn't ever mention UEFI 2.0 on their site, nor is x86-64 CPU on list of supported CPUs.
Phoenix Technologies supports UEFI 2.0 in it's brands SecureCore, TrustedCore, and AwardCore Tiano. They also offer development enviroment for driver programming, called UEFI Platform Initialization DDK: Phoenix TrustedCore, Phoenix SecureCore, Phoenix AwardCore Tiano.
AMI (American Megatrends Inc.) supports UEFI 2.0 in their codebase Aptio. The 32-bit implementation of Aptio can be found on Efinity motherboards (by MSI), and we are expecting UEFI 2.x implementation on MSI 45 boards very soon. In 2005 ASUS announced it will use Aptio, but I am not aware of any x86 ASUS product with EFI support.
AMI also offers source-level debugger for UEFI modules, compatible with TianoCore EDK.
There is also a very old project gnu-efi, which provides C header files for EFI 1.02 standard.
Since UEFI standard defines exact binary interface, standalone UEFI drivers and applications are portable between various implementations. All version of standard are also backward compatible. (I am not 100% sure about this, but the differences seem minimal).
The UEFI standard also supports old-style boot via 16-bit real mode code, so it can be used with OSes that don't have UEFI support, but in this case UEFI runtime drivers doesn't work. So, most motherboard have both oldschool BIOS and UEFI implementation.
Next important topic about UEFI is support for it in existing operating systems.
All OSes for Itanium processor support UEFI booting, since this technology is AFAIK only standard on Itanium platforms. As for x86 OSes, situation is more complicated:
Windows Vista supports UEFI booting since Service Pack 1, but only in 64-bit version. That means it requires board with UEFI 2.x implementation, which are hard to get today. Currently only motherboards with UEFI 2.x implementation are Intel boards, but when I tried to install Vista on one of those, it complained about lack of some ACPI support. We are expecting BIOS update with UEFI 2.x support coming from MSI in August 2008.
Also x86-64 version of Windows Server 2008 includes UEFI support.
Apple Max OS X for Intel processors uses EFI 1.10, but it only supports 32-bit EFI version, even on 64-bit CPUs.
As for Linux, both elilo and grub support UEFI for x86-32, x86-64, or Itanium CPUs (but I haven't tried this in practice).
It seems BSD operating systems in x86 versions don't support UEFI boot.
In general, companies which belong to Unified EFI Forum provide UEFI drivers for their hardware. But I have not ever seen these drivers provided standalone for download, and they are probably only offered as parts of "complete solutions" already mentioned.
To include some criticism of UEFI too, in following post Linus is having nostalgic moments about young rascals making up unnescessary new things, and about how back in those times everything was simpler.
Mark Larson, who worked as professional BIOS developer for last 14 years, joined our discussion and added criticism of UEFI. It is standard that hardware developers provide BIOS developers with reference implementation, that BIOS developers only have to integrate into their product. Implementation provided for UEFI was Tiano, that is written in C, not Assembler, which is still standard for BIOS development. Disadvantage of C over Assembler is that produced code is considerably bigger, and so motherboards require more Flash RAM, and their production price increases.
If I will have enough time and good mood for it, I will also write continuation to this article, describing working with UEFI in practice, and some UEFI coding too.
Continue to discussion board.
You can contact the author using e-mail vid@x86asm.net.
Visit author's home page.
| 2008-10-24 | 1.1 | Added Mark Larson's reaction; few minor fixes | vid |
| 2008-07-31 | 1.0 | First public version | vid |
(dates format correspond to ISO 8601)