2. Overview

2.1. Driver Execution Environment (DXE) Phase

The Driver Execution Environment (DXE) phase is where most of the system initialization is performed. Pre-EFI Initialization (PEI), the phase prior to DXE, is responsible for initializing permanent memory in the platform so that the DXE phase can be loaded and executed. The state of the system at the end of the PEI phase is passed to the DXE phase through a list of position-independent data structures called Hand-Off Blocks (HOBs). HOBs are described in detail in Volume 3 .

There are several components in the DXE phase:

• DXE Foundation

• DXE Dispatcher

• A set of DXE Drivers

The DXE Foundation produces a set of Boot Services, Runtime Services, and DXE Services. The DXE Dispatcher is responsible for discovering and executing DXE drivers in the correct order. The DXE drivers are responsible for initializing the processor, chipset, and platform components as well as providing software abstractions for system services, console devices, and boot devices. These components work together to initialize the platform and provide the services required to boot an operating system. The DXE phase and Boot Device Selection (BDS) phases work together to establish consoles and attempt the booting of operating systems. The DXE phase is terminated when an operating system is successfully booted. The DXE Foundation is composed of boot services code, so no code from the DXE Foundation itself is allowed to persist into the OS runtime environment. Only the runtime data structures allocated by the DXE Foundation and services and data structured produced by runtime DXE drivers are allowed to persist into the OS runtime environment.

PI Architecture Firmware Phases shows the phases that a platform with PI Architecture firmware will execute.

Fig. 2.2 PI Architecture Firmware Phases

In a PI Architecture firmware implementation, the phase executed prior to DXE is PEI. This specification covers the transition from the PEI to the DXE phase, the DXE phase, and the DXE phase’s interaction with the BDS phase. The DXE phase does not require a PEI phase to be executed. The only requirement for the DXE phase to execute is the presence of a valid HOB list. There are many different implementations that can produce a valid HOB list for the DXE phase to execute. The PEI phase in a PI Architecture firmware implementation is just one of many possible implementations.

2.2. UEFI System Table

2.2.1. Overview

The UEFI System Table is passed to every executable component in the DXE phase. The UEFI System Table contains a pointer to the following:

• UEFI Boot Services Table

• UEFI Runtime Services Table

It also contains pointers to the console devices and their associated I/O protocols. In addition, the UEFI System Table contains a pointer to the UEFI Configuration Table, and this table contains a list of GUID/pointer pairs. The UEFI Configuration Table may include tables such as the DXE Services Dependencies, HOB list, ACPI table, SMBIOS table, and SAL System table.

The UEFI Boot Services Table contains services to access the contents of the handle database. The handle database is where protocol interfaces produced by drivers are registered. Other drivers can use the UEFI Boot Services to look up these services produced by other drivers.

All of the services available in the DXE phase may be accessed through a pointer to the UEFI System Table.

2.2.2. UEFI Boot Services Table

UEFI Boot Services provides a summary of the services that are available through the UEFI Boot Services Table. These services are described in detail in the UEFI 2.0 specification. This DXE CIS makes a few minor, backward-compatible extensions to these services.

Table 2.2 UEFI Boot Services

UEFI Boot Services	Description
Task Priority	Provides services to increase or decrease the current task priority level This can be used to implement simple locks and to disable the timer interrupt for short periods of time These services depend on the CPU Architectural Protocol.
Memory	Provides services to allocate and free pages in 4 KiB increments and allocate and free pool on byte boundaries It also provides a service to retrieve a map of all the current physical memory usage in the platform
Event and Timer	Provides services to create events signal events check the status of events wait for events and close events One class of events is timer events and that class supports periodic timers with variable frequencies and one shot timers with variable durations These services depend on the CPU Architectural Protocol, the Timer Architectural Protocol, the Metronome Architectural Protocol, and the Watchdog Timer Architectural Protocol.
Protocol Handler	Provides services to add and remove handles from the handle database It also provides services to add and remove protocols from the handles in the handle database Additional services are available that allow any component to lookup handles in the handle database and open and close protocols in the handle database
Image	Provides services to load start exit and unload images using the PE COFF image format These services use the services of the Security Architectural Protocol if it is present
Driver Support	Provides services to connect and disconnect drivers to devices in the platform These services are used by the BDS phase to either connect all drivers to all devices or to connect only the minimum number of drivers to devices required to establish the consoles and boot an operating system The minimal connect strategy is one possible mechanism to reduce boot time

2.2.3. UEFI Runtime Services Table

UEFI Runtime Services provides a summary of the services that are available through the UEFI Runtime Services Table. These services are described in detail in the UEFI 2.0 specification. One additional runtime service, Status Code Services, is described in this specification.

Table 2.3 UEFI Runtime Services

