What Is the Firmware Execution Flow?

A practical overview of the UEFI firmware execution flow from reset vector, SEC, PEI, DXE, BDS, TSL to runtime debugging.

October 28, 2025 Updated June 19, 2026 4 min read

Đọc bằng English Tiếng Việt 日本語

The firmware execution flow is the path from the moment the CPU leaves reset until the operating system takes control. In UEFI, the usual checkpoints are Reset Vector, SEC, PEI, DXE, BDS, TSL, and runtime after ExitBootServices().

In short: the firmware flow helps you locate the failing stage instead of treating the whole BIOS as a black box.

When a machine does not boot, the first question should not be “where is the BIOS bug”. It is better to split the problem:

Did the CPU run past the reset vector?
Did SEC build temporary RAM?
Did PEI initialize memory and create HOBs?
Did the DXE dispatcher run drivers?
Did BDS select the right Boot#### option?
Did the OS loader call ExitBootServices() successfully?

Overall flow

Power On / Reset
  -> Reset Vector
  -> SEC
  -> PEI
  -> PEI to DXE Handoff
  -> DXE
  -> BDS
  -> TSL
  -> ExitBootServices
  -> Runtime Services

Each checkpoint has a different responsibility. The reset vector is only the first address executed by the CPU. SEC creates the minimum execution environment. PEI prepares memory and HOBs. DXE loads drivers and publishes protocols. BDS selects a boot option. TSL is where the OS loader runs while Boot Services still exist. After ExitBootServices(), the OS controls memory, and only Runtime Services may remain callable.

Why the flow matters

Real BIOS logs are often incomplete. Without the flow, it is easy to debug the wrong layer. For example, “no boot option” may be a BDS problem, but it may also mean a DXE driver never published BlockIo or SimpleFileSystem. A Runtime Services crash is usually not a BDS issue. It often points to the memory map, runtime descriptors, SetVirtualAddressMap(), or ConvertPointer().

The flow lets you group failures by layer:

No serial log        -> reset vector / SEC / serial init
Memory init fail     -> PEI
Driver not loaded    -> DXE dispatcher / DEPEX / FDF placement
Device not visible   -> Driver Binding / protocol install
Boot option ignored  -> BDS / NVRAM / Device Path
EBS fail             -> memory map key / allocation timing
Runtime crash        -> runtime memory / virtual address change

Checkpoints that are easy to confuse

EndOfDxe is not ExitBootServices(). EndOfDxe is a firmware event that usually means DXE is nearing completion and boot policy is about to run. ExitBootServices() is an API called by the OS loader to end Boot Services.

BDS is not the OS loader. BDS selects a boot option and calls LoadImage() / StartImage(). TSL is the stage where the OS loader or another boot application runs under Boot Services.

A DXE driver EntryPoint running does not mean the device is working. For a Driver Binding driver, Supported() and Start() decide whether the driver actually binds to the controller.

Debug by following the flow

When debugging firmware, write down “after which checkpoint does the failure appear”. For example:

Do we have SEC logs but no PEI memory logs?
Do we have PEI HOBs but no DXE Core?
Do we have DXE Core but no driver dispatch?
Do we have Block I/O but no Simple File System?
Do we have Boot#### but LoadImage returns EFI_NOT_FOUND?
Does ExitBootServices return EFI_INVALID_PARAMETER?
Does a Runtime Service crash after SetVirtualAddressMap?

This style narrows the problem much faster than reading a large log without structure.

Source-reading checklist

When reading firmware flow source, check in this order:

1. Did reset code and the SEC entry run?
2. Was temporary RAM or CAR set up?
3. Did PEI create a valid HOB list?
4. Did DXE IPL find and jump to DXE Core?
5. Is the module actually placed in an FV?
6. Is DEPEX holding the module back?
7. Did Driver Binding Supported()/Start() succeed?
8. Did BDS read BootOrder/Boot#### correctly?
9. What status did LoadImage/StartImage return?
10. How did the OS loader call GetMemoryMap/ExitBootServices?

Conclusion

The firmware execution flow is the map for reading UEFI logs and source code. Once you understand reset vector, SEC, PEI, DXE, BDS, TSL, and runtime, a vague “BIOS does not boot” issue becomes a concrete question: did it fail before memory init, during driver dispatch, during boot option selection, or after the OS took control?