Framework Overview Part 3

The framework runs in two major phases: Pre-EFI Initialization (PEI) and Driver Execution Environment (DXE). PEI includes the minimum amount of code needed to discover the minimum amount of memory needed to support a permanent memory stack. Modules in the PEI phase for a particular processor and chipset need to be rewritten when ported to another processor/chipset architecture. The portion of the code that implements PEI and the code for the PEI processor and chipset modules represent about 15 percent or less of a typical implementation.

On IA32 (including EM64T MDDE*), the system moves to protected mode very early in the PEI phase. PEI delivers great flexibility and is delivered around how memory is allocated and initialized. Initialization of most of the system's memory and sophisticated diagnostics and initialization of memory in high-end systems is deferred until after the PEI phase has completed and control is handed off to the EFI Driver Execution Environment (DXE), which is the second major phase in the framework. Initialization of silicon to support I/O devices is also deferred to DXE.

98% of the code needed to support an EFI-based boot under the framework is written in C.

DXE implements and exploits the EFI Driver Model. Drivers that are written according to the EFI 1.10 Specification work within the framework. EFI-defined GUIDs (Globally Unique Identifiers) provide modularity that supports version control and the integration of modules from multiple authoring organizations. EFI drivers and the framework are not compiled as a single image, nor are they statically linked; they are self-describing and discovered as the platform initializes. But EFI hardware drivers are not OS hardware drivers. While an OS driver has to exploit the full capability of the hardware and make it available to applications, DXE and EFI drivers are single threaded and simply have to support those features that are needed to boot the OS or set up and manage the platform. As a result, a practical implementation of the framework on a desktop PC platform, including drivers and a CSM (see below), fits in only 512 KB of flash memory.

For Intel® architecture-based systems, the framework loads itself above the 1 MB real-mode memory boundary to accommodate an optional Compatibility Support Module (CSM). CSM implementations can be tailored to platform requirements. A typical CSM is approximately 60 KB (~38KB compressed) of firmware that is specific to each participating vendor and is based on that Vendor's latest BIOS code base. A contemporary implementation of the framework on a PC includes a CSM for supplying services to operating systems that do not boot using EFI and for supporting legacy option ROMs on add-in cards. For legacy boot the framework initializes the platform's silicon and executes EFI drivers. Then control is transferred to the CSM, which supports the legacy OS boot.

The order in which drivers are executed in DXE is automatically governed by a number of (modifiable) heuristics and by self-described dependencies that sort the DXE drivers at runtime. I/O hardware that is powered on but not initialized can be activated by loading an EFI driver that supports the device. The result of this model is a building-block flexibility not available in traditional BIOS. Adding support for a USB disk automatically confers on a platform the ability to boot from that disk. A keyboard that is plugged in after DXE runs is recognized and is usable as a pre-boot console. As underlying hardware becomes more and more user-friendly and appliance-like, the firmware that is provided by the framework brings those attributes to the first part of the system experience.

The framework includes tools and utilities that use the inherent modularity of the framework to allow for very flexible packaging of firmware images. While PEI and DXE code must reside in nonvolatile memory along with drivers for storage that contains further EFI code, virtually all other code in firmware can be loaded from other devices. This flexibility can be exploited to reduce integration effort from firmware developed by geographically dispersed teams. A wide variety of firmware update policies can be implemented within the framework to match an OEM's service and support strategy.

The services provided by the framework are relatively simple. In addition to the ordered load and execution of EFI drivers, the framework provides pre-boot and runtime services that are required by the EFI 1.10 Specification, including a space-optimized implementation of the FAT32 file system.

For advanced diagnostics and manufacturing test automation, a TCP/IP stack and a localized version of the EFI command shell are also available. Intel recommends Microsoft Windows Preinstallation Environment* (WinPE) for Windows* Operating System provisioning.

BIOS was created by IBM in 1980 for the original PC in the context of a total expected production run of 250,000 systems. The original BIOS and its architecturally comparable successors have served the industry for over 20 years and will continue to do so through the transition to the framework. But the transition to the firmware architecture for our next 20 years has now begun.

1 | 2 | 3

back to top