10. Boot Paths

10.1. Introduction

The PEI Foundation is unaware of the boot path required by the system. It relies on the PEIMs to determine the boot mode (e.g. R0, R1, S3, etc.) and take appropriate action depending on the mode.

To implement this, each PEIM has the ability to manipulate the boot mode using the PEI Service SetBootMode() described in Services - PEI.

The PEIM does not change the order in which PEIMs are dispatched depending on the boot mode.

10.2. Code Flow

The normal code flow in PI firmware passes through a succession of phases, in the following order:

SEC
PEI
DXE
BDS
Runtime
Afterlife

This section describes alternatives to this ordering.

10.2.1. Reset Boot Paths

The following sections describe the boot paths that are followed when a system encounters several different types of reset.

10.2.1.1. Intel Itanium Processor Reset

Itanium architecture contains enough hooks to authenticate PAL-A and PAL-B code that is distributed by the processor vendor. The internal microcode on the processor silicon, which starts up on a PowerGood reset, finds the first layer of processor abstraction code (called PAL-A) that is located in the boot firmware volume (BFV), or the volume that has SEC and the PEI core, using architecturally defined pointers in the BFV. It is the responsibility of this microcode to authenticate that the PAL-A code layer from the processor vendor has not been tampered. If the authentication of the PAL-A layer passes, control then passes to the PAL-A layer, which then authenticates the next layer of processor abstraction code (called PAL-B) before passing control to it. In addition to this microarchitecture-specific authentication, the SEC phase of UEFI is still responsible for locating the PEI Foundation and verifying its authenticity.

In an Itanium-based system, it is also imperative that the firmware modules in the BFV be organized such that at least the PAL-A is contained in the fault-tolerant regions. This processor-specific PAL-A authenticates the PAL-B code, which usually is contained in the non-fault-tolerant regions of the firmware system. The PAL A and PAL B binary components are always visible to all the processors in a node at the time of power-on; the system fabric should not need to be initialized.

10.2.1.2. Non-Power-on Resets

Non-power-on resets can occur for many reasons. There are PEI and DXE system services that reset and reboot the entire platform, including all processors and devices. It is important to have a standard variant of this boot path for cases such as the following:

Resetting the processor to change frequency settings
Restarting hardware to complete chipset initialization
Responding to an exception from a catastrophic error

This reset is also used for Configuration Values Driven through Reset (CVDR) configuration.

10.3. Normal Boot Paths

A traditional BIOS executes POST from a cold boot (G3 to S0 state), on resumes, or in special cases like INIT. UEFI covers all those cases but provides a richer and more standardized operating environment.

The basic code flow of the system needs to be changeable due to different circumstances. The boot path variable satisfies this need. The initial value of the boot mode is defined by some early PEIMs, but it can be altered by other, later PEIM(s). All systems must support a basic S0 boot path. Typically a system has a more rich set of boot paths, including S0 variations, S-state boot paths, and one or more special boot paths.

The architecture for multiple boot paths presented here has several benefits, as follows:

The PEI Foundation is not required to be aware of system-specific requirements such as MP and various power states. This lack of awareness allows for scalability and headroom for future expansion.
Supporting the various paths only minimally impacts the size of the PEI Foundation.
The PEIMs that are required to support the paths scale with the complexity of the system.

Note that the Boot Mode Register becomes a variable upon transition to the DXE phase. The DXE phase can have additional modifiers that affect the boot path more than the PEI phase.

These additional modifiers can indicate if the system is in manufacturing mode, chassis intrusion, or AC power loss or if silent boot is enabled.

10.3.1. Basic G0-to-S0 and S0 Variation Boot Paths

The basic S0 boot path is “boot with full configuration.” This path setting informs all PEIMs to do a full configuration. The basic S0 boot path must be supported.

The Framework architecture also defines several optional variations to the basic S0 boot path. The variations that are supported depend on the following:

Richness of supported features
If the platform is open or closed
Platform hardware

For example, a closed system or one that has detected a chassis intrusion could support a boot path that assumes no configuration changes from last boot option, thus allowing a very rapid boot time.

Unsupported variations default to basic S0 operation. The following are the defined variations to the basic boot path:

Boot with minimal configuration: This path is for configuring the minimal amount of hardware to boot the system.
Boot assuming no configuration changes: This path uses the last configuration data.
Boot with full configuration plus diagnostics: This path also causes any diagnostics to be executed.
Boot with default settings: This path uses a known set of safe values for programming hardware.

10.3.2. S-State Boot Paths

The following optional boot paths allow for different operation for a resume from S3, S4, and S5:

