BIOS Firmware Architecture
Modern BIOS firmware is no longer the simple 16‑bit ROM used decades ago. Today’s systems rely on UEFI (Unified Extensible Firmware Interface), a modular and service‑oriented firmware environment that behaves more like a miniature operating system than legacy BIOS. According to modern UEFI development resources, UEFI firmware executes in a structured sequence of phases — SEC → PEI → DXE → BDS → TSL → RT → AL — each with distinct responsibilities for initializing hardware and handing off control to the operating system.
1. Firmware Layout in SPI Flash
UEFI firmware is stored inside a dedicated SPI NOR flash chip (typically 8–64MB). Technical documentation confirms that the flash layout usually contains the following regions:
- Flash Descriptor (FD) – Defines region boundaries.
- Intel ME / AMD PSP region – Platform security & initialization processor.
- GbE region – Network firmware (platform‑specific).
- BIOS region – Contains UEFI firmware volumes (FV), DXE drivers, NVRAM, microcode, capsule updates.
- EC/PMC region – Embedded controller firmware (if used by OEM).
Inside the BIOS region, UEFI modules are organized into Firmware Volumes (FV) and FFS Files (drivers, PEI core, DXE core, microcode, etc.).
2. UEFI Firmware Phases
The UEFI Platform Initialization (PI) specification defines a multi‑stage boot flow: SEC → PEI → DXE → BDS → TSL → RT → AL. These phases appear consistently across official PI specifications, EDK2 documentation, and firmware engineering guides.
2.1 SEC (Security) Phase
The first code that runs after CPU reset. Responsibilities:
- Create temporary memory using Cache‑as‑RAM (CAR).
- Initialize CPU into a predictable state.
- Act as the root of trust.
- Authenticate and pass control to the PEI core. [4](https://uefi.org/specs/PI/1.8/V1_Security_SEC_Phase_Information.html)
The SEC phase handles all restart events, ensuring integrity before advancing into PEI.
2.2 PEI (Pre‑EFI Initialization) Phase
The PEI phase brings the system into a usable hardware state. Core responsibilities include:
- Initialize DRAM.
- Execute PEIMs (Pre‑EFI Initialization Modules).
- Initialize early chipset components.
- Build the HOB list (Hand‑Off Blocks).
- Pass system info to DXE.
Modern UEFI engineering documents confirm that PEI is where memory training, chipset bring‑up, and early platform setup occur.
2.3 DXE (Driver Execution Environment)
DXE is the core of UEFI firmware. It loads most platform drivers and fully initializes hardware.
- DXE Foundation + DXE Dispatcher
- Loads DXE drivers from firmware volumes
- Initializes USB, storage, PCIe, network, GPU
- Builds Boot Services & Runtime Services
- Prepares environment for BDS
Firmware engineering guides describe DXE as a miniature operating system managing protocols, drivers, and device enumeration.
2.4 BDS (Boot Device Selection)
The BDS phase:
- Initializes console and input devices
- Loads boot entries from NVRAM
- Executes OS bootloader (EFI application)
These responsibilities are defined in the PI Spec.
2.5 TSL (Transient System Load)
This phase handles OS loader execution until ExitBootServices() is called.
2.6 RT (Runtime Services)
UEFI Runtime Services remain active even after the OS boots (e.g., variables, time, firmware config).
2.7 AL (After‑Life)
“After‑Life” handles shutdown, S3 resume, or specific firmware behaviors after OS handoff.
3. Key Firmware Data Structures
3.1 Firmware Volumes (FV)
Containers that store UEFI modules, DXE drivers, PEI core, microcode, and boot‑critical components.
3.2 FFS Files
Drivers or components stored inside FV containers (DXE drivers, PEIMs, microcode).
3.3 HOB (Hand‑Off Blocks)
The mechanism for passing hardware/platform info from PEI to DXE. [1]
3.4 NVRAM Variables
UEFI variables stored in non‑volatile memory include:
- BootOrder / BootXXXX entries
- Secure Boot keys
- OEM configuration
UEFI architecture guides show how NVRAM is used across DXE and RT phases.
4. Security Components
4.1 Secure Boot
Ensures OS bootloaders & drivers are signed before execution. [4]
4.2 Intel ME / AMD PSP
Platform controllers that provide security, memory initialization support, and platform trust chain. [3]
4.3 Boot Guard
Validates firmware authenticity at the earliest phase to prevent unauthorized ROM images.
5. Technician Summary
- SEC/PEI failures: Usually cause black screen / no POST.
- DXE failures: USB/keyboard not working, stuck logos, “no boot device”.
- BDS/NVRAM corruption: Boot loops, missing OS entries.
- ME/PSP region issues: Memory init failure (common on Intel boards).
0 comments