Crisis Recovery is the process of updating a "bad" version of the BIOS with a "good" version of the BIOSbased on the detection of some illegal state, such as:
- The system is not bootable
- The normal BIOS image has become corrupted
- The configuration settings are invalid.
- The user has forced a recovery condition (using a jumper).
This article describes the recovery architecture in SecureCore-Tiano and the basic execution flow.
See Also: Crisis Recovery Related Articles
In systems that support crisis recovery, the BIOS flash image is usually divided into two areas: boot block and normal. The boot block code is usually stored in some hardware-protected region of the flash device and contains the CPU's reset vector so that execution begins in this section when the system is reset. The crisis recovery Boot Mode requires that all code accesses must remain within the boot block area, while other Boot Modes allow accesses to the normal area.
Detecting That Crisis Recovery Is Needed
The PEI Dispatcher starts dispatching PEI Drivers in the normal manner. During this process, different Boot Mode Providers can register their preferred Boot Mode. These are prioritized and, after all Boot Mode Providers have registered, the Boot Mode is finalized. See PHOENIX_BOOT_MODE_PPI for more information. The PEI phase cannot complete until the Boot Mode is finalized.
Crisis recovery is started if the Boot Mode BOOT_IN_RECOVERY_MODE is finalized.. This might be happen if:
- The normal area of the BIOS image has been corrupted.
- A user action has been detected, such as a jumper setting detected through a GPIO input
- A power failure occurs while the normal portion of the flash part is in the process of being updated and does not finish.
- There is an error initializing some critical hardware.
When BOOT_IN_RECOVERY_MODE is finalized, the EFI_PEI_BOOT_IN_RECOVERY_MODE_PEIM_PPI is installed. This PPI can be included in the .dxs file of PEI Drivers that only execute during crisis recovery. Other drivers that behave differently depending on the Boot Mode by waiting for the EFI_PEI_MASTER_BOOT_MODE_PEIM_PPI to be installed. If the Boot Mode is BOOT_IN_RECOVERY_MODE, PEI Drivers might:
- Perform normally or no behavior change. This behavior is typical of support modules.
- Perform no action. This behavior is typical for non-critical hardware. Examples are nonrecovery modules.
- Perform minimal configuration. This behavior is typical of critical hardware, such as memory initialization.
- Enable functionality. This behavior is typical of modules that are required only for recovery.
Loading The Crisis Recovery Image
The PEI Dispatcher invokes the DXE Initial Program Load (IPL) PEI Driver, regardless of the Boot Mode. The DXE IPL PEI Driver detects that a crisis recovery is in process using GetBootMode() and invokes the EFI_PEI_RECOVERY_MODULE_PPI. This PPI does the following:
- Loads a Recovery Capsule which is a firmware volume image containing the crisis recovery DXE image.
- Installs the firmware volme so that it can be discovered by the PEI Core.
Note that the EFI_PEI_RECOVERY_MODULE_PPI is device and content neutral. The DXE IPL PEI Driver does not know or care about the capsule’s internal structure or from which device the capsule was loaded. Typically, the Recovery Module PEI Driver does the following:
- Searches the supported devices for recovery capsules
- Decides which capsule to load
- Loads the capsule into memory
- Loads the resulting DXE firmware volume
The Recovery Module PEI Driver provides the first three phases and the DXE IPL PEI Driver encompasses the last phase.
Launching The Crisis Recovery Image
After loading a Recovery Capsule, the DXE IPL PEI Driver attempts to load the DXE Core. In the Crisis Recovery Boot Mode, only the boot block firmware volume and the Recovery Capsule's firmware volume are available.
Copyright (C) 2009-2010 Phoenix Technologies Ltd. All Rights Reserved. Portions (C) 2001-2003 Intel Corporation. Used with permission.