Vincent Zimmer and Michael Rothman are engineers in the Software and Services Group at Intel. Suresh Marisetty is a software and systems architect at Intel focusing on security and manageability. They are the authors of Beyond BIOS: Developing with the Unified Extensible Firmware Interface
In essence, the modern day BIOS is one that has survived for more than 25 years. However, the program and instructions themselves have been dramatically changed and adapted over time to match the ever quickening pace of technological advancement. The goals of the Extensible Firmware Interface (EFI), and now the Unified Extensible Firmware Interface (UEFI), is to eventually replace the aging BIOS, learning from both the mistakes and successes of the past 25 years. This article provides an overview of the evolution of the Extensible Firmware Interface (EFI) to the Unified Extensible Firmware Interface (UEFI) and from the Intel Framework specifications to the UEFI Platform Initialization (PI) specifications.
When we discuss UEFI, we need to emphasize that UEFI is a pure interface specification that does not dictate how the platform firmware is built; the "how" is relegated to PI. The consumers of UEFI include but are not limited to operating system loaders, installers, adapter ROMs from boot devices, pre-OS diagnostics, utilities, and OS runtimes (for the small set of UEFI runtime services). In general, though, UEFI is about booting, or passing control to a successive layer of control, namely an operating system loader, as shown in Figure 1. UEFI offers many interesting capabilities and can exist as a limited runtime for some application set, in lieu of loading a full, shrink-wrapped multi-address space operating systems like Microsoft Windows+, Apple OS X+, HP-UX+, or Linux, but that is not the primary design goal.
PI, on the other hand, should be largely opaque to the pre-OS boot devices, operating systems, and their loaders since it covers many software aspects of platform construction that are irrelevant to those consumers. PI instead describes the phases of control from the platform reset and into the success phase of operation, including an environment compatible with UEFI, as shown in Figure 2. In fact, the PI DXE component is the preferred UEFI core implementation.
Within the evolution of Framework to PI, some things were omitted from inclusion in the PI specifications. As a result of these omissions, some subjects that were discussed in the first edition of Beyond BIOS, such as the compatibility support module (CSM), have been removed from the second edition in order to provide space to describe the newer PI and UEFI capabilities. This omission is both from a scope perspective, namely that the PI specification didn’t want to codify or include the CSM, but also from a long-term perspective. Specifically, the CSM specification abstracted booting on a PC/AT system. This requires an x86 processor, PC/AT hardware complex (for example, 8254, 8259, RTC). The CSM also inherited other conventional BIOS boot limitations, such as the 2.2-TB disk limit of Master Boot Record (MBR) partition tables. For a world of PI and UEFI, you get all of the x86 capabilities (IA-32 and x64, respectively), ARM+, Itanium, and future CPU bindings. Also, via the polled driver model design, UEFI APIs, and the PI DXE architectural protocols, the platform and component hardware details are abstracted from all consumer software. Other minor omissions also include data hub support. The latter has been replaced by purpose-built infrastructure to fill the role of data hub in Framework-based implementations, such as SMBIOS table creation and agents to log report status code actions.
What has happened in PI beyond Framework, though, includes the addition of a multiprocessor protocol, Itanium E-SAL and MCA support, the above-listed report-status code listener and SMBIOS protocol, an ACPI editing protocol, and an SIO protocol. With Framework collateral that moved to PI, a significant update was made to the System Management Mode (SMM) protocol and infrastructure to abstract out various CPU and chipset implementations from the more generic components. On the DXE front, small cleanup was added in consideration of UEFI 2.3 incompatibility. Some additions occurred in the PEI foundation for the latest evolution in buses, such as PCI Express+. In all of these cases, the revisions of the SMM, PEI, and DXE service tables were adjusted to ease migration of any SMM drivers, DXE drivers, and PEI module (PEIM) sources to PI. In the case of the firmware file system and volumes, the headers were expanded to comprehend larger file and alternate file system encodings, respectively. Unlike the case for SMM drivers, PEIMs, and DXE drivers, these present a new binary encoding that isn’t compatible with a pure Framework implementation.
The notable aspect of the PI is the participation of the various members of the UEFI Forum, which will be described below. These participants represent the consumers and producers of PI technology. The ultimate consumer of a PI component is the vendor shipping a system board, including multinational companies such as Apple, Dell, HP, IBM, Lenovo, and many others. The producers of PI components include generic infrastructure producers such as the independent BIOS vendors (IBVs) like AMI, Insyde, Phoenix, and others. And finally, the vendors producing chipsets, CPUs, and other hardware devices like AMD, ARM, and Intel would produce drivers for their respective hardware. The IBVs and the OEMs would use the silicon drivers, for example. If it were not for this business-to-business transaction, the discoverable binary interfaces and separate executable modules (such as PEIMs and DXE drivers) would not be of interest. This is especially true since publishing GUID-based APIs, marshaling interfaces, discovering and dispatching code, and so on take some overhead in system board ROM storage and boot time. Given that there’s never enough ROM space, and also in light of the customer requirements for boot-time such as the need to be "instantly on," this overhead must be balanced by the business value of PI module enabling. If only one vendor had access to all of the source and intellectual property to construct a platform, a statically bound implementation would be more efficient, for example. But in the twenty-first century with the various hardware and software participants in the computing industry, software technology such as PI is key to getting business done in light of the ever-shrinking resource and time-to-market constraints facing all of the UEFI forum members.
There is a large body of Framework-based source-code implementations, such as those derived or dependent upon EDK I (EFI Developer Kit version 1), which can be found on http://www.tianocore.org. These software artifacts can be recompiled into a UEFI 2.3, PI 1.2-compliant core, such as UDK2010 (the UEFI Developer Kit revision 2010), via the EDK Compatibility Package (ECP). For new development, though, the recommendation is to build native PI 1.2, UEFI 2.3 modules in the UDK2010 since these are the specifications against which long-term silicon enabling and operating system support will occur, respectively.