Craig is an engineer for the Infrastructure Processor Division at Intel. He can be contacted at [email protected].
Every time a PC boots up, the basic input/output system (BIOS) initializes the system. This system boot process has remained virtually unchanged over the last 20 years, while other platform technologies have advanced significantly. The Extensible Firmware Interface (EFI) changes this (http://developer.intel.com/ technology/efi/). EFI is an open-standard specification that defines an interface between the operating system and platform firmware. This interface facilitates modifications and optimizations by board developers, opening the door to greater platform differentiation.
Intel-architecture-based platforms have evolved since the PC AT hardware of 1981. Many of the platform components—CPU, buses, video, audio, and operating systems—have seen tremendous technological changes (see Figure 1). The firmware, however, has been stuck in a 16-bit world, founded in a time when 640 KB of memory was "more than anyone would need."
BIOS is still 16-bit assembler code while the rest of the platform is 64-bit and high-level language capable. Helping firmware participate in the technological revolution, EFI supports 64-bit with preboot drivers and applications in C.
EFI is designed to be a pure API between the platform firmware and the operating system. BIOS has traditionally provided this functionality for 32-bit Intel architecture-based platforms.
EFI is an architecture-independent specification that defines the interfaces and structures the platform firmware must implement to successfully launch an operating system (Figure 2). Platform firmware-related information is abstracted using EFI data tables, while boot and runtime services can configure hardware and run applications before the OS launches. This capability supports many preOS features, such as initializing add-in cards, communicating with other devices on a network, and running diagnostics.
The Intel Platform Innovation Framework for EFI (the "Framework") is a production-ready implementation of EFI (http:// www.intel.com/technology/framework/). The Framework is designed to support multiple architectures, including IA-32-, Itanium-, and Xscale-based processors. This broad reach helps drive interoperability and communications across a wide range of networked devices, such as servers, appliances, storage, desktops, laptops, and PDAs.
Most new Intel boards that ship in 2005 support the Framework for EFI, and the expectation is that many embedded boards will be EFI based in 2006. Platform developers can get the Framework through participating vendors, including the likes of American Megatrends (http://www.megatrends .com/) and Insyde Software (http://www .insydesw.com/). The Framework is not generally available directly from Intel. However, to assist platform firmware engineers who write, build, debug, and test drivers and EFI applications within the Framework's preboot environment, Intel hosts a web-based collaborative software development community called "TianoCore" (http://www .tianocore.com/).
EFI provides embedded board vendors and system developers new flexibility. This includes the ability to boot with both legacy and new EFI methods. For example, the Framework supports an optional Compatibility Support Module (CSM) that launches existing BIOS code. This lets you utilize legacy BIOS to initialize peripherals instead of developing new software.
Unlike PCs, many embedded designs are not required to support a large number of legacy devices. A simple EFI implementation resembles a board-support package, with the minimum amount of code required to initialize the hardware and to load the operating system. Hardware boot times can be significantly decreased when legacy device support is not a concern.
Keeping up with modern times, board developers can write EFI drivers and services in high-level languages such as C. This should make EFI-compliant code rather portable between designs. As BIOS functions migrate from 16-bit assembly code to C, firmware projects can be assigned more easily to general programmers as opposed to relying on specialized BIOS programmers.
For instance, Examples 1 through 3 wait for a keypress and print the corresponding character to a console. The progression of these code snippets illustrate how the EFI facilitates the use of high-level languages. In Example 1, programmers need to be aware of the routines supported by the firmware. The implication is, you must be educated on the low-level details of the boot firmware.
In Example 2, efilib is added and lets users use more generic print instructions instead of knowing about the ConOut routine supported by the firmware. Also, the code to wait for a character input is abstracted by not requiring a call to the "Bootservices" firmware routine.
In Example 3, the atk_libc or "application toolkit" library lets the code be written with C instructions without any firmware-specific calls. This further abstracts the firmware from the program code.
The EFI model is modular, which increases software reusability and eases development resource planning. For example, a driver for initializing a USB port for one platform can easily be ported to other boards. A modular approach lets code development be partitioned into independent modules, enabling tasks to be divided amongst a team of programmers. Debug and testing can be conducted in a modular fashion as well.
EFI implementations, such as the Framework, support a development shell to ease software development. Within the shell, drivers can be invoked, tested and revised, and reinvoked without going through painful steps such as reprogramming on-board flash. The shell greatly reduces driver development time by improving programmer interactivity between the hardware and the software.
EFI also lets board vendors build more reliable systems. By writing EFI drivers that execute at the start of the boot sequence, hardware can be protected against intrusion even before the OS loads. Board developers have greater control over the hardware shortly after reset, allowing them to pursue enhancements such as decreasing the time to secure the board or running TCP/IP stacks to communicate with other network elements.
In addition, new services are enabled through the flexibility afforded by EFI. For example, EFI code can be loaded from a range of storage devices including disk, CD-ROM, and DVD as well as a remote location via a network. The ability to boot from a network source will usher in new platform-management features for IT departments as well as provide mechanisms to implement advanced diagnostics and manufacturing test automation.
IT managers will appreciate the improved network manageability enabled through EFI applications. It will be easier to handle out-of-box configuration issues because EFI applications can facilitate the management of computers by other computers. Instead of manual and serial configuration of new network devices, EFI enables network managers to automate this process. Because EFI is extensible to many types of devices, it helps networks better identify and control diverse machines and improve device interoperability and network reliability.
As opposed to the relatively closed nature of BIOS, EFI embraces modularity, high-level language, scalability, reusability, and enhanced debug environments to drive reduced development time and effort. Additionally, some embedded platforms may boot faster when firmware code is tailored to specific hardware configurations. In short, EFI is providing a new era of firmware efficiency.
The EFI Booting Sequence
Figure 3 illustrates a generalized boot sequence. This sequence is similar to BIOS today, but with the "hooks" provided by EFI for developers to add their own code.
Upon system reset, the CPU, chipset, and main memory are initialized. This code is likely to be supplied by the silicon manufacturer or a BIOS vendor. Initialization of other components such as an Ethernet controller may be handled by traditional BIOS code supplied by an Independent BIOS Vendor (IBV) or perhaps through the component manufacturer. This code runs in 16-bit, real-mode, which is limited to a small region of code. This phase is intended to be short, representing around 15 percent or less of a booting sequence. For 32-bit Intel architecture platforms, the CPU transitions to "protected-mode," which provides more memory and better support for high-level language programming.
During the second phase, the EFI boot manager starts running the EFI firmware. EFI drivers, protocols, and applications are loaded and executed, most of which are written in C. These drivers and applications allow platform developers to add new features and differentiate their boards.
Drivers and applications are modular and can be developed and tested in a development shell. The shell provides an interactive console interface, loads EFI protocols and drivers, and supports simple scripting and batch file capabilities. This environment helps developers debug and test drivers more efficiently, especially during the integration of new hardware and features.
Some EFI drivers, protocols, and applications will be available within an EFI development environment. EFI environments will provide code libraries to expedite platform firmware development.
There are two types of EFI firmware services—boot and runtime. Boot services terminate once the OS loads and never run again. Runtime services remain after the OS launches and today are limited to manipulating nonvolatile RAM and the real-time clock.
EFI applications execute platform-specific tasks within the booting sequence. Diagnostics, disaster recovery tools, and hard-drive-related operations are examples of tasks that can be implemented in a preOS environment. These routines will run in the development shell after the OS launches to make debugging easier.
During the third booting sequence phase, the OS loader is loaded. If the OS loader is unable to load its operating system properly, control can be issued back to the EFI boot manager and alternative action taken.
The last booting sequence phase occurs when the OS loads properly. The EFI boot services are terminated and the OS takes control.
Conclusion
EFI lets firmware evolve from a strict legacy-based BIOS structure to a more flexible and feature-rich environment. By putting more of the firmware control in the hands of the developers, EFI opens the door to new features and capabilities
DDJ