S3 (Save to RAM Resume): Platforms that support S3 resume must take special care to preserve/restore memory and critical hardware.
S4 (Save to Disk): Some platforms may want to perform an abbreviated PEI and DXE phase on a S4 resume.
S5 (Soft Off): Some platforms may want an S5 system state boot to be differentiated from a normal boot – for example, if buttons other than the power button can wake the system.

An S3 resume needs to be explained in more detail because it requires cooperation between a G0-to-S0 boot path and an S3 resume boot path. The G0-to-S0 boot path needs to save hardware programming information that the S3 resume path needs to retrieve.

This information is saved in the Hardware Save Table using predefined data structures to perform I/O or memory writes. The data is stored in an UEFI equivalent of the INT15 E820 type 4 (firmware reserved memory) area or a firmware device area that is reserved for use by UEFI. The S3 resume boot path code can access this region after memory has been restored.

10.4. Recovery Paths

All of the above boot paths can be modified or aborted if the system detects that recovery is needed. Recovery is the process of reconstituting a system’s firmware devices when they have become corrupted. The corruption can be caused by various mechanisms. Most firmware volumes on nonvolatile storage devices (flash, disk) are managed as blocks. If the system loses power while a block, or semantically bound blocks, are being updated, the storage might become invalid. On the other hand, the device might become corrupted by an errant program or by errant hardware. The system designers must determine the level of support for recovery based on their perceptions of the probabilities of these events occurring and their consequences.

The following are some reasons why system designers may choose to not support recovery:

A system’s firmware volume storage media might not support modification after being manufactured. It might be the functional equivalent of a ROM.
Most mechanisms of implementing recovery require additional firmware volume space, which might be too expensive for a particular application.
A system may have enough firmware volume space and hardware features that the firmware volume can be made sufficiently fault tolerant to make recovery unnecessary.

10.4.1. Discovery

Discovering that recovery is done using a PEIM (for example, by checking a “force recovery” jumper).

10.4.2. General Recovery Architecture

The concept behind recovery is to preserve enough of the system firmware so that the system can boot to a point where it can do the following:

Read a copy of the data that was lost from chosen peripherals.
Reprogram the firmware volume with that data.

Preserving the recovery firmware is a function of the way the firmware volume store is managed, which is generally beyond the scope of this document.

The PI recovery architecture allows for one or many PEIMs to be built to handle the portion of the recovery that would initialize the recovery peripherals (and the buses they reside on) and then to read the new images from the peripherals and update the firmware volumes.

It is considered far more likely that the PEI will transition to DXE because DXE is designed to handle access to peripherals. This transition has the additional benefit that, if DXE then discovers that a device has become corrupted, it may institute recovery without transferring control back to the PEI.

10.5. Defined Boot Modes

The list of possible boot modes is described in the GetBootMode() function description. PI architecture specifically does not define an upgrade path if new boot modes are defined. This is necessary as the nature of those additional boot modes may work in conjunction with or may conflict with the previously defined boot modes.

10.6. Priority of Boot Paths

Within a given PEIM, the priority ordering of the sources of boot mode should be as follows (from highest priority to lowest):

BOOT_IN_RECOVERY_MODE
BOOT_ON_FLASH_UPDATE
BOOT_ON_S3_RESUME
BOOT_WITH_MINIMAL_CONFIGURATION
BOOT_WITH_FULL_CONFIGURATION
BOOT_ASSUMING_NO_CONFIGURATION_CHANGES
BOOT_WITH_FULL_CONFIGURATION_PLUS_DIAGNOSTICS
BOOT_WITH_DEFAULT_SETTINGS
BOOT_ON_S4_RESUME
BOOT_ON_S5_RESUME
BOOT_ON_S2_RESUME

The boot modes listed above are defined in the PEI Service SetBootMode().

10.7. Assumptions

Boot Path Assumptions lists the assumptions that can be made about the system for each sleep state.

Table 10.1 Boot Path Assumptions
System State	Description	Assumptions
R0	Cold Boot	Cannot assume that the previously stored configuration data is valid.
R1	Warm Boot	May assume that the perviously stored configuration data is valid.
S3	ACPI Save to RAM Resume	The previously stored configuratio data is valid and RAM is valid. RAM configuration must be restored from nonvolatile storage (NVS) before RAM may be used. The firmware may only modify previously reserved RAM. There are two types of reserved memory. One is the equivalent of the BIOS INT15h, E820 type-4 memory and indicates that the RAM is reserved for use by the firmware. The suggestion is to add another type of memory that allows the OS to corrupt the memory during runtime but that may be overwritten during resume.
S4, \| S5	Save to Disk Resume, \| “Soft Off”	S$ and S% are identical from a PEIM’s point of view. The two are distinguished to support follow-on phases. The entire system must be reinitialized but the PEIMs may assume that the previous configuration is still valid.
Boot on Flash Update		This boot mode can be either an INIT, S3, or other means by which to restart the machine. If it is an S3, for example, the flash update cause will supersede the S3 restart. It is incumbent upon platform code, such as the Memory Initialization PEIM, to determine the exact cause and perform correct behavior (i.e., S3 state restoration versus INIT behavior).
Boot with Manufacturing Mode settings		PEIM’s and/or DXE drivers may parameterize based upon actions that should only occur in the factory or a manufacturer approved setting.

