techdoc

boot process on UEFI platforms

created onNovember 13, 2025

I’ve always been running Intel CPU’s, so I focus on the Intel platform here. Intel and AMD do take slightly different approaches during the early boot sequence, but the overall picture is the same.

I deliberately leave out the parts of a secure boot like with Intel’s Boot Guard modes Verified or Measured Boot to keep the article shorter.

I focus only on the ’normal’ boot sequence, omitting both recovery boot and resuming from any suspend mode. Also, I do not touch on other boot modes, like cold boot vs warm boot, or boot on flash update.

UEFI boot stages

An UEFI boot sequence is divided into the following six stages:

  • SEC – Security Stage
  • PEI – Pre EFI Initialization
  • DXE – Driver Execution Environment
  • BDS – Boot Device Selection
  • RT – Runtime, OS Runtime
  • AL – Afterlife, OS shutdown
UEFI boot sequence

UEFI boot sequence
credits: adapted from UEFI Platform Specification 1.9, 2. Overview, Fig. 2.2 PI Architecture Firmware Phases
click on image to enlarge

x

Most sources apart from the official UEFI docs do not contain the AL stage. Strictly speaking, the AL stage is not part of the UEFI boot sequence, but part of the whole UEFI life cycle.

The six boot stages are referred to as the PI (Platform Initialization).

interlude – hardware back then and now

In the old days, there were three main distinct chips able to execute operations on a motherboard:

  • northbridge – for performance-critical tasks like controlling main memory and video.
  • southbridge – for less performance-critical tasks like slower I/O, audio and several buses.
  • CPU

Later, the northbridge was integrated into the CPU. Intel renamed the southbridge to PCH (Platform Controller Hub). If we want to include AMD, we can just call the latter ’the chipset'.

On power on, the CPU is stuck in reset and no execution takes place there. The PMC (Power Management Controller) delivers power to the CSME (Converged Security and Manageability Engine). The CSME, containing a tiny i486-like IP block, starts executing code from the reset vector of its ROM code. This ROM code acts as the Root-of-Trust for the entire platform. After a few other steps I’m skipping here, the CSME requests from the PMC to bring the CPU out of reset. The boot sequence continues with the IBB (Initial Boot Block).

SEC – Security Stage

Intel CPUs ship with built-in µCode (microcode). But improved versions of the µCode might be available or the µCode currently in the system’s flash memory is known to contain bugs. The CPU starts the SEC phase by checking the system flash memory for µCode updates. New µCodes images are pulled out of the flash and the new microcode starts running.

The µCode loads a component called the ACM (Authenticated Code Module) of the flash. The ACM is still Intel code.

starting the CPU in real mode, switching to protected mode

Modern CPUs are connected to an SPI (Serial Peripheral Interface) flash memory that contains the initial boot code. The CPU can execute code directly from the SPI flash memory. The CPU starts the SEC phase by executing code from the SPI’s reset vector 0xfffffff0. Address 0xfffffff0 is the legacy reset vector for the 80386 CPU. The CPU is running in real mode, which comes with a set of constraints like no memory protection and a memory limit of 1 MB. Also, at the reset vector, the platform can execute only in a constrained state and has no concept of components such as RAM. Not really cool if you want to execute code above bare essential stuff. In the next step the CPU is switched to protected mode.

setting up CAR (Cache as Ram) memory

The memory available in the CPU caches is configured via MTRRs (Memory-Type Range Registers) into a CAR (Cache-as-RAM) with ’no-eviction mode’. This mode will ensure that reads/writes to the CPU caches do not lead to an attempt to evict the data to RAM, which is not under control of the CPU yet. The available memory at this point is limited to the memory of the CPU caches, but this is usually large enough to hold the entire firmware in memory and still have enough memory for execution environments (heap, stack and data regions). I’m still running an i7-8700 with an L3 cache of 12 MB. The Core Ultra 9 Series CPUs variants, released in October 2024, come with a L3 cache of 36 MB and a L2 cache of 40 MB, summing up to a total cache of 76 MB. Note that not all the firmware image is loaded into the CAR.

The UEFI spec states that as an alternative to using CAR, the CPU’s On-Die SRAM, if available, can be used as the temporary memory.

loading and executing the IBB (Initial Boot Block)