UEFI Runtime Services	Description
Variable	Provides services to look up, add, and remove environment variables from nonvolatile storage. These services depend on the Variable Architectural Protocol and the Variable Write Architectural Protocol.
Real Time Clock	Provides services to get and set the current time and date. It also provides services to get and set the time and date of an optional wake-up timer. These services depend on the Real Time Clock Architectural Protocol.
Reset	Provides services to shut down or reset the platform. These services depend on the Reset Architectural Protocol.
Virtual Memory	Provides services that allow the runtime DXE components to be converted from a physical memory map to a virtual memory map. These services can only be called once in physical mode. Once the physical to virtual conversion has been performed, these services cannot be called again. These services depend on the Runtime Architectural Protocol.

2.2.4. DXE Services Table

DXE Services provides a summary of the services that are available through the DXE Services Table. These are new services that are available in boot service time and are required only by the DXE Foundation and DXE drivers.

Table 2.4 DXE Services

DXE Services	Description
Global Coherency Domain	Provides services to manage I O resources memory mapped I O resources and system memory resources in the platform These services are used to dynamically add and remove these resources from the processor s global coherency domain
Dispatcher	Provides services to manage DXE drivers that are being dispatched by the DXE Dispatcher

2.3. DXE Foundation

The DXE Foundation is a boot service image that is responsible for producing the following:

• UEFI Boot Services

• UEFI Runtime Services

• DXE Services

The DXE Foundation consumes a HOB list and the services of the DXE Architectural Protocols to produce the full complement of UEFI Boot Services, UEFI Runtime Services, and DXE Services. The HOB list is described in detail in the Volume 3 .

The DXE Foundation is an implementation of UEFI. The DXE Foundation defined in this specification is backward compatible with the UEFI 2.0 specification. As a result, both the DXE Foundation and DXE drivers share many of the attributes of UEFI images. Because this specification makes extensions to the standard UEFI interfaces, DXE images will not be functional on UEFI systems that are not compliant with this DXE CIS. However, UEFI images must be functional on all UEFI-compliant systems including those that are compliant with the DXE CIS.

2.4. DXE Dispatcher

The DXE Dispatcher is one component of the DXE Foundation. This component is required to discover DXE drivers stored in firmware volumes and execute them in the proper order. The proper order is determine by a combination of an a priori file that is optionally stored in the firmware volume and the dependency expressions that are part of the DXE drivers. The dependency expression tells the DXE Dispatcher the set of services that a particular DXE driver requires to be present for the DXE driver to execute. The DXE Dispatcher does not allow a DXE driver to execute until all of the DXE driver’s dependencies have been satisfied. After all of the DXE drivers have been loaded and executed by the DXE Dispatcher, control is handed to the BDS Architectural Protocol that is responsible for implementing a boot policy that is compliant with the UEFI Boot Manager described in the UEFI 2.0 specification.

2.5. DXE Drivers

The DXE drivers are required to initialize the processor, chipset, and platform. They are also required to produce the DXE Architectural Protocols and any additional protocol services required to produce I/O abstractions for consoles and boot devices.

2.6. DXE Architectural Protocols

The following table provides a summary of the Section 12. The DXE Foundation is abstracted from the platform through the DXE Architectural Protocols. The DXE Architectural Protocols manifest the platform-specific components of the DXE Foundation. DXE drivers that are loaded and executed by the DXE Dispatcher component of the DXE Foundation must produce these protocols.

Table 2.5 DXE Architectural Protocols

Protocol Name	Description
Security Architectural	Allows the DXE Foundation to authenticate files stored in firmware volumes before they are used
CPU Architectural	Provides services to manage caches manage interrupts retrieve the processor s frequency and query any processor based timers
Metronome Architectural	Provides the services required to perform very short calibrated stalls
Timer Architectural	Provides the services required to install and enable the heartbeat timer interrupt required by the timer services in the DXE Foundation
BDS Architectural	Provides an entry point that the DXE Foundation calls once after all of the DXE drivers have been dispatched from all of the firmware volumes This entry point is the transition from the DXE phase to the Boot Device Selection BDS phase and it is responsible for establishing consoles and enabling the boot devices required to boot an OS
Watchdog Timer Architectural	Provides the services required to enable and disable a watchdog timer in the platform
Runtime Architectural	Provides the services required to convert all runtime services and runtime drivers from physical mappings to virtual mappings
Variable Architectural	Provides the services to retrieve environment variables and set volatile environment variables
Variable Write Architectural Protocol	Provides the services to set nonvolatile environment variables
Monotonic Counter Architectural	Provides the services required by the DXE Foundation to manage a 64 bit monotonic counter
Reset Architectural	Provides the services required to reset or shutdown the platform
Real Time Clock Architectural	Provides the services to retrieve and set the current time and date as well as the time and date of an optional wake up timer
Capsule Architectural Protocol	Provides the services to retrieve and set the current time and date as well as the time and date of an optional wake up timer

2.7. Runtime Protocol

Status Codes Runtime Protocol provides a summary of the runtime protocol for status codes.

Table 2.6 Status Codes Runtime Protocol

Status Code Runtime Protocol

Provides the services to send status codes from the DXE Foundation or DXE drivers to a log or device.