10.8. Architectural Boot Mode PPIs

There is a possible hierarchy of boot mode PPIs that abstracts the various producers of this variable. It is a hierarchy in that there should be an order of precedence in which each mode can be set. The PPIs and their respective GUIDs are described in Required Architectural PPIs and Optional Architectural PPIs. The hierarchy includes the master PPI, which publishes a PPI that will be depended upon by the appropriate PEIMs, and some subsidiary PPI. For PEIMs that require that the boot mode is finally known, the Master Boot Mode PPI can be used as a dependency. Architectural Boot Mode PPIs lists the architectural boot mode PPIs.

Table 10.2 Architectural Boot Mode PPIs
PPI Name	Required or Optional	PPI Definition in Section
Master Boot Mode PPI	Required	Architectural PPIs: Required Architectural PPIs
Boot in Recovery Mode PPI	Optional	Architectural PPIs: Optional Architectural PPIs

10.9. Recovery

10.9.1. Scope

Recovery is the process of reconstituting a system’s firmware devices when they have become corrupted. The corruption can be caused by various mechanisms. Most firmware volumes (FVs) in nonvolatile storage (NVS) devices (flash or disk, for example) are managed as blocks. If the system loses power while a block, or semantically bound blocks, are being updated, the storage might become invalid. On the other hand, an errant program or hardware could corrupt the device. The system designers must determine the level of support for recovery based on their perceptions of the probabilities of these events occurring and the consequences.

The designers of a system may choose not to support recovery for the following reasons:

A system’s FV storage media might not support modification after being manufactured. It might be the functional equivalent of a ROM.
Most mechanisms of implementing recovery require additional FV space that might be too expensive for a particular application.
A system may have enough FV space and hardware features that the FV can be made sufficiently fault tolerant to make recovery unnecessary.

10.9.2. Discovery

Discovering that recovery is required may be done using a PEIM (for example, by checking a “force recovery” jumper) or the PEI Foundation itself. The PEI Foundation might discover that a particular PEIM has not validated correctly or that an entire firmware has become corrupted.

10.9.3. General Recovery Architecture

The concept behind recovery is to preserve enough of the system firmware so that the system can boot to a point where it can do the following:

Read a copy of the data that was lost from chosen peripherals.
Reprogram the firmware volume (FV) with that data.

Preserving the recovery firmware is a function of the way the FV store is managed, which is generally beyond the scope of this document.

If the PEI Dispatcher encounters PEIMs that have been corrupted (for example, by receiving an incorrect hash value), it must change the boot mode to “recovery.” Once set to recovery, other PEIMs must not change it to one of the other states.

A PEIM can also detect a catastrophic condition or a forced-recovery event and alert the PEI 10.6.4 Finding and Loading the Recovery DXE Image.

10.9.4. Finding and Loading the Recovery DXE Image

10.9.4.1. Finding the Recovery DXE Image: Overview

The PEI Dispatcher specifically invokes the DXE Initial Program Load (IPL) PEIM, regardless of normal or recovery mode. The DXE IPL PEIM detects that a recovery is in process and invokes a recovery-specific PPI, the Recovery Module PPI. The Recovery Module PPI, EFI_PEI_RECOVERY_MODULE_PPI, does the following:

Loads a binary capsule that includes a recovery DXE image into memory
Updates the Hand-Off Block (HOB) table with the DXE firmware volume
Installs or Reinstalls instance of the Firmware Volume Info PPI (EFI_PEI_FIRMWARE_VOLUME_INFO_PPI) for the DXE firmware volume

See Section 8.6.3 for the PPIs that are needed to load the DXE image.

Note: The Recovery Module PPI is device and content neutral. The DXE IPL PEIM uses the Recovery Module PPI to load a DXE image and invokes the DXE image normally. The DXE IPL PEIM does not know or care about the capsule’s internal structure or from which device the capsule was loaded.

The internals of the recovery PEIM normally fall within four phases:

Searching the supported devices for recovery capsules
Deciding which capsule to load
Loading the capsule into memory
Loading the resulting DXE firmware volume

The Recovery Module PPI encompasses the first three phases and the DXE IPL PEIM encompasses the last phase. See the next topic, Recovery Sequence: Detailed Steps, for the details of these four phases.

10.9.4.2. Recovery Sequence