The Initial Boot Block (IBB) is the first chunk of OEM provided BIOS code executed by ACM. The IBB verifies and executes the OBB (OEM Boot Block). The OBB then verifies and executes the next code to run, which is an UEFI application – usually it is a boot manager. The IBB runs not only during the SEC stage, but overlaps into the PEI (Pre EFI Initialization) stage.

During the SEC stage the initial handling of the various sleep states that the machine could have resumed from is performed to alter the boot sequence accordingly. Going into details here would mean to go into some details of ACPI, which is massively complex in itself and that would be beyond the scope of this article.

PEI - Pre-EFI Initialization

PEI Foundation

base-hardware setup with PEIMs

The PEI foundation is a binary without any dependency and is responsible for executing the PEIMs (Pre-EFI Initialization Modules). A PEIM can be dependent on other PEIMs. The PEI Foundation revolves much around the PEI Dispatcher, which resolves those dependencies in order to execute the PEIMs in the appropriate order.

The PEIMs in turn are responsible for all aspects of base-hardware initialization, such as setting up the main RAM, CPU and chipset initialization, I/O initialization (i.e., disk controllers), system buses init, and the setup of other core functions of the platform.

PEIMs can communicate to each other though PPIs (PEIM-to-PEIM Interfaces). PEIMs and PPIs can reside in the BFV (Boot Firmware Volume) or other FVs (Firmware Volumes). It is mandatory that the SEC infrastructure code and PEI Foundation code are not linked together into one binary in the ROM.

The SEC (Security) phase calls the entry point to the PEI Foundation with some information, including:

  • size and location of the BFV and its mapping into a processor-accessible memory, and other boot-critical FVs (Firmware Volumes).
  • a set of PPIs (PEIM-to-PEIM Interfaces).
  • size and location of the temporary RAM.
  • size and location of the stack and the temporary RAM available for use by the PEI Foundation.

The PEI Foundation begins operation using the CAR that contains the initial call stack from the SEC phase.

The PEI stack is available for subsequent PEIM invocations. PEIMs can create sequential data structures that can be used in later boot stages, called HOBs (Hand-Off Block). The PEI heap is used for PEIM memory allocations and HOBs.

PEI Foundation services

During the PEI Foundation, some services that are also available to later stages are set up. Because the PEI Foundation stage has no main RAM available until nearly the end of the stage, the services created during the PEI Foundation can’t be as functionally rich as services created during later stages.

Among the services are:

  • boot mode services – manages the normal boot mode, boot modes from resume (S3 - hibernate to RAM, S5 - hibernate to disk) and the correlating diagnostics
  • HOB services – can be used by later PI stages to locate relevant data.
  • FV services – to find PEIMs and other firmware files in the flash memory.
  • PEI memory services – memory management services for use both before and after main RAM has been set up.
  • status code services – simple error code reporting, i.e. on port 080h or a serial port. This is where the BIOS status codes come from.
  • reset services – to initiate a warm or cold system reset.

main RAM setup

There can be no memory writes to the main RAM until it is initialized by the corresponding PEIM. When the main RAM is set up, PEI Foundation copies the call stack located in CAR into a segment of the main RAM. If necessary, the size of the call stack is expanded to support the subsequent operation, including those of the DXE.

In addition to the call stack, the PEI Foundation copies the following from CAR to main RAM:

  • PEI Foundation private data
  • PEI Foundation heap
  • HOB list
  • Installed Firmware Volumes

Any main RAM used by the PEI Foundation is described in a HOB, which the PEI Foundation creates. Interestingly, the main RAM is set up very late in the PEI stage.

In the UEFI docs, the system’s main RAM is referred to as permanent memory.

The PEI transfers execution to the DXE stage with a HOB list containing the following information:

  • boot mode
  • memory that was set up in the PEI stage.
  • description of the system memory that was initialized by the PEI stage
  • information about the firmware devices that were discovered in the PEI stage.

DXE – Driver Execution Environment

DXE Foundation

The DXE Foundation is completely independent of the system’s hardware (CPU, chipset, etc.) so it is completely portable. The DXE Foundation only depends on the HOB list created in the PEI stage, thus any other data in RAM can be cleared. The HOB list is treated as read-only data and is never updated during the DXE stage.

HOB details