The normal, non-recovery sequence is that after completion of the PEI phase, the PEI Dispatcher specifically invokes the DXE Initial Program Load (IPL) PEIM. The recovery sequence is identical to the non-recovery sequence in that the PEI Dispatcher also specifically invokes the DXE IPL PEIM. After invoking the DXE IPL PEIM, the recovery sequence is as follows:

The DXE IPL PEIM detects that a recovery is inprocess, searches for the Recovery Module PPI, and invokesthe recovery function EFI_PEI_RECOVERY_MODULE_PPI.LoadRecoveryCapsule().
EFI_PEI_RECOVERY_MODULE_PPI searches for one or more instances of the Device Recovery Module PPI, EFI_PEI_DEVICE_RECOVERY_MODULE_PPI. For each instance found, the EFI_PEI_DEVICE_RECOVERY_MODULE_PPI.GetNumberRecoveryCapsules() function is invoked to determine the following:
- The number of recovery DXE capsules detected by the specified device
- The maximum buffer size required to load a capsule
EFI_PEI_RECOVERY_MODULE_PPI then decides the following:
- The device search order, if more than one Device Recovery Module PPI was discovered
- The individual search order, if the device reported more than one recovery DXE capsule was found generating a search order list
EFI_PEI_RECOVERY_MODULE_PPI invokes the device recovery function EFI_PEI_DEVICE_RECOVERY_MODULE_PPI.LoadRecoveryCapsule() to load a capsule that includes a recovery DXE image into memory. The capsule that is returned from the device recovery module is a capsule that contains the recovery DXE image.
The EFI_PEI_RECOVERY_MODULE_PPI security does the following:
- Verifies the capsule
- Generates a data Hand-Off Block (HOB) entry for a security failure
- Tries the next entry in the search order list
Once a valid capsule has been loaded, EFI_PEI_RECOVERY_MODULE_PPI does the following:
- Decomposes the capsule and updates the HOB table with the recovery DXE firmware volume information. The path parameters are assumed to be redundant for recovery. The Setup parameters are either redundant or fixed.
- Invalidates all HOB entries for updateable firmware volume entries.

The DXE capsule that is loaded by the Device Recovery Module PPI makes no assumptions about contents or format other than assuming that the recovery DXE image is somewhere in the returned capsule.

The following subsections describe the different recovery PPIs.

10.9.4.3. Recovery PPIs: Recovery Module PPI

The Recovery Module PPI, EFI_PEI_RECOVERY_MODULE_PPI , invokes the Device Recovery Module PPI EFI_PEI_DEVICE_RECOVERY_MODULE_PPI to do the following:

Determine the number of DXE recovery capsules found by each device
Determine capsule information
Load a specific DXE recovery capsule from the indicated device
Determine the device load order

The capsule is security verified and decomposed and the HOB table is updated with the DXE recovery firmware volume.

There are two general categories of recovery PPIs:

Device recovery PPI
Device recovery block I/O PPI

The Device Recovery Module PPI is device neutral. The Device Recovery Block I/O PPI is device specific and used to access the physical media. The following subsections describe the PPI associated with each category. See Code Definitions for the definitions of these PPIs.

10.9.4.3.1. Device Recovery Module PPI

The table below lists the device recovery functions in the Device Recovery Module PPI, EFI_PEI_DEVICE_RECOVERY_MODULE_PPI .

Table 10.3 Device Recovery Module Functions
Function	Description
GetNumberRecoveryCapsules	Scans the devices that are supported by the PPI for DXE recovery capsules and reports the number found The internal ordering should reflect the priority in the load order with the highest priority capsule number set to one and the lowest priority number set to N
GetRecoveryCapsuleInfo	Provides the size of the indicated capsule and a CapsuleType Globally Unique Identifier GUID The recovery module uses this information to allow an alternate priority scheme based on the CapsuleType information
LoadRecoveryCapsule	Loads the indicated DXE recovery capsule instance and returns a capsule with the actual number of bytes loaded

10.9.4.3.2. Device Recovery Block I/O PPI

The Device Recovery Block I/O PPI, EFI_PEI_RECOVERY_BLOCK_IO_PPI , differs from the Device Recovery Module PPI in that the Device Recovery Block I/O PPI is used for physical media access. The Device Recovery Module PPI uses this PPI to search for capsules. This PPI is included with the recovery PEIMs because a block I/O is the most common recovery media.

The table below lists the functions in the Device Recovery Block I/O PPI.

Table 10.4 Device Recovery Block I/O Functions
Function	Description
GetNumberOfBlockDevices	Returns the number of block I O devices supported There is no ordering priority
GetBlockDeviceMediaInfo	Indicates the type of block I O device found such as a legacy floppy or CD ROM The block size and last block number are also returned
ReadBlocks	Reads the indicated block I O device starting at the given logical block address LBA and for buffer size block size