The HOB list starts with a PHIT Hob (Phase Handoff Information Table), which contains the following information:

  • HOB list
  • some amount of free memory
  • potentially some logical memory allocations

The base address of the HOB list is passed to the DXE Foundation in the parameter , and the PHIT HOB field specifies the end of the HOB list.

The CPU HOB contains the field , which defines the number of address bits that the processor can use to address memory resources. The CPU HOB also contains the field which defines the number of address bits that the processor can use to address I/O resources. This information enables the DXE phase to operate completely platform-agnostic (in the sense of CPU platform).

Using the PHIT and the CPU HOB, the DXE Foundation can relocate teh HOB list to a new location in system memory and can initialize the GCD (Global Coherency Domain) memory space map as well as the GCD I/O space map.


HOB List

HOB List
credits: adapted from UEFI Specification 1.9, 9. DXE Foundation, Fig. 9.1 HOB List

UEFI System Table

The DXE Foundation produces the UEFI System Table, which is passed to every executable component in the DXE stage. The UEFI System Table contains:

  • UEFI Boot Services Table – contains services that are only available before OS runtime.
  • UEFI Runtime Services Table – contains services that are available before and during OS runtime.
  • pointers to the console devices and their associated I/O protocols
  • a pointer to the UEFI Configuration Table, which 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.
UEFI System Table

UEFI System Table
credits: adapted from UEFI specification 1.9, 9. DXE Foundation, Fig. 9.2 UEFI System Table and Related Components
click on image to enlarge

x

DXE Driver Dispatcher

Much like the PEI Foundation revolving around the PEI Dispatcher, the DXE Foundation revolves around the DXE Driver Dispatcher which is a component of the DXE Foundation. The DXE Driver Dispatcher discovers DXE drivers stored in firmware volumes and executes them in the proper order.

DXE Driver classes

There are two DXE Diver classes.

Early DXE Drivers

The Early DXE Drivers provide basic services, like CPU, chipset and platform initialization. They also produce the DXE Architectural Protocols that are required by the DXE Foundation to produce the UEFI Boot Services and UEFI Runtime Services of the UEFI System Table.

The order by which the Early DXE divers are executed is determined by:

  • an a-priori file – contains a list of DXE drivers that have to be executed in the order they appear in the a-priori file, without resolving any dependency. These drivers are executed before any other drivers.
  • driver dependencies – the DXE Driver Dispatcher resolves the dependencies of every driver loaded after the drivers in the a-priori-file in order to execute the DXE drivers in the appropriate order.
  • “emergency patch” DXE driver dependencies – these dependency expressions can declare that a DXE driver is to be loaded and executed immediately before or immediately after another specific DXE driver.

Late DXE Drivers

The UEFI spec refers to drivers of this class as “DXE Drivers that Follow the UEFI Driver Model”, which is quite long and I can’t wrap my head around the meaning of this class name. I wonder why this class is not simply called Late DXE Drivers in the UEFI spec, which is the class name I’m shamelessly using here.

Late DXE Drivers do not touch any hardware resources, but register a Driver Binding Protocol interface in the handle database. The set of Driver Binding Protocols produced by the late Drivers is used in the BDS (Boot Device Selection) stage to connect the drivers to the devices that are required for console access and boot devices access.

When a specific controller is needed, an EFI boot service is used to connect to the controller, along with the EFI Driver Binding Protocol services to identify the best drivers for a controller. When the EFI boot service has identified the best drivers for a controller, the start service in the EFI Driver Binding Protocol is used to start each driver on the controller. Once a controller is no longer needed, it can be released with an EFI boot service, which calls the stop service in each EFI Driver Binding Protocol to stop the controller.

Late DXE Drivers do not have dependencies. DXE drivers without dependencies are not dispatched by the DXE Dispatcher until all DXE Architectural Protocols have been installed. In order to speed up boot time, as much initialization as possible is deferred to the Late DXE Drivers.

Additional DXE Driver Classifications

DXE drivers can also be classified by the kind of service they produce:

  • Boot service drivers – provide services that are available before OS runtime. When the OS has booted, all the memory used by boot service drivers is released for use by the OS.
  • Runtime drivers – provide services that are available both before and during OS runtime. All services in the UEFI Runtime Services Table are produced by runtime drivers.

BDS – Boot Device Select

After all DXE drivers whose dependencies have been satisfied have been loaded and executed, the DXE phase hands over control to the BDS phase.

The BDS phase is responsible for the following:

  • Loading device drivers – existing drivers are used to initialize any remaining necessary hardware.
  • Initializing console devices – this makes it possible to use an UEFI Shell or select a boot option from an OS bootlader menu.
  • Attempting to load and execute boot selections of the firmware boot manager. The boot selections are UEFI images.

firmware boot manager loads and starts UEFI apps

In the BDS phase, the firmware boot manager loads UEFI drivers and UEFI applications like an UEFI Shell or UEFI OS bootloaders in an order defined by the global NVRAM variables. The boot order in which to invoke the UEFI drivers and UEFI applications is also defined by the global NVRAM variables and is mandatory for normal boot. The platform firmware may add extra boot options or remove invalid boot options from the boot order list.

The firmware can load UEFI drivers and UEFI apps from any file on an UEFI-defined file system, from media that contain an UEFI OS loader, or through the use of an UEFI-defined image loading service, i.e. for network boot. To load UEFI image apps from block devices, UEFI requires UEFI-defined system partition. An UEFI-defined system partition does not require any change to the first sector of a partition, so it is possible to set up media that boot on both legacy architectures and UEFI platforms.

On PC-compatibles, UEFI requires a VFAT (Virtual FAT) system partition. VFAT is FAT32 with an added support for long filenames with a maximum of 255 Unicode characters.
For VFAT, the maximum total path length, including all directories and the filename, is also around 255 characters.

NVRAM variables to control firmware bootmanager operation

On initialization the firmware boot manager reads the NVRAM variables, whose values comprise the boot load options:

variable name attributes description
Boot#### NV A boot load option. Specifies an OS to load.
BootCurrent The boot option that was selected for the current boot.
BootNext NV The boot option that is to be booted next after the current boot.
BootOrder NV Defines the order in which options are processed.
BootOptionSupport The types of boot options supported by the boot manager. Should be treated as read-only.
Driver#### NV A driver load option. Specifies a driver to load.
DriverOrder NV Defines the order in which the options are processed
Key#### NV Defines a hot-key for a option.
PlatformRecovery#### NV? Platform-specified recovery options. Only modified by firmware and are read-only to the OS.
SecureBoot Indicates if the platform firmware is operating in Secure boot mode (1) or not (0). Should be treated as read-only.
SysPrep#### NV A System Prep application load option.
SysPrepOrder NV Defines the order in which the load options are processed.
Timeout NV The firmware’s boot managers timeout, in seconds, before initiating the default boot selection.
OsIndications NV Set by the OS to request the firmware to enable certain features or to take certain actions.
OsIndicationsSupported Indicates the firmware features and actions supported by the firmware to the OS.
  • #### – four digit hexadecimal number with leading zeros. For digits A - F, upper case is mandatory. The commonly used prefix for hexadecimal numbers is omitted.
  • NV – nonvolatile variable, values are persistent across system resets and power cycles.
  • in the UEFI spec 2.11, is listed without the NV attribute. As every other var is listed as NV, I guess is NV, too. Right now, I don’t want to sift through all the errata.
  • Some NVRAM variables also contain a human-readable string that can be displayed to the user, i.e., in a menu.
  • Some NVRAM vars like the options can also contain load options that are passed directly to the UEFI image. The platform firmware does not care about these load options, but just passes them to the UEFI image. I.e., such information can be used to define the location of the OS kernel if it is different from the location of the UEFI OS loader.
In the UEFI spec 2.11, Table 3.1 Global Variables lists every variable with the attributes BS (only available before EFI_BOOT_SERVICES.ExitBootServices() is called) and RT (available before and after ExitBootServices() is called), which is a contradiction in itself. Which is why I left out the BS and RT attributes.

modifications to NVRAM variables

Modifications to NVRAM variables are guaranteed to take effect in the next system boot. Firmware boot manager implementations may improve on this guarantee, so that changes that effect boot manager behaviour take effect immediately for subsequent accesses to these variables without requiring any form of system reset. An exception to this is the variable. Changes to this variable are only guaranteed to take effect after the next system reset.

firmware boot menu

The design goal of UEFI was to have a boot menu that be provided by the platform firmware. The UEFI spec specifies only the NVRAM variables used in boot options but leaves the implementation of the boot menu system to the firmware supplier.

firmware manager boot sequence

  • the options are processed in the order defined by
  • the option is processed. The boot manager clears the BootNext variable before transferring control to the BootNext boot option.
  • After the BootNext boot option is tried, the options are processed in the order defined by . A variable also contains a pointer to the hardware device and to a file that contains the UEFI image that can be loaded from the hardware device, i.e. from a harddisk, or a USB-stick, or from the network.
  • If booting a options returns with a status of , and the platform firmware supports a boot manager menu, and if firmware is configured to boot in an interactive mode, the boot manager will stop processing the variable and present a boot manager menu to the user. If any of the above-mentioned conditions is not satisfied, the next in the variable will be tried until all boot options in have been tried.
  • If all entries of BootNext and (in order defined by ) have been processed without success, or if the firmware has been instructed to attempt boot order recovery, the firmware attempts boot option recovery.

launching Boot#### options with hot keys

The firmware boot manager may support launching a option using a special key press or a combination of several keys being pressed. If so, the boot manager reports this capability by setting in the global variable.

The key information is read from the console. Any key press is compared the defined NVRAM variables. For any match, it is verified that the load option specified is valid and, if so, the specified option is launched immediately. The order in which the variables are checked is implementation-specific.

The boot manager may ignore variables where the hot keys specified overlap with those used for internal firmware boot manager functions. The firmware boot manager may delete such keys.

Unfortunately, the UEFI specification is not clear on how hot keys for launching a option are defined.

boot option default file pointer and booting from removable media

If the option does not contain a pointer to a file, the UEFI firmware generates a default pointer in the form , where defines the PE32+ image format architecture. Each file only contains one UEFI image type. A medium (i.e., a USB-stick) can provide several UEFI image types in the form of to support booting for several architectures. The following table lists the UEFI image types for several architectures:

architecture UEFI image file name PE executable machine type
32-bit BOOTIA32.EFI 0x14c
x64 BOOTx64.EFI 0x8664
Itanium architecture BOOTIA64.EFI 0x200
AArch32 architecture BOOTARM.EFI 0x01c2
RISC-V 32-bit architecture BOOTRISCV32.EFI 0x5032
RISC-V 64-bit architecture BOOTRISCV64.EFI 0x5064
RISC-V 128-bit architecture BOOTRISCV128.EFI 0x5128
LoongArch32 architecture BOOTLOONGARCH32.EFI 0x6232
LoongArch64 architecture BOOTLOONGARCH64.EFI 0x6264

The PE Executable machine type is contained in the machine field of the COFF file header as defined in the Microsoft Portable Executable and Common Object File Format Specification, Revision 6.0

The file separator in a UEFI file pointer is always the backslash ‘\’, regardless of the OS’ file separator.

fallback to DXE phase on errors in BDS

If the BDS phase cannot make forward progress, it will re-invoke the DXE Dispatcher to see if the dependencies of any additional DXE drivers have been satisfied since the last time the DXE Dispatcher was invoked.

TSL – Transient System Load

In the TSL phase, EFI applications execute. That is, UEFI images are loaded and executed. The range of EFI applications is not limited, but in most cases the EFI application may be an UEFI Shell, or an OS bootloader for loading the OS, optionally presenting a menu to the user to choose an OS to load beforehand. When an UEFI Shell terminates, control is transferred back to the firmware boot manager and the PI switches back to the last part of the BDS phase, so other EFI applications like an OS boot manager can be executed.

Usually, an OS bootloader terminates the UEFI Boot Services (firmware bootloader) via the ExitBootServices() call. However, terminating of the firmware boot manager is also possible for the OS itself. In both cases, the TSL phase transitions to the RT phase.

RT – Runtime

The RT phase is the runtime of the OS. This is the phase where the OS controls the system. The UEFI firmware provides access to certain firmware NVRAM variables to the OS. The OS’ access to each variable is either read/write or read-only.

AL - Afterlife

As in real life, not much is known about the Afterlife in PI.

After the OS takes over from the BDS via its boot (TSL), only a small set of UEFI is left behind. If the hardware or OS crashes, the firmware could try and implement some form of recovery or remediation action. The UEFI spec does not specify any required behavior in this phase.

reference

additional resources

boot process on UEFI platforms

© 2022 – 2026 Rudolf Held
x