.

1. Basic Foundation: The NOP Instruction (0x90)

The NOP (No Operation) instruction is the most basic single-byte instruction in x86 architecture, with a fixed machine code value of 0x90.

Key characteristics of NOP:

• Occupies 1 byte of memory space and consumes one CPU clock cycle;

• Performs no data operations, no register modifications, and no program logic changes;

• Main application scenarios: program padding, memory address alignment, debugging breakpoint reservation, and shellcode space filling.

In memory layout, consecutive NOPs form blank instruction intervals, which are often used as buffer zones for jump instruction execution in low-level development.

2. Core Rule of All Relative Jump Instructions

Most common jump instructions in x86 arerelative jumps. Unlike absolute jumps that directly specify a target memory address, relative jumps only store an offset value. The CPU follows a fixed formula to calculate the final jump target, which is the most error-prone core principle for beginners:

Target Address = Address of the instruction immediately after the JMP instruction + signed offset

It is critical to note that the offset is not based on the starting address of the JMP instruction itself, but on the address of the next instruction after the entire JMP instruction ends. In GNU assembly syntax, the symbol $ represents the starting address of the current instruction.

3. Full Analysis of Common x86 JMP Instruction Variants

3.1 Short Relative Jump (Opcode: 0xEB)

The short jump is the smallest and most flexible relative jump instruction, applicable only to short-distance program jumps.

• Instruction length: 2 bytes total (1-byte opcode 0xEB + 1-byte signed offset)

• Jump range: 8-bit signed offset, covering -128 bytes ~ +127 bytes

• Application scenarios: Local small loops, short conditional branches, and tiny code block jumps

Practical memory example and calculation:

Memory layout:
0x0000: 90 nop
0x0001: EB 03 jmp $+3

Calculation steps:

1. The JMP instruction starts at 0x0001 and occupies 2 bytes;

2. Address of the next instruction: 0x0001 + 2 = 0x0003;

3. Jump offset = 0x03;

4. Final target address: 0x0003 + 0x03 = 0x0006.

This instruction implements a short forward jump. By using a negative offset (e.g., EB FD, offset = -3), it can implement a backward short jump.

3.2 Near Relative Jump (Opcode: 0xE9)

The 0xE9 near relative jump is the most widely used jump instruction in x86 32-bit programs and shellcode, with a far larger jump range than short jumps.

• Instruction length: 5 bytes total (1-byte opcode 0xE9 + 4-byte little-endian signed offset)

• Jump range: 32-bit signed offset, covering -2GB ~ +2GB, covering the entire program memory space

• Application scenarios: cross-code-block jumps, position-independent shellcode, and large program logic jumps

Basic example (zero-offset jump):
0x0002: E9 00 00 00 00 jmp $+5

Calculation logic:

1. The JMP instruction starts at 0x0002 and occupies 5 bytes;

2. Address of the next instruction: 0x0002 + 5 = 0x0007;

3. Offset = 0, so the target address is exactly 0x0007;

This zero-offset jump is a “null jump” that directly executes the next instruction, which is often used for instruction padding and verification.

Extended practical examples:

• Forward jump 0x10 bytes: Machine code E9 10 00 00 00, assembly jmp $+0x15

• Backward jump 0x20 bytes: Machine code E9 E0 FF FF FF (negative numbers stored in two’s complement)

3.3 Indirect Absolute Jump (Opcode: 0xFF)

Different from relative jumps, the0xFF indirect jump is an absolute jump. It does not calculate the target address through offsets, but directly reads the complete absolute address from registers or memory, with no offset calculation involved.

3.3.1 Register indirect jump

Typical instruction: jmp eax, machine code FF E0 (2 bytes)

Execution logic: The CPU directly assigns the 32-bit address value stored in the EAX register to the instruction pointer (EIP) to complete the jump.

Common variants:FF E1 (jmp ecx), FF E2 (jmp edx), applicable to function pointer calls and dynamic jump scenarios.

3.3.2 Memory indirect jump

Typical instruction: jmp [0x1000], machine code FF 25 00 10 00 00 (6 bytes)

Execution logic: The CPU reads the 32-bit absolute address data stored at the memory address 0x1000, then assigns it to EIP, realizing indirect jump based on memory data.

Application scenarios: Jump table calls, dynamic program address scheduling, and pointer-based program branching.

4. Comprehensive Comparison of All Jump Instructions

The following table summarizes the core parameters and characteristics of all mainstream x86 jump instructions, facilitating quick distinction and application:

1. Short Relative Jump (0xEB)
Size: 2 Bytes | Operand: 8-bit signed offset | Calculation: Target = Next Instr Address + Offset | Usage: Short local loop, tiny conditional branch

2. Near Relative Jump (0xE9)
Size: 5 Bytes | Operand: 32-bit signed offset | Calculation: Target = Next Instr Address + Offset | Usage: Long-distance code jump, position-independent shellcode

3. Register Indirect Jump (0xFF E0~E7)
Size: 2 Bytes | Operand: Register stored absolute address | Calculation: EIP = Register value | Usage: Function pointer call, program dynamic jump

4. Memory Indirect Jump (0xFF 25)
Size: 6 Bytes | Operand: Memory pointer data | Calculation: EIP = *Memory address | Usage: Jump table invocation, dynamic memory address scheduling

5. Integrated Assembly & Machine Code Example

The following complete memory code snippet integrates NOP and all jump types, intuitively showing the actual memory layout of different instructions:

0x0000 90 nop
0x0001 EB 05 jmp $+7 ; Short relative forward jump
0x0003 90 nop
0x0004 90 nop
0x0005 E9 08 00 00 00 jmp $+13 ; Near relative long jump
0x0009 FF E1 jmp ecx ; Register indirect absolute jump

6. Key Takeaways & Common Pitfalls

• NOP (0x90) is a single-byte empty instruction, mainly used for memory padding and alignment;

• All relative jumps (0xEB, 0xE9) calculate targets based on the next instruction address, not the current JMP address — this is the most common error in manual shellcode writing and reverse analysis;

• Relative jumps are position-independent, making them the core choice for shellcode; indirect absolute jumps rely on fixed register/memory addresses, suitable for program internal dynamic calls;

• Short jumps have strict distance limitations, while near jumps cover the full memory range, which should be selected according to actual code distance in development.

Introduction

The x86-64 boot sequence is one of the most misunderstood areas in low-level systems programming. Firmware engineers, kernel developers, and students alike frequently conflate concepts that live at entirely different layers of the system: assembler directives with CPU modes, register names with separate registers, memory models with execution modes, and I/O instructions with privilege levels.

This article builds a correct mental model from the ground up. We trace the boot flow from the reset vector to C code, dissect each CPU mode, clarify what BITS directives actually control, explain register aliasing, and demystify port-mapped I/O. By the end, you will understand not just what happens during boot, but why each layer exists and how they interact.

The Boot Sequence: From Reset Vector to C Code

When an x86-64 CPU receives power or a reset signal, it does not start executing your operating system. It begins in a minimal 16-bit environment called Real Mode, at a fixed memory address. The firmware (BIOS or UEFI SEC phase) must then shepherd the CPU through several mode transitions before it can execute ordinary C code.

Reset Vector and Real Mode Entry

The reset vector is the physical address from which the CPU fetches its first instruction after reset. For all x86 and x86-64 CPUs — Intel and AMD alike — this address is 0xFFFFFFF0 (the top of the 4 GB address space, minus 16 bytes). In real-mode segmentation terms, this corresponds to CS:IP = F000:FFF0 with the upper address bits hardwired high.

At this point, the CPU is in 16-bit Real Mode: segment:offset addressing, a 1 MB addressable memory window (20-bit address bus), no memory protection, no privilege levels, and no paging. The first firmware instructions run here.

; Reset vector: physical 0xFFFFFFF0 (F000:FFF0 real mode)
BITS 16
cli
xor ax, ax
mov ds, ax
mov ss, ax
mov sp, 0x7C00        ; temporary stack (placeholder)

Early Initialization: A20, GDT, and PAE

Before the CPU can leave real mode, several prerequisites must be satisfied:

1. A20 Line Enable: The 20th address line (A20) must be enabled to allow access to memory above 1 MB. On modern systems this is often already enabled by silicon reset, but legacy firmware explicitly enables it (historically via the keyboard controller on port 0x64, or via port 0x92).

2. Load GDT: The Global Descriptor Table (GDT) must be loaded with at least a null descriptor, a 64-bit code segment descriptor, and a 64-bit data segment descriptor. The GDT defines the segment attributes that protected mode and long mode rely on.

3. Enable PAE: Physical Address Extension (PAE), controlled by CR4 bit 5, must be enabled. PAE is a hard prerequisite for long mode — it changes the page table hierarchy to the 4-level structure that 64-bit mode uses.

call enable_a20
lgdt [gdt_descriptor]

; Enable PAE (CR4 bit 5)
mov eax, cr4
or  eax, 1 << 5
mov cr4, eax

Enabling Long Mode: The EFER.LME Step

With PAE enabled and the GDT loaded, the next step is to set the Long Mode Enable (LME) bit in the Extended Feature Enable Register (EFER). EFER is a Model-Specific Register (MSR) at address 0xC0000080, and LME is bit 8.

Setting LME does not by itself activate long mode. It merely arms the mechanism. Long mode becomes active only after paging is enabled and a far jump reloads the code segment (CS) with a 64-bit descriptor.

; Load PML4 base into CR3
mov eax, pml4_table
mov cr3, eax

; Enable Long Mode (EFER.LME, bit 8)
mov ecx, 0xC0000080
rdmsr
or  eax, 1 << 8
wrmsr

Note that CR3 is loaded before enabling long mode. CR3 holds the physical base address of the PML4 (Page Map Level 4) table — the root of the 4-level page table walk. Without valid page tables, enabling paging will cause an immediate page fault.

The Transient Protected Mode

This is the step that causes the most confusion. To activate long mode, you must set both CR0.PE (Protected Mode Enable, bit 0) and CR0.PG (Paging, bit 31). When these are set with EFER.LME already armed, the CPU enters 32-bit Protected Mode — but only momentarily.

; Enable Protected Mode + Paging (CR0.PE bit 0 + CR0.PG bit 31)
mov eax, cr0
or  eax, (1 << 31) | (1 << 0)
mov cr0, eax

After the mov cr0, eax instruction, the CPU is in a transitional state. Long mode is enabled (LME=1, PE=1, PG=1) but not yet active, because the CS register still holds its old real-mode cached attributes. The CPU uses those old attributes to fetch and decode the very next instruction. In effect, the processor is in 32-bit protected mode for the duration of exactly one instruction.

Far Jump: The Actual Mode Switch

The far jump is what actually activates 64-bit long mode. It performs two critical actions simultaneously:

1. It flushes the instruction pipeline, discarding any pre-fetched instructions that were decoded under the old mode.

2. It reloads the CS register from the GDT entry at selector 0x08. If that descriptor has the L-bit (Long Mode bit) set to 1, the CPU switches to 64-bit mode.

; Far jump flushes pipeline, loads 64-bit CS (L-bit=1)
jmp 0x08:long_mode_start

BITS 64
long_mode_start:
mov ax, 0x10
mov ds, ax
mov es, ax
mov ss, ax
lea rsp, [stack_top]

After the far jump, the CPU is fully in 64-bit long mode. The data segments (DS, ES, SS) are reloaded with selector 0x10 (the 64-bit data segment), and the stack pointer is set to a valid 64-bit stack.

Hand-off to PEI Core

With the CPU in 64-bit mode and a valid stack, the firmware can now call C code. In the UEFI Platform Initialization (PI) architecture, this is the PEI Core (Pre-EFI Initialization), entered via a function typically named pei_main.

call pei_main        ; hand off to PEI Core (C code)
hlt

From this point forward, the firmware executes primarily in C, with occasional assembly for low-level operations. The SEC (Security) phase — the assembly code we have been tracing — is complete.

CPU Modes Explained

The x86-64 architecture defines several execution modes, each with distinct addressing capabilities, register widths, and protection mechanisms. Understanding the differences is essential for firmware and kernel development.

Real Mode (16-bit)

Real Mode is the CPU’s native state at reset. It emulates the behavior of the original 8086 processor:

Real mode’s 1 MB limit is a direct inheritance from the 8086’s 20-bit address bus. The A20 gate (mentioned earlier) exists because the 8086 would wrap addresses above 1 MB back to zero, and some legacy software relied on this behavior.

Protected Mode (32-bit)

Protected Mode, introduced with the 80286 and extended to 32-bit with the 80386, is the mode that enables modern operating system features:

Protected mode is enabled by setting CR0.PE (bit 0). In the boot flow we traced, protected mode is entered but immediately exited via the far jump to long mode. It is a corridor, not a destination.

Long Mode (64-bit)

Long Mode is the 64-bit mode of the x86-64 architecture, originally designed by AMD as AMD64 and later adopted by Intel as Intel 64. It is enabled by the combination of EFER.LME=1, CR0.PE=1, and CR0.PG=1, and activated by a far jump to a 64-bit code segment.

Long Mode is not a single mode — it contains two sub-modes, selected by the attributes of the current code segment (CS) descriptor:

64-bit Sub-mode

When CS.L=1 and CS.D=0, the CPU is in full 64-bit mode:

• 64-bit general-purpose registers (RAX, RBX, RCX, RDX, RSI, RDI, RBP, RSP, and R8–R15)

• 64-bit linear addressing (canonical addresses, 48-bit or 57-bit with LA57)

• 4-level (or 5-level) page table hierarchy

• Flat memory model — segmentation is largely disabled (CS, DS, ES, SS bases are forced to 0; FS and GS remain configurable)

• RIP-relative addressing

Compatibility Sub-mode

When CS.L=0, the CPU remains in long mode but executes legacy 32-bit (CS.D=1) or 16-bit (CS.D=0) code. This allows 32-bit applications to run under a 64-bit operating system without emulation. The system firmware (UEFI) and modern OS kernels run in 64-bit sub-mode, while compatibility mode is used primarily for running legacy user-space applications.

Flat Mode: A Memory Model, Not a CPU Mode

“Flat Mode” is frequently mistaken for a CPU execution mode. It is not. Flat mode is a memory model configuration in which all segment registers point to the same linear address space — base address 0, limit set to the maximum. When segmentation is effectively disabled, the logical address (the address the program works with) equals the linear address (the address after segmentation, before paging).

Flat mode can coexist with different CPU modes:

Configuration

Description

Flat Protected Mode

CS, DS, ES, SS all have base=0, limit=0xFFFFFFFF. This is the standard memory model used by Linux, Windows, and virtually all 32-bit operating systems. Segmentation provides no isolation; protection is enforced entirely by paging.

Unreal Mode (Flat Real Mode)

A clever hack: temporarily enter protected mode, load DS and/or ES with a 4 GB limit descriptor, then return to real mode. The segment registers retain their expanded limits even after switching back to real mode, allowing access to memory above 1 MB while still executing 16-bit real-mode code. Used by some BIOS firmware and legacy software.

Flat Long Mode

In 64-bit long mode, flat mode is effectively mandatory. The CPU forces CS, DS, ES, and SS bases to 0 and ignores their limits. Only FS and GS retain configurable bases (used for thread-local storage and per-CPU data).

The critical distinction: CPU modes (Real, Protected, Long) are hardware execution states controlled by CR0, CR4, EFER, and CS attributes. Flat mode is a software configuration of segment registers that can be applied within certain CPU modes. You cannot “switch to flat mode” — you configure a flat memory model while running in protected mode or long mode.

BITS Directives: Assembler Layer, Not CPU Layer

One of the most persistent sources of confusion in x86 assembly is the relationship between BITS directives and CPU modes. They are entirely different things at different layers of the system.

What BITS Actually Does

BITS 16, BITS 32, and BITS 64 are assembler directives — instructions to the assembler (NASM, GAS, etc.), not to the CPU. They tell the assembler which instruction encoding mode to use for the instructions that follow. The CPU never sees these directives; they are consumed at assembly time and affect the machine code bytes that are emitted.

Specifically, BITS controls:

• Default operand size: Whether mov ax, 0 or mov eax, 0 is the “natural” encoding that does not require an operand-size prefix (0x66).

• Default address size: Whether 16-bit or 32-bit addressing forms are used by default (controlled by the 0x67 prefix in 16/32-bit modes).

• Available register names: In BITS 64, the assembler accepts RAX, RBX, R8–R15, and other 64-bit register names. In BITS 16 or BITS 32, these names are not recognized.

• REX prefixes: In BITS 64, the assembler automatically emits REX prefixes when 64-bit registers or extended registers are used.

BITS vs Mode: The Orthogonality Principle

The most important concept to internalize is that BITS directives and CPU modes are orthogonal — they operate independently and can be combined in ways that may seem counterintuitive:

• BITS 32 code in 16-bit protected mode: You can assemble code with BITS 32 and run it in a 16-bit code segment. The assembler emits 32-bit encodings (with implicit 0x66 prefixes relative to the 16-bit default), and the CPU executes them correctly because the 0x66 prefix overrides the CS default operand size.

• BITS 16 code in compatibility mode: Under long mode’s compatibility sub-mode with a 16-bit CS (CS.L=0, CS.D=0), you can execute BITS 16-encoded code. The CPU remains in long mode but decodes instructions as 16-bit.

• BITS 64 code requires 64-bit mode: This is the one combination that is not freely mixable. BITS 64 uses REX prefixes and 64-bit registers that only exist when the CPU is in 64-bit sub-mode (CS.L=1). Executing BITS 64 code in any other mode will produce undefined behavior or invalid opcodes.

Register Aliasing: AL, AX, EAX, RAX

Another common misconception is treating AL, AX, EAX, and RAX as four separate registers. They are not — they are four different-sized windows into a single physical register in the CPU’s register file.

The Register Hierarchy

The x86 architecture has accumulated register widths over decades of evolution, and each new, wider register name overlays the previous one:

Visually, the register looks like this:

63                          31              15       7        0
+---------------------------+---------------+--------+--------+
|                           |               |   AH   |   AL   |  <- 8-bit
|                           |               +---- AX ----+    |  <- 16-bit
|                           +---------- EAX ---------------+  |  <- 32-bit
+---------------------------- RAX ----------------------------+  <- 64-bit

When you write to AL, you modify only the lowest 8 bits. The upper bits (bits 8–63) remain unchanged. When you write to AX, you modify bits 0–15. When you write to EAX, you modify bits 0–31 — with one important exception in 64-bit mode, described below.

Behavior Across Modes

The register file is the same physical silicon in every CPU mode. What changes is which windows are addressable and how writes to partial registers behave:

16-bit Real Mode

AL and AX are natively accessible. EAX physically exists in the silicon but requires a 0x66 operand-size prefix to access. The assembler emits this prefix automatically when you write mov eax, 0 under BITS 16. The upper 32 bits (bits 32–63) are not architecturally visible in real mode — they exist but cannot be read or written.

32-bit Protected Mode

AL, AX, and EAX are all accessible. EAX is the native size (no prefix needed); AX requires a 0x66 prefix. The upper 32 bits (bits 32–63) still exist in the register file but are not architecturally visible. They are typically zero from reset and preserved across mode switches, but software cannot observe or modify them in 32-bit mode.

64-bit Long Mode

All four names (AL, AX, EAX, RAX) are architecturally visible and directly addressable. This is where the most interesting behavior occurs.

The 64-bit Zero-Extension Quirk

In 64-bit mode, writing to a 32-bit register (such as EAX) has an unusual side effect: it zero-extends the upper 32 bits of the corresponding 64-bit register. This is different from writing to 8-bit or 16-bit registers, which preserve the upper bits.

mov rax, 0xAAAAAAAAAAAAAAAA   ; RAX = 0xAAAAAAAAAAAAAAAA

mov eax, 0x12345678           ; RAX = 0x0000000012345678
;                               ^^^^^^^^^^ upper 32 bits ZEROED!

mov ax, 0x1234                ; RAX = 0x00000000AAAA1234
;                               ^^^^^^^^^^^^^^^^ upper bits preserved

mov al, 0x56                  ; RAX = 0x00000000AAAA1256
;                               ^^^^^^^^^^^^^^^^^^^^^ only low byte changed

This zero-extension is not a bug — it is a deliberate architectural design decision. In 32-bit x86, partial-register writes (writing to AL or AX while EAX holds other data) created false dependencies that forced the CPU to merge the partial write with the existing upper bits, causing pipeline stalls and performance penalties. By zero-extending 32-bit writes in 64-bit mode, the architecture eliminates these dependencies: after mov eax, X, the full 64-bit value of RAX is known to be 0:X, with no dependency on the previous value of RAX.

Port-Mapped I/O: IN and OUT Instructions

The x86 architecture provides two mechanisms for communicating with hardware devices: memory-mapped I/O (MMIO), where device registers appear in the physical memory address space, and port-mapped I/O (PMIO), where devices are addressed through a separate I/O address space. The IN and OUT instructions are the gateway to port-mapped I/O.

I/O Address Space vs Memory Address Space

The x86 I/O address space is completely separate from the memory address space. It contains 65,536 I/O ports, numbered from 0x0000 to 0xFFFF. Each port can transfer 8, 16, or 32 bits at a time. This is distinct from the physical memory address space, which is 4 GB (32-bit) or 256 TB (48-bit 64-bit) and is accessed via normal load/store instructions (mov).

Instruction Syntax and Encoding

The IN instruction reads data from an I/O port into the accumulator register (AL, AX, or EAX). The OUT instruction writes data from the accumulator to an I/O port. The port number can be specified as an immediate value or via the DX register.

; Immediate port (only 0x00-0xFF)
in  al, 0x60        ; read 8-bit from port 0x60 (keyboard data)
in  ax, 0x1F0       ; read 16-bit from port 0x1F0 (IDE data)
in  eax, 0xCFC      ; read 32-bit from port 0xCFC (PCI config data)
out 0x60, al        ; write 8-bit to port 0x60
out 0xCF8, eax      ; write 32-bit to port 0xCF8 (PCI config address)

; Port in DX (any port 0x0000-0xFFFF)
mov dx, 0x3F8
in  al, dx          ; read 8-bit from COM1 data port
out dx, ax          ; write 16-bit to port in DX

Rule

Detail

Data register is fixed

IN always reads into AL/AX/EAX. OUT always writes from AL/AX/EAX. You cannot use other registers for the data.

Immediate port range

Only ports 0x00–0xFF can be specified as an immediate. Ports 0x0100–0xFFFF must use DX.

No 64-bit I/O

Even in 64-bit long mode, IN/OUT only support 8/16/32-bit transfers via AL/AX/EAX. RAX is never used with IN/OUT.

Encoding is mode-independent

The IN/OUT instruction encodings are identical in real, protected, and long mode. No mode-specific prefixes are needed.

Privilege and Access Control

The behavior of IN/OUT instructions changes dramatically depending on the CPU mode and privilege level:

Real Mode

In real mode, there is no privilege protection. Any code can execute IN/OUT instructions to any I/O port. This is why firmware running in real mode has unrestricted hardware access.

Protected Mode and Long Mode

In protected mode and long mode, I/O access is controlled by two mechanisms:

1. IOPL (I/O Privilege Level): A 2-bit field in the EFLAGS register (bits 12–13) that specifies the minimum privilege level required to execute I/O instructions. If the Current Privilege Level (CPL) is numerically greater than IOPL, IN/OUT instructions cause a General Protection fault (#GP). Firmware and kernel code run at CPL=0, so IOPL does not restrict them. User applications run at CPL=3 and are typically blocked unless IOPL is set to 3.

2. I/O Permission Bitmap: A bitmask stored in the Task State Segment (TSS) that grants per-port access even when CPL > IOPL. Each bit corresponds to one I/O port (0 = access allowed, 1 = access denied). This allows an OS to grant a user-space driver access to specific ports (e.g., a parallel port) without opening all I/O access.

Common I/O Ports

While the I/O address space has 65,536 ports, only a small fraction are commonly used. Here are some classic examples:

Many of these legacy ports are emulated or deprecated on modern systems (keyboard controllers, IDE, COM ports are often absent), but the PCI config ports (0xCF8/0xCFC) remain universally supported for PCIe configuration access, and the RTC ports remain for basic timekeeping.

Putting It All Together: The Full Picture

We have examined five distinct layers of the x86-64 boot environment. Let us synthesize them into a unified understanding:

Now, trace the boot sequence one more time with all five layers in mind:

1. Reset: CPU starts in Real Mode (hardware layer). The assembler used BITS 16 (assembler layer) for the code that runs here. Instructions use AL/AX (register layer), with EAX accessible via 0x66 prefix. The memory model is segmented (not flat). IN/OUT is unrestricted.

2. Early init: Still in Real Mode. A20 is enabled via IN/OUT to port 0x64 or 0x92. GDT is loaded. PAE is enabled via CR4. The code uses mov eax, cr4 — BITS 16 encoding with implicit 0x66 prefix for the 32-bit register.

3. Long mode arming: EFER.LME is set via rdmsr/wrmsr (MSR access, not IN/OUT). CR3 is loaded with the PML4 base. Still in Real Mode at the hardware layer.

4. Mode switch #1: CR0.PE and CR0.PG are set. CPU enters 32-bit Protected Mode (hardware layer) — transiently. The next instruction (far jump) is fetched using old CS attributes. The assembler still used BITS 16 for this instruction because it appears before the BITS 64 directive.

5. Mode switch #2: Far jump to selector 0x08. CS is reloaded with a 64-bit code segment (L-bit=1). CPU enters 64-bit Long Mode (hardware layer). The assembler switches to BITS 64 at the long_mode_start: label. Now RAX is accessible. The memory model is flat (mandatory in long mode). IN/OUT remains available but now privilege-gated (though firmware runs at ring 0).

6. C hand-off:call pei_main transfers control to C code running in 64-bit long mode with a flat memory model. The SEC phase assembly is complete.

Summary and Key Takeaways

1. The boot flow involves exactly 2 mode switches: Real Mode → Protected Mode (transient, one instruction) → Long Mode (64-bit). The reset state is Real Mode, not a switch.

2. BITS directives are not CPU modes. BITS 16/32/64 tell the assembler how to encode instructions. The CPU mode is controlled by CR0, CR4, EFER, and CS. They are orthogonal.

3. AL, AX, EAX, RAX are one register. They are different-sized windows into the same physical register file. In 64-bit mode, writing EAX zero-extends the upper 32 bits; writing AX or AL preserves them.

4. Flat mode is a memory model, not a CPU mode. It means all segments point to base 0 with maximum limit. It can be configured in protected mode (flat protected model) or is mandatory in long mode. Unreal mode achieves flat addressing while staying in real mode.

5. IN/OUT work identically in all modes. The instruction encoding is the same in real, protected, and long mode. What changes is privilege: unrestricted in real mode, gated by IOPL and I/O Permission Bitmap in protected/long mode. Data sizes are 8/16/32-bit only — never 64-bit.

6. CR0.PE must be set alongside CR0.PG. A common bug in simplified boot examples is setting only PG without PE. Without PE, the CPU never enters protected mode, and long mode cannot activate.

7. The far jump is the actual mode switch. Setting control registers arms the mode; the far jump that reloads CS with a 64-bit descriptor (L-bit=1) is what activates 64-bit long mode.

Glossary

Term

Definition

SEC

Security Phase — the first phase of UEFI PI boot, written in assembly, responsible for initial CPU state setup and hand-off to PEI.

PEI

Pre-EFI Initialization — the second boot phase, primarily C code, responsible for memory initialization and early platform setup.

GDT

Global Descriptor Table — a table in memory that defines segment descriptors used by protected mode and long mode.

PAE

Physical Address Extension — a feature (CR4 bit 5) that enables 36-bit+ physical addressing and is a prerequisite for long mode.

EFER

Extended Feature Enable Register — MSR 0xC0000080, containing the LME (Long Mode Enable) bit and other feature controls.

PML4

Page Map Level 4 — the root page table in the 4-level paging hierarchy used by long mode. Its physical address is stored in CR3.

CS.L

The Long Mode bit in a code segment descriptor. When set (CS.L=1) with CS.D=0, the CPU executes in 64-bit mode.

IOPL

I/O Privilege Level — a 2-bit field in EFLAGS (bits 12–13) that controls which privilege levels may execute IN/OUT instructions.

TSS

Task State Segment — a system segment that contains, among other things, the I/O Permission Bitmap used for per-port I/O access control.

MMIO

Memory-Mapped I/O — a mechanism where device registers appear in the physical memory address space, accessed via normal load/store instructions.

PMIO

Port-Mapped I/O — a mechanism where devices are addressed through a separate 64 KB I/O address space, accessed via IN/OUT instructions.

Unreal Mode

A configuration where the CPU is in real mode but segment registers have 4 GB limits (loaded via a temporary protected-mode switch), allowing access to memory above 1 MB.

ACPI usually does not directly enumerate ordinary PCIe devices. The key distinction is:

PCI/PCIe enumeration discovers the devices; ACPI describes the PCIe topology and platform-specific resources/operations to Linux.

For an onboard PCIe device, the typical boot flow is:

             BIOS / UEFI
                 │
        PCIe Root Complex
                 │
        ┌─────────┴────┐
        │                  │
   PCIe Root Port      PCIe Root Port
        │                  │
     NVMe / NIC          Wi-Fi
        │
        └──────────────┐
                       │
                 PCI configuration
                 space / BARs
                       │
                    Linux

1. What ACPI tells Linux

ACPI tables such as DSDT/SSDT describe the PCI host bridge and its relationship to the PCI hierarchy.

A simplified ACPI namespace might look like:

\_SB
 └── PCI0                 ← PCI Host Bridge
      │
      ├── _HID = PNP0A08
      │
      ├── _SEG = 0
      ├── _BBN = 0
      │
      ├── _CRS            ← PCIe MMIO / I/O / bus resources
      │
      ├── RP01            ← Root Port
      │    └── ...
      │
      └── RP02
           └── ...

For example:

Device (PCI0)
{
    Name (_HID, EisaId ("PNP0A08"))
    Name (_CID, EisaId ("PNP0A03"))

    Name (_SEG, Zero)
    Name (_BBN, Zero)

    Method (_CRS, 0, Serialized)
    {
        ...
        // PCIe MMIO windows
        // PCI bus number ranges
        // I/O ranges
    }
}

Linux uses this information to create the PCI host bridge.

2. But where does the actual PCIe device come from?

Suppose the motherboard has an onboard Ethernet controller:

AMD/Intel CPU
     │
     │ PCIe
     ▼
Root Port 00:01.0
     │
     ▼
Ethernet Controller
01:00.0

The BIOS doesn’t normally need an ACPI device like:

Device (ETH0)
{
    Name (_HID, "PCI....")
}

Instead, Linux performs PCI configuration-space enumeration.

Linux essentially does:

PCI bus 00
   │
   ├── device 00:00.0
   │
   ├── device 00:01.0
   │       │
   │       └── PCIe secondary bus 01
   │               │
   │               └── 01:00.0 Ethernet
   │
   └── device 00:02.0

Linux reads:

Vendor ID
Device ID
Class Code
Header Type
BARs
Capabilities
PCIe Capability
MSI/MSI-X
Subsystem ID
...

So the fundamental discovery mechanism is PCI configuration space, not ACPI.

3. What is ACPI’s role then?

ACPI provides information that PCI configuration space cannot provide or that is platform-specific.

For example:

                    ACPI
                     │
        ┌────────────┼────────────┐
        │            │            │
       _CRS         _PRT         _OSC
        │            │            │
   resources       IRQ        PCIe ownership
        │
        ▼
   PCI Host Bridge
        │
        ▼
PCI configuration-space scan
        │
        ▼
   PCI devices

Important ACPI mechanisms include:

_CRS

Describes resources assigned to the host bridge.

For example:

PCI bus:
    Bus 0-255

PCI MMIO:
    0x80000000 - 0xFFFFFFFF

PCI I/O:
    0x0000 - 0xFFFF

Linux uses this to understand the address space available for PCI devices.

_PRT

Historically used to describe PCI interrupt routing.

For example:

PCI device
    │
    ├── INTA
    │
    └── _PRT
          │
          ▼
        GSI 16
          │
          ▼
        IOAPIC

On modern PCIe systems, MSI/MSI-X often makes _PRT less important for the device itself, but it can still matter for legacy INTx routing.

_OSC

This is particularly important for PCIe.

It allows the OS and firmware to negotiate control of PCI/PCIe features.

Conceptually:

Linux
  │
  │ _OSC
  ▼
ACPI firmware
  │
  ├── PCIe native hotplug
  ├── PME
  ├── AER
  ├── ASPM
  └── other PCIe capabilities

4. What about an onboard PCIe device?

This is probably the most important point.

Imagine a motherboard has an onboard:

Intel/AMD SoC
      │
      ▼
PCIe Root Port
      │
      ▼
Onboard NIC

Firmware may configure:

PCIe Root Port
Bus = 00
Device = 01
Function = 0

and the NIC appears at:

01:00.0

Linux then scans the PCI bus.

You can see it with:

lspci

For example:

00:01.0 PCI bridge: AMD PCIe Root Port
01:00.0 Ethernet controller: Realtek ...

The NIC’s:

Vendor ID
Device ID
Class
BAR
PCIe capabilities
MSI-X

come from PCI configuration space.

Not from the DSDT.

5. So why do I sometimes see PCI devices in ACPI?

Because ACPI may contain a corresponding ACPI namespace object for a PCI device or bridge, especially when the platform needs OS-visible device-specific functionality.

For example:

ACPI namespace

\_SB.PCI0.RP01
             │
             └── Device(...)

Linux can associate ACPI objects with PCI devices using the PCI address:

Segment
Bus
Device
Function

Conceptually:

ACPI Device
   │
   │ PCI address
   │
   ▼
0000:01:00.0
   │
   ▼
struct pci_dev

The ACPI object can provide additional information such as:

power management
reset methods
GPIO
DSM
hotplug
wake
platform-specific controls

6. Very important: _ADR

One common way ACPI identifies a PCI device is _ADR.

For example:

Device (DEV0)
{
    Name (_ADR, 0x00010000)
}

The encoding is:

31             16 15              0
+----------------+----------------+
|    Device      |    Function    |
+----------------+----------------+

For example:

Device = 1
Function = 0

_ADR = (1 << 16) | 0
     = 0x00010000

So ACPI can associate:

ACPI DEV0
    │
    │ _ADR = 0x00010000
    ▼
PCI device
01:00.0

But again, _ADR doesn’t cause PCI enumeration.

It identifies/augments an already-existing PCI device.

7. The complete Linux boot flow

For an onboard PCIe device, think about the process like this:

              BIOS / UEFI
                  │
                  │ ACPI tables
                  ▼
        ┌────────────────────┐
        │ DSDT / SSDT / MCFG │
        └─────────┬──────────┘
                  │
                  ▼
           Linux ACPI core
                  │
                  ▼
        PCI Host Bridge driver
                  │
                  │ _CRS
                  │ _OSC
                  │ _PRT
                  ▼
             PCI core
                  │
                  │ scan PCI bus
                  ▼
       PCI configuration space
                  │
       ┌──────────┼───────────┐
       │          │           │
       ▼          ▼           ▼
    Root Port    NIC        NVMe
    00:01.0    01:00.0     02:00.0
       │          │           │
       └──────────┼───────────┘
                  ▼
          struct pci_dev
                  │
                  ▼
        PCI driver matching
                  │
                  ▼
          Network / NVMe /
          other subsystem

8. Where does MCFG fit?

For modern PCIe systems, ACPI commonly provides the MCFG table.

It tells Linux where PCI Express Enhanced Configuration Space (ECAM) is mapped.

For example:

MCFG

Segment 0
Bus 0 - 255
ECAM base = 0xE0000000

Then Linux can calculate the configuration-space address.

Conceptually:

ECAM address =
    base
  + (bus      << 20)
  + (device   << 15)
  + (function << 12)
  + register

So for:

Bus      = 1
Device   = 0
Function = 0
Register = 0x00

Linux accesses:

0xE0000000
+ (1 << 20)
+ (0 << 15)
+ (0 << 12)
+ 0

and reads:

Vendor ID
Device ID

This is how Linux discovers the PCI device.

9. The key distinction

For firmware development, I would remember this table:

10. A very useful firmware/Linux debugging model

When you have an onboard PCIe device that doesn’t appear in Linux, debug it in this order:

BIOS
 │
 ├─ PCIe Root Port enabled?
 │
 ├─ PERST# released?
 │
 ├─ REFCLK present?
 │
 ├─ device link comes up?
 │
 ├─ PCIe enumeration in BIOS?
 │
 ├─ Bus numbers assigned?
 │
 ├─ BARs assigned?
 │
 └─ ACPI tables correct?
          │
          ▼
        Linux
          │
          ├─ PCI host bridge created?
          │
          ├─ PCI bus scanned?
          │
          ├─ lspci sees device?
          │
          ├─ BAR resources correct?
          │
          ├─ MSI/MSI-X works?
          │
          └─ driver binds?

The most important diagnostic split is:

If lspci cannot see the device → investigate PCIe hardware/link/firmware enumeration/host bridge configuration.

If lspci sees it but the driver doesn’t work → investigate PCI config space, BARs, IRQ/MSI, ACPI power/GPIO/DSM, and the Linux driver.

reboot

it looks like a simple operation.

But on an x86 platform, the Linux kernel usually doesn’t directly know which hardware register or EC command will reset the system.

That hardware-specific knowledge is provided by BIOS/UEFI through ACPI.

The diagram shows an interesting implementation where the platform uses Embedded Controller (EC) RAM as part of the ACPI reset mechanism.

1️⃣ BIOS/UEFI defines the reboot interface

During BIOS/UEFI development, the platform firmware builds the ACPI tables and publishes them to the OS.

One important table is the:

FADT — Fixed ACPI Description Table

The FADT can provide reset information such as:

ResetRegister
ResetValue
ResetCommand
ResetStatus

Conceptually, firmware is telling Linux:

“If you want to reset this platform, use this interface and this value.”

The important point is that Linux doesn’t need to understand the underlying board implementation.

The implementation could involve:

• EC

• PMIC

• PCH/chipset

• Super I/O

• GPIO

• PCI configuration space

• platform-specific reset logic

ACPI provides the abstraction layer.

2️⃣ Where does the FADT come from?

The boot flow is roughly:

BIOS / UEFI
     │
     ├── Build DSDT / SSDT
     ├── Build FADT
     ├── Build MADT / MCFG / HPET ...
     │
     ▼
ACPI Tables in Memory
     │
     ▼
RSDP
     │
     ▼
RSDT / XSDT
     │
     ▼
Linux Kernel

On a UEFI system, the firmware can provide the ACPI table information to the OS through the EFI configuration table.

Linux’s early ACPI initialization discovers the RSDP, follows the RSDT/XSDT, and eventually locates the FADT.

This is one of the most important concepts to understand when debugging UEFI → Linux platform handoff.

3️⃣ Linux doesn’t just “know” the reset register

Once Linux has parsed the FADT, the ACPI subsystem can obtain the reset information.

The conceptual flow is:

Linux reboot
     │
     ▼
Kernel reboot framework
     │
     ▼
ACPI reset handling
     │
     ▼
Read FADT reset information
     │
     ├── Reset Register
     ├── Reset Value
     └── Reset Command
     │
     ▼
Write to platform-defined interface
     │
     ▼
EC
     │
     ▼
Hardware Reset

This is a powerful firmware/OS separation:

BIOS describes the hardware.
Linux consumes the description.

4️⃣ Where EC RAM becomes interesting

Imagine the platform has an Embedded Controller with a RAM/register area:

EC RAM

0x66 ── Reset Register
0x67 ── Reset Status
0x68 ── Reset Command

Firmware can expose the appropriate reset interface through ACPI.

Then the EC firmware can implement something like:

Linux writes reset command
        │
        ▼
     EC RAM
        │
        ▼
EC firmware detects command
        │
        ▼
Execute reset sequence
        │
        ├── Disable / prepare EC functions
        ├── Notify platform
        ├── Assert reset
        └── Reset system

The actual EC implementation is platform-specific.

That’s the key idea:

ACPI standardizes the interface, while EC firmware implements the hardware behavior.

5️⃣ What happens after reboot?

A simplified sequence looks like this:

User
 │
 │  reboot -r now
 ▼
Linux Kernel
 │
 ▼
Reboot framework
 │
 ▼
ACPI subsystem
 │
 ▼
FADT
 │
 ├── ResetRegister
 ├── ResetValue
 └── ResetCommand
 │
 ▼
EC interface
 │
 ▼
EC RAM / EC register
 │
 ▼
EC firmware
 │
 ▼
Platform reset
 │
 ▼
CPU starts again
 │
 ▼
BIOS / UEFI

Notice something important:

Linux doesn’t need a special driver for every motherboard reset implementation.

That is exactly the value of ACPI.

6️⃣ What does the firmware engineer actually need to implement?

From the BIOS/UEFI side, you need to make sure that:

ACPI tables are correct

The FADT must describe the reset mechanism correctly.

The EC implementation matches the ACPI definition

If ACPI says:

ResetRegister = X
ResetValue    = Y

the EC/platform hardware must actually respond as expected.

The ACPI tables are published correctly

The OS must be able to discover:

RSDP
  ↓
XSDT
  ↓
FADT

The reset sequence is safe

The platform must handle the transition from:

Linux running
      ↓
shutdown/reboot preparation
      ↓
EC reset command
      ↓
platform reset

7️⃣ How do you debug this on Linux?

Start by dumping the ACPI tables:

sudo acpidump > acpi.dat

Extract the tables:

acpixtract -a acpi.dat

Disassemble AML:

iasl -d DSDT.dat

Check the kernel’s ACPI messages:

dmesg | grep -i acpi

Inspect tables exposed by Linux:

ls /sys/firmware/acpi/tables/

For example:

DSDT
SSDT1
SSDT2
FACP
APIC
MCFG
HPET
...

You can then compare:

BIOS source
     ↓
Compiled ACPI table
     ↓
Binary table in firmware
     ↓
/sys/firmware/acpi/tables/
     ↓
Linux ACPI parser

This is an extremely useful workflow when debugging a new platform.

8️⃣ The most important firmware lesson

When something like reboot, shutdown, thermal management, sleep, or device enumeration doesn’t work under Linux, don’t immediately assume:

“Linux needs a new driver.”

Sometimes the real problem is much earlier:

Hardware
   ↓
EC firmware
   ↓
BIOS/UEFI
   ↓
ACPI tables
   ↓
Linux ACPI subsystem
   ↓
Linux driver / subsystem

A mistake in any layer can produce an OS-level symptom.

For example:

Linux reboot fails
       │
       ├── Kernel problem?
       ├── ACPI parser?
       ├── Wrong FADT?
       ├── Wrong reset register?
       ├── Wrong reset value?
       ├── EC RAM mapping?
       ├── EC firmware?
       └── Platform reset hardware?

This is why ACPI debugging is a valuable skill for both UEFI engineers and Linux kernel engineers.

🔑 The big picture

ACPI is more than a collection of tables.

It is a contract between firmware and the operating system.

For reboot:

BIOS/UEFI
  "Here is the reset interface."
           │
           ▼
        ACPI FADT
           │
           ▼
     Linux ACPI Core
  "I understand the interface."
           │
           ▼
       EC / Hardware
  "I implement the reset."
           │
           ▼
        REBOOT 🔄

The same philosophy extends far beyond reboot—to CPU P-states/C-states, thermal zones, power buttons, sleep states, GPIO events, device enumeration, PCI resources, EC communication, and platform-specific control methods.

For firmware engineers moving into Linux, understanding this firmware → ACPI → kernel subsystem → hardware chain is one of the best ways to connect UEFI knowledge with Linux driver development.

If you’re debugging a Linux platform issue, always ask:
“What did the firmware actually tell Linux?”

#ACPI #UEFI #BIOS #Linux #LinuxKernel #Firmware #EDK2 #EmbeddedController #EC #PlatformFirmware #KernelDevelopment #EmbeddedSystems #SystemArchitecture #LinuxDriver #FirmwareEngineering #x86 #ACPI

David Zhu

Every modern x86 system runs on ACPI. It is the interface that lets the OS stop guessing about the hardware and start reading a machine-readable description of it: what CPUs exist, where the APIC is, how to put the machine to sleep, and where every PCIe device lives. The BIOS builds these tables at boot. Linux parses them to bring up the platform.

But the handoff is rarely explained end to end. What happens between firmware composing a DSDT and the kernel’s acpi_boot_table_init() finding the RSDP?

Let me walk the full pipeline — from ASL source to /sys/firmware/acpi/tables/.

Part 1: The ACPI Table Family

Before the flow, a quick map of the tables that matter. They are a directed graph rooted at a single pointer.

▸ RSDP — Root System Description Pointer. The entry point. A small structure with the signature "RSD PTR " that contains the physical address of the RSDT (32-bit) and/or XSDT (64-bit). Everything else is reachable from here.

▸ RSDT / XSDT — Root/Extended System Description Table. Arrays of pointers to every other ACPI table. RSDT holds 32-bit addresses, XSDT holds 64-bit. Modern systems use XSDT.

▸ FADT (FACP) — Fixed ACPI Description Table. Power management: fixed hardware register blocks, PM timer, sleep state (S3/S5) control, reset register.

▸ MADT (APIC) — Multiple APIC Description Table. CPU and interrupt controller topology: LAPIC entries, IOAPIC entries, interrupt source overrides.

▸ DSDT — Differentiated System Description Table. The primary device tree, written in AML bytecode. The namespace root — \_SB, \_PR, \_GPE — lives here.

▸ SSDT — Secondary System Description Table. Additional AML. CPU hotplug, device descriptions, and OEM-specific objects that extend the DSDT namespace.

▸ MCFG — PCIe ECAM table. Memory-mapped configuration space base addresses and segment groups for PCIe.

The critical detail: DSDT and SSDT are bytecode, not data structures. They are written in ASL (ACPI Source Language), compiled to AML (ACPI Machine Language) with iasl, and interpreted by the OS at runtime. The fixed tables (FADT, MADT, MCFG) are plain C structures.

Part 2: BIOS Side — Building the Tables

The AcpiTableDxe Driver

On EDK2, the core driver lives at MdeModulePkg/Universal/Acpi/AcpiTableDxe/. It produces the EFI_ACPI_TABLE_PROTOCOL — the interface platform code uses to register ACPI tables.

From AcpiTableDxe.c, the driver maintains an internal linked list of all tables (EFI_ACPI_TABLE_LIST). The key entry points are InstallAcpiTable() and UninstallAcpiTable(). The protocol also exposes GetAcpiTable(), which the OS loader can use to query the raw table data.

How Platform Code Registers Tables

Platform code — a dedicated DXE driver, or in many AMD/Intel reference designs the AcpiPlatform driver — composes each table and calls InstallAcpiTable():

▸ FADT — built as a C struct (EFI_ACPI_2_0_FIXED_ACPI_DESCRIPTION_TABLE), fields filled with the platform’s power management configuration.

▸ MADT — built dynamically based on the number of CPUs discovered during PEI/DXE, one LAPIC entry per core.

▸ DSDT/SSDT — the AML blobs produced at build time by iasl, embedded into the firmware image as binary arrays and installed verbatim.

Each InstallAcpiTable() call:

1. Validates the table’s 4-byte signature and checksum

2. Allocates a copy in EfiACPIReclaimMemory (a memory type the OS can safely reclaim after boot)

3. Appends the table to the driver’s internal list

4. Optionally triggers a rebuild of the RSDT/XSDT

Finalization: Publishing the RSDP

When boot reaches the point of OS handoff, the firmware finalizes the root tables and publishes the RSDP:

// From AcpiTableDxe — install the root pointer into the EFI config table Status = gBS->InstallConfigurationTable ( &gEfiAcpi20TableGuid, // ACPI 2.0+ (XSDT) AcpiTableInstance->Rsdp1 );

For ACPI 1.0 compatibility, the driver also installs gEfiAcpiTableGuid pointing to the RSDT-based RSDP.

The RSDP itself is a small structure:

struct RSDP { char Signature[8]; // “RSD PTR “ uint8_t Checksum; char OemId[6]; uint8_t Revision; // 0 = ACPI 1.0, 2 = ACPI 2.0+ uint32_t RsdtAddress; // 32-bit RSDT (always present) uint32_t Length; // RSDP length (ACPI 2.0+) uint64_t XsdtAddress; // 64-bit XSDT (ACPI 2.0+) uint8_t ExtendedChecksum; uint8_t Reserved[3]; };

The XSDT then points to every other table by 64-bit physical address.

The handoff mechanism differs by boot path:

▸ UEFI systems: The RSDP lives in the EFI Configuration Table. The OS loader (or the kernel’s EFI stub) reads it directly — no scanning.

▸ Legacy BIOS systems: The firmware writes the RSDP into the Extended BIOS Data Area (EBDA) or the top 128 KB of system memory (0x000E0000–0x000FFFFF). The OS finds it by scanning for the "RSD PTR " signature on a 16-byte boundary.

Both mechanisms target the same result: the OS ends up holding the RSDP’s XsdtAddress.

Part 3: Linux Side — Reading the Tables

Early Boot: Finding the RSDP

On x86, acpi_boot_table_init() runs very early — before PCI, before SMP. From drivers/acpi/tables.c:

acpi_status __init acpi_boot_table_init(void) { acpi_status status; status = acpi_initialize_tables(...); ... }

The RSDP discovery follows this order:

▸ UEFI systems: The kernel reads efi.acpi20 (or efi.acpi) from the EFI System Table, which contains the RSDP physical address directly.

▸ Legacy systems: acpi_find_root_pointer() scans low memory — first the EBDA, then the 0xE0000–0xFFFFF range — looking for the "RSD PTR " signature. On a hit it validates the checksum and revision.

Once the RSDP is found, the kernel extracts XsdtAddress, maps the XSDT into kernel virtual address space via early_ioremap(), and validates it.

Walking the XSDT

acpi_tb_parse_root_table() iterates the XSDT entries. Each entry is a 64-bit physical address of a table header. Every table found is stored in acpi_gbl_root_table_list — the kernel’s master index of ACPI tables, keyed by signature (DSDT, FADT, MADT, SSDT, MCFG, and dozens more).

At this point nothing is interpreted yet. The kernel has only catalogued the tables.

The AML Interpreter

The interesting part is what happens to DSDT/SSDT. The kernel’s AML interpreter (drivers/acpi/acpica/) loads the DSDT bytecode, builds the ACPI namespace, then loads each SSDT and merges it in.

The namespace is a tree of objects:

▸ _SB — system bus, contains PCI root bridges and devices

▸ _PR — processor objects

▸ _GPE — general-purpose events (sci/notify sources)

▸ _S0–_S5 — sleep state objects

Devices appear with ACPI Hardware IDs like PNP0C0D (lid button), PNP0C09 (embedded controller), or PNP0A03 (PCI host bridge). The ACPI driver enumerates these and creates the corresponding platform devices. Standard Linux drivers then bind to them exactly as they would to a PCI or platform device.

Sysfs Export

The kernel exposes every raw table as a binary file under /sys/firmware/acpi/tables/:

▸ DSDT — the primary AML table

▸ SSDT* — secondary AML tables (one file each)

▸ FACP — the FADT

▸ APIC — the MADT

▸ MCFG — PCIe ECAM

▸ XSDT — the root table itself

Userspace Tools

▸ acpidump — dumps all raw ACPI tables into one binary

▸ acpixtract — extracts individual tables from an acpidump

▸ iasl -d — disassembles an AML table back to readable ASL (the standard way to debug a misbehaving DSDT)

▸ dmesg | grep ACPI — the kernel logs every table it initializes, which is the first thing to check when ACPI misbehaves

Try this on any Linux box right now:

ls /sys/firmware/acpi/tables/ acpidump | acpixtract # or: cat /sys/firmware/acpi/tables/DSDT > /tmp/dsdt.aml iasl -d /tmp/dsdt.aml # read the actual device tree of your machine

The Full Flow in Summary

1. Platform ASL source is compiled to AML (DSDT/SSDT) with iasl at build time

2. Fixed tables (FADT, MADT, MCFG) are built as C structs at runtime

3. AcpiTableDxe installs EFI_ACPI_TABLE_PROTOCOL; platform code calls InstallAcpiTable() per table

4. Firmware builds the RSDP and publishes it via InstallConfigurationTable() (UEFI) or the EBDA/0xE0000 region (legacy)

5. Linux’s acpi_boot_table_init() reads the RSDP from the EFI config table or scans for “RSD PTR “

6. The kernel walks the XSDT, catalogues every table in acpi_gbl_root_table_list

7. The AML interpreter loads DSDT/SSDT and builds the ACPI namespace

8. Drivers bind to devices found in the namespace; raw tables are exposed at /sys/firmware/acpi/tables/

The elegant part: a single 8-byte signature string is the root of a graph that describes the entire machine. The BIOS writes a description; Linux reads it and brings the platform to life. No probing, no guessing, no hardcoded addresses — just a well-defined handoff that has scaled from 1996 laptops to today’s multi-socket servers.

#firmware #uefi #edk2 #acpi #linuxkernel #bios #embedded #x86 #gdbplus

When you call gBS->Stall(1000) in a DXE driver, a lot happens before that microsecond delay returns. But the timer that powers event-based timing — SetTimer(), EVT_TIMER events, the firmware’s heartbeat — is an entirely different mechanism. That mechanism is the Timer Architectural Protocol.

It’s one of only six Architectural Protocols the DXE Core requires to boot. Without it, the dispatcher halts with a fatal assertion. And yet it’s one of the simplest protocols in the PI specification: four function pointers, one handler slot, and a whole lot of trust placed in the platform to get the hardware programming right.

Let’s walk through the entire stack, from the protocol definition in MdePkg down to the CPU interrupt vector.

The Protocol: EFI_TIMER_ARCH_PROTOCOL

Defined in MdePkg/Include/Protocol/Timer.h, the protocol is astonishingly minimal:

struct _EFI_TIMER_ARCH_PROTOCOL {
  EFI_TIMER_REGISTER_HANDLER        RegisterHandler;
  EFI_TIMER_SET_TIMER_PERIOD        SetTimerPeriod;
  EFI_TIMER_GET_TIMER_PERIOD        GetTimerPeriod;
  EFI_TIMER_GENERATE_SOFT_INTERRUPT GenerateSoftInterrupt;
};

That’s it. Four function pointers. The GUID is { 0x26baccb3, 0x6f42, 0x11d4, {0xbc, 0xe7, 0x0, 0x80, 0xc7, 0x3c, 0x88, 0x81} }.

The protocol operates in units of 100 nanoseconds. A TimerPeriod of 100000 means “fire every 10 milliseconds.” The tick callback — EFI_TIMER_NOTIFY — receives a UINT64 Time parameter telling it how much time elapsed since the last tick (in 100ns units). If the hardware can detect missed interrupts, Time may be larger than TimerPeriod.

The Four Services

▸ RegisterHandler(NotifyFunction): Register or unregister the interrupt callback. Only ONE handler can be registered at a time — if one is already registered, you get EFI_ALREADY_STARTED. Pass NULL to unregister. The callback runs at TPL_HIGH_LEVEL, the highest task priority level in UEFI.

▸ SetTimerPeriod(TimerPeriod): Program the hardware timer frequency in 100ns units. The implementation rounds up to the nearest supported period. Pass 0 to disable timer interrupts entirely — this is not the same as CLI. The hardware stops generating interrupts, but the CPU’s interrupt flag is unaffected.

▸ GetTimerPeriod(*TimerPeriod): Return the current period. Returns 0 if the timer is disabled.

▸ GenerateSoftInterrupt(): Fire a software-generated timer interrupt. The registered handler executes exactly as if hardware triggered it — the handler cannot distinguish between a real interrupt and a soft one. Returns EFI_UNSUPPORTED if the platform doesn’t support software timer interrupts.

The Hardware Layer: Three Backends, One Protocol

EDK2 ships three implementations for different platforms. The DXE Core never knows which one it’s talking to — it just locates the protocol GUID and starts calling.

1. HPET Timer Dxe (PcAtChipsetPkg/HpetTimerDxe)

The High Precision Event Timer is the modern x86 standard. Key facts:

▸ Counter: 64-bit main counter, minimum 10 MHz clock, monotonically increasing
▸ Comparators: Up to 32 independent timer comparators; the driver uses one
▸ Periodic mode: The comparator is set to fire at a fixed interval
▸ MSI support: Can deliver interrupts via MSI (Message Signaled Interrupt) if PcdHpetMsiEnable is TRUE — bypasses the I/O APIC entirely
▸ PCDs consumed: PcdHpetBaseAddress, PcdHpetLocalApicVector, PcdHpetDefaultTimerPeriod

The HPET registers are memory-mapped at the address in the ACPI HPET table. The driver uses IoLib to program the General Configuration register, the Main Counter Value register, and the Timer N Comparator Value register.

2. Local APIC Timer Dxe (OvmfPkg/LocalApicTimerDxe)

Used in virtualized environments (OVMF, QEMU). The local APIC timer is per-CPU, simpler than HPET, and doesn’t require ACPI table parsing.

▸ Clock source: FSB (Front-Side Bus) clock, divided by a configurable divider (1, 2, 4, 8, 16, 32, 64, or 128)
▸ Frequency calculation: TimerCount = (TimerPeriod × PcdFSBClock) / 10,000,000
▸ Overflow guard: If TimerCount > MAX_UINT32, clamped to MAX_UINT32 with TimerPeriod = 429,496,730
▸ One-shot mode: The APIC timer is programmed in one-shot mode — the interrupt handler re-arms it on every tick
▸ Vector: LOCAL_APIC_TIMER_VECTOR — a fixed interrupt vector assigned by the platform

The initialization sequence in TimerDriverInitialize():

// 1. Assert protocol not already installed
ASSERT_PROTOCOL_ALREADY_INSTALLED(NULL, &gEfiTimerArchProtocolGuid);

// 2. Locate CPU Arch Protocol (needed for interrupt registration)
Status = gBS->LocateProtocol(&gEfiCpuArchProtocolGuid, NULL, (VOID **)&mCpu);

// 3. Force timer disabled initially
Status = TimerDriverSetTimerPeriod(&mTimer, 0);

// 4. Register interrupt handler
Status = mCpu->RegisterInterruptHandler(mCpu, LOCAL_APIC_TIMER_VECTOR,
                                         TimerInterruptHandler);

// 5. Enable timer at default period
Status = TimerDriverSetTimerPeriod(&mTimer, DEFAULT_TIMER_TICK_DURATION);

// 6. Install Timer Arch Protocol
Status = gBS->InstallMultipleProtocolInterfaces(&mTimerHandle,
            &gEfiTimerArchProtocolGuid, &mTimer, NULL);

The interrupt handler itself is straightforward. On each tick:

▸ Send EOI (End of Interrupt) to the local APIC
▸ Check if a notify function is registered
▸ Call it, passing mTimerPeriod as the time delta
▸ The handler uses NestedInterruptRestoreTPL to handle nested interrupts correctly

3. ARM Generic Timer Dxe (ArmPkg/Drivers/TimerDxe)

ARM platforms use the architectural generic timer, present in all ARMv7-A and ARMv8-A cores.

▸ System counter: 56-64 bit counter, fixed frequency (typically 1-50 MHz), accessible via CNTPCT_EL0 (physical) or CNTVCT_EL0 (virtual)
▸ Timer registers: CNTP_TVAL_EL0 (physical timer value), CNTP_CTL_EL0 (physical timer control)
▸ Interrupt: Private Peripheral Interrupt (PPI), routed through the GIC (Generic Interrupt Controller)
▸ Virtual timer offset: Hypervisors can offset CNTVCT_EL0 for guest migration — the virtual timer is preferred in virtualized ARM environments

The Consumer: How DXE Core Uses the Timer

Once the Timer Architectural Protocol is installed, the DXE Core discovers it during core initialization and registers its internal CoreTimerTick function.

CoreTimerTick — The Heartbeat

Every tick, the DXE Core’s timer callback performs this work:

▸ Advances mEfiSystemTime: The firmware’s wall clock advances by the timer period. This feeds GetTime() and RT->GetTime().

▸ Walks the timer event queue: All EVT_TIMER events are checked. If an event’s trigger time has passed, the event is signaled.

▸ Dispatches notify-signal callbacks: Events created with EVT_TIMER | EVT_NOTIFY_SIGNAL have their notification function called at TPL_HIGH_LEVEL.

▸ Decrements the watchdog: The boot watchdog timer (if enabled) counts down. If it hits zero, the system resets.

▸ Checks for periodic events: EVT_TIMER events created with TimerPeriod > 0 are re-armed for the next interval.

CoreStall() — A Different Mechanism

This is a common point of confusion. gBS->Stall() does not use the Timer Architectural Protocol. Instead:

▸ For short delays: spins on the CPU timestamp counter (AsmReadTsc() on x86) — pure busy-wait
▸ For longer delays: calls gMetronome->WaitForTick() — the Metronome Architectural Protocol, which is a separate abstraction
▸ The DXE Core’s CoreStall() falls back to a calibrated spin loop if the metronome is unavailable

The Timer Arch Protocol is for event-driven timing. Stall is for blocking delays. They serve different purposes and use different mechanisms.

SetTimer() and EVT_TIMER Events

When a driver calls gBS->SetTimer(Event, TimerRelative, 50000000), the DXE Core:

▸ Converts the trigger time (50,000,000 × 100ns = 5 seconds) to an absolute tick count
▸ Inserts the event into the timer event queue, sorted by trigger time
▸ On every CoreTimerTick call, checks if any event’s trigger time ≤ current tick count
▸ When the event fires: if EVT_NOTIFY_SIGNAL, calls the notify function; if EVT_NOTIFY_WAIT, signals the event so WaitForEvent() unblocks

Why an Architectural Protocol?

The PI specification defines six “Architectural Protocols” that are mandatory for the DXE Core to function:

▸ CPU Architectural Protocol — interrupt management, flush caches, read timers
▸ RTC Architectural Protocol — real-time clock access
▸ Timer Architectural Protocol — periodic timer interrupt (this one)
▸ Metronome Architectural Protocol — fixed-rate tick for Stall()
▸ Watchdog Timer Architectural Protocol — boot watchdog
▸ Variable Write Architectural Protocol — non-volatile variable storage

Each Architectural Protocol represents a hardware capability that the DXE Core cannot function without. If any of them is missing when the DXE Core initializes, the dispatcher asserts and the boot halts.

The “Architectural” designation means the protocol is defined by the PI specification itself — not by a vendor or an interest group. All UEFI-compliant platforms must provide an implementation.

Debugging Tips

If you’re bringing up a new platform and the DXE Core hangs during initialization:

▸ Check the serial log for “Arch Protocol”: The DXE Core prints which Architectural Protocols it’s waiting for. If you see it stuck waiting for the timer, your timer driver isn’t being dispatched.

▸ Verify DEPEX: The timer driver’s [Depex] section may require gEfiCpuArchProtocolGuid. If the CPU Arch Protocol isn’t installed yet, the timer driver won’t load.

▸ Assert in InstallMultipleProtocolInterfaces: Each timer driver does ASSERT_PROTOCOL_ALREADY_INSTALLED before installing. If two timer drivers try to install, the second one asserts. Check your platform DSC — you should only include ONE timer driver.

▸ Interrupt not firing: If the protocol installs but CoreTimerTick is never called, check the interrupt routing. On x86, verify the I/O APIC redirection table entry for the timer vector. On ARM, check the GIC distributor configuration for the timer PPI.

▸ SetTimerPeriod(0) confusion: If you call SetTimerPeriod(0) and events stop firing, that’s expected behavior — you disabled the timer. The DXE Core does this intentionally during critical sections.

Bottom Line

The Timer Architectural Protocol is a masterclass in firmware abstraction. Four functions. One handler slot. Three completely different hardware implementations. And the consumer — the DXE Core — never knows which one is running underneath.

That’s the power of UEFI’s protocol model. The interface is the contract. The implementation is the platform’s problem.

David Zhu writes about UEFI firmware internals, EDK2 implementation details, and embedded systems at gdbplus.substack.com. If you’re debugging a DXE driver or bringing up a new platform, there’s more where this came from.

You didn’t change a thing. You just plugged in a diagnostic tool.

Welcome to one of firmware’s most insidious timing traps: the I/O port 80 delay gotcha. And to understand it properly, we need to start with the CPU feature that makes precise timing possible in the first place — the Time Stamp Counter.

Part 1: The Time Stamp Counter — Your CPU’s Built-in Stopwatch

Every modern x86 CPU has a hidden clock ticking away inside it. Actually, it’s not hidden at all — it’s the Time Stamp Counter (TSC), and it’s been there since the Intel Pentium and AMD K5 days.

The TSC is a 64-bit register that increments with every core clock cycle. Reset it at power-on, and it counts up. And up. At 2 GHz, it won’t wrap around for roughly 292 years. It’s accessible through a single instruction:

rdtsc             ; EDX:EAX ← 64-bit TSC value
                  ; ~20–30 cycles on modern CPUs

That’s it. One instruction, ~20-30 cycles of overhead, and you have a high-precision timestamp. The upper 32 bits land in EDX, the lower 32 in EAX. Combine them into a 64-bit value and you’ve got a monotonically-increasing counter with sub-nanosecond granularity.

Invariant TSC: The Game-Changer

On older CPUs, the TSC had a dirty secret: it wasn’t reliable. If the CPU changed frequency (P-state transitions), the TSC rate changed too. Two timestamps taken seconds apart could be wildly inaccurate if a frequency shift happened in between.

This was fixed with the invariant TSC, guaranteed by CPUID leaf 0x80000007:EDX[8]. On any CPU that advertises this feature (which is every x86 chip from the last 15+ years), the TSC ticks at a constant rate regardless of:

• P-state (frequency scaling)

• C-state (power saving)

• Which core you’re reading from

All cores share the same underlying tick source. The TSC became the gold standard for high-performance timing on x86. Linux even uses it as its preferred clock source — run cat /sys/devices/system/clocksource/clocksource0/current_clocksource and you’ll almost certainly see tsc.

There’s also RDTSCP, a serialized variant that guarantees all previous instructions have completed before the TSC is read — important for precise benchmarking where you don’t want out-of-order execution to skew your measurements.

What Firmware Actually Uses TSC For

In the UEFI/BIOS world, the TSC is a workhorse:

▸ Performance profiling — wrap a PEIM dispatch or DXE driver entry point with RDTSC, compute the delta, and you know exactly how long it took.

▸ Spin-wait delays — when you need a microsecond-level delay and the timer hardware isn’t ready yet (hello, early PEI phase before the ACPI timer is configured), you spin on TSC deltas.

▸ Microbenchmarks — DDR training, PCIe link initialization, USB controller reset sequences — all need precise timing measurements.

▸ Event timestamping — correlate firmware log entries with hardware events at cycle-level precision.

▸ APIC timer calibration — measure the bus clock to configure the Local APIC timer divisor.

The TSC is fast, precise, and universally available. It’s the closest thing firmware has to a Swiss Army knife for timing.

But what do you do when you’re in really early boot — before memory is initialized, before the chipset timers are configured, and you just need a cheap, predictable delay? Something that takes a handful of microseconds and doesn’t depend on any initialized hardware?

Enter the I/O port read trick.

Part 2: The I/O Port 80 Trick — A Convenient Lie

In the early stages of firmware initialization — SEC and PEI phases in UEFI PI parlance, or the reset vector through early POST in traditional BIOS — your toolbox is extremely limited. DRAM isn’t up yet. The 8254 PIT might not be configured. The HPET isn’t enumerated. The TSC works, but TSC-based spin-wait loops need the invariant TSC guarantee, and on some platforms you haven’t confirmed CPUID leaf 0x80000007 yet.

So firmware developers reach for the oldest trick in the x86 book: an I/O port read as a delay.

An I/O bus cycle on x86 takes a predictable amount of time — roughly 1 microsecond on typical hardware when no device responds. The CPU issues the read, the bus controller waits through the ISA/LPC bus cycle timeout, nobody claims the transaction, and the bus controller returns ~0xFF to the CPU. End of story. Consistent, reliable, available from the very first instruction after reset.

And which I/O port gets abused for this purpose? Port 80h.

Why? Because firmware is already writing POST codes to port 80h. It’s the standard diagnostic port — every BIOS since the IBM PC/AT has written checkpoint codes to port 80h during boot. The code is already there, the port address is hard-coded into every firmware codebase on the planet, and adding a read after the write seems harmless:

// Classic firmware delay pattern (WRONG)
IoWrite8(0x80, PostCode);   // Write POST checkpoint
IoRead8(0x80);              // Read-back for ~1μs delay

The write sends the POST code to any attached debug hardware. The read — the thinking goes — just burns ~1 microsecond while the bus controller waits for a device that isn’t there.

This works perfectly. Until it doesn’t.

Part 3: The Trap — When Port 80h Has a Listener

The moment you plug in a POST debug card — whether it’s a PCIe POST card, an LPC debug module, or a BMC with port 80h snooping — everything changes.

That debug card isn’t passively watching. It’s actively decoding I/O cycles targeting port 80h. When the CPU issues inb(0x80), the card sees the address on the bus, recognizes it as port 80h, and asserts its claim.

Here’s the critical mechanism: on the ISA bus (and its LPC successor), a slow device can stretch the bus cycle by de-asserting IOCHRDY (I/O Channel Ready). This inserts wait states. The CPU sits there, held, waiting for the device to finish whatever it’s doing and re-assert IOCHRDY.

A debug card is, by design, a slow device. It’s a microcontroller running at a few tens of MHz, connected through an LPC-to-SPI bridge or similar, reading the port value, formatting it for a 7-segment display or UART output. It needs time to process. So it holds IOCHRDY low.

The result: your “1 microsecond” delay becomes 5 microseconds. Or 10. Or 50. Or more.

A slow device on the bus can hold the I/O cycle arbitrarily long.

There’s no timeout in the ISA/LPC bus protocol for IOCHRDY. The device can theoretically hold it forever. In practice, most debug cards add 5-50μs per access, but I’ve seen worse. And if your firmware code reads port 80h in a tight loop for timing — say, 100 iterations for a “100μs delay” — you’re now waiting anywhere from 500μs to 5ms. Per delay loop.

Imagine what happens to a boot sequence that has dozens of these scattered through early initialization. Suddenly your 3-second POST becomes 15 seconds. Peripherals with tight initialization timeouts start failing. The watchdog timer fires because a critical section overran its budget.

All because of a debug card. The tool that’s supposed to help you debug is actually creating bugs.

Part 4: The Performance Numbers

Let’s quantify this. On a typical Intel platform with an LPC debug card:

▸ Without debug card: ~1.0–1.2μs per inb(0x80) — the bus controller’s no-device timeout is predictable and fast.

▸ With debug card (quality LPC POST card): ~5–8μs per inb(0x80) — the card’s microcontroller needs time to latch and display.

▸ With debug card (cheap USB-to-LPC analyzer): ~15–50μs per inb(0x80) — slower bridge chips, more processing overhead.

▸ With BMC snooping port 80h: variable — anywhere from 3μs to 100μs depending on BMC load and the snooping implementation.

That’s a 5–50× slowdown from a single hardware addition. And it’s not proportional — it’s a step function. The moment that debug card is plugged in, every port 80h access in your entire firmware codebase gets slower. You can’t selectively exempt some accesses; the bus doesn’t work that way.

Part 5: The Fix — Unclaimed Ports

The solution is simple once you understand the mechanism: use an I/O port that no device decodes.

On x86 platforms, the I/O address space is 64KB (0x0000–0xFFFF), but only a fraction of it is claimed by real hardware. The rest is empty — no device responds, so the bus controller times out immediately and returns ~0xFF.

Some safe unclaimed ports commonly used in firmware:

▸ 0xED — widely used in EDK2 and coreboot for delay purposes
▸ 0xEE — also common, same behavior
▸ 0xEF — another safe choice
▸ 0xEB — occasionally used, but verify your platform isn’t using it

The corrected code:

// Correct approach: separate POST code write from delay
IoWrite8(0x80, PostCode);   // Write POST checkpoint (debug card sees this)
IoRead8(0xED);              // Read unclaimed port for delay (debug card ignores this)

The write to port 80h still goes to the debug card — good, you want that for diagnostics. But the delay read goes to port 0xED, which no device claims. The bus controller times out immediately (~1μs), and your timing is consistent regardless of whether a debug card is plugged in.

But Wait — What About the Write?

An important nuance: writing to port 80h is typically not a performance problem, even with a debug card. Here’s why:

On the ISA/LPC bus, writes are posted. The CPU issues the write and continues executing; the bus controller acknowledges immediately and the data eventually reaches the device. The CPU doesn’t wait for the device to accept the data. Reads, however, are non-posted — the CPU must wait for the data to come back. That’s why outb(0x80, val) is fast but inb(0x80) can be slow.

So keep the POST code writes to port 80h — they’re valuable for debugging. Just separate the delay mechanism from the debug port.

Part 6: How to Detect This in Your Own Codebase

If you maintain or work with firmware that does I/O port delays, here’s how to audit:

▸ Step 1: Grep for 0x80 or 0x0080 in your codebase. Look for inb, IoRead8, __inbyte, or whatever I/O abstraction your codebase uses.

▸ Step 2: For each match, ask: is this being used for timing (delay, spin-wait, microsecond wait) or purely for POST code display?

▸ Step 3: If it’s timing, replace 0x80 with 0xED (or another verified-unclaimed port on your platform).

▸ Step 4: Add a comment. Future-you will thank present-you:

//
// Port 0xED is unclaimed on this platform.
// DO NOT change to 0x80 — debug cards will stretch the bus cycle.
//
IoRead8(0xED);

▸ Step 5: Test with AND without a debug card. Your boot time should be identical in both configurations.

EDK2 Already Does This (Mostly)

If you’re working with EDK2, search for IoRead8 (0xED) — you’ll find it used extensively, especially in early PEI modules and chipset initialization code. The EDK2 community learned this lesson the hard way years ago. But legacy code, vendor BLOBs, and older codebases still have port 80h delay patterns hiding in them.

Part 7: The Bigger Lesson

This isn’t really about port 80h. It’s about a fundamental principle of hardware-near programming:

Hardware that you think is passive may be actively participating in your bus transactions.

A debug card isn’t a passive monitor. An oscilloscope probe isn’t passive. A JTAG debugger isn’t passive. Any tool that connects to your platform’s buses or signals can change the timing characteristics of the system you’re trying to measure.

Other examples of the same class of problem:

▸ JTAG/SWD debuggers — setting breakpoints can change cache behavior and execution timing. A Heisenbug that disappears when you attach the debugger? That’s this principle in reverse.

▸ Logic analyzers — probe capacitance can alter signal rise times on high-speed buses. Your DDR training that passes with no probes attached may fail with probes.

▸ Serial console — UART output at 115200 baud can add milliseconds of delay per print statement. Your firmware that works fine with serial logging disabled may hit race conditions when logging is enabled.

▸ SPI flash programmers — in-system programming tools that hold the flash in reset can cause the chipset to time out on the SPI bus, triggering unexpected error paths.

The common thread: measurement changes the system. Always validate your firmware timing in the configuration that most closely matches production — and in the configuration that exposes the worst-case timing.

Bottom Line

The TSC and port 80h delay trap represent two sides of the same coin: precise timing in firmware is both essential and fragile.

The TSC gives you cycle-accurate measurement for profiling, benchmarking, and calibration. Use it. It’s one of the most reliable timing primitives on x86, and the invariant TSC guarantee means it works the same way on every modern platform.

But when you need a quick delay in early boot — before the timers are up, before memory is initialized — reach for an I/O port read. Just don’t reach for port 80h. The POST code debug port has one job: displaying POST codes. Let it do that job, and use an unclaimed port (0xED, 0xEE) for your delays.

The debug card you plug in to find timing bugs shouldn’t be the cause of them.

David Zhu is a firmware engineer working on UEFI BIOS, embedded systems, and hardware-near software. He writes about the dark corners of x86 platform initialization at gdbplus.substack.com.

One of the first things every firmware engineer does on a new board is print “Hello World.” Surprisingly, making that message appear consistently across every boot stage is much more complicated than simply programming a 16550 UART.

Introduction

When bringing up an AMD platform, one of the first milestones is obtaining serial debug output.

Most engineers expect writing to I/O port 0x3F8 (COM1) or 0x2F8 (COM2) to “just work.”

In reality, the debug path changes several times during boot:

Power On
    │
    ▼
+--------------------+
| PSP Boot ROM       |
+--------------------+
    │
    ▼
+--------------------+
| PSP Firmware       |
+--------------------+
    │
    ▼
+--------------------+
| AMD ABL            |
| (AGESA Bootloader) |
+--------------------+
    │
    ▼
+--------------------+
| UEFI BIOS          |
| SEC→PEI→DXE→BDS    |
+--------------------+
    │
    ▼
+--------------------+
| Linux Kernel       |
+--------------------+

Every stage uses different software.

Every stage has different ownership of the UART.

Understanding how the same COM port remains usable across the entire boot process is an important topic for BIOS and platform firmware engineers.

The Legacy COM Port

The PC architecture has defined two classic UART addresses for decades.

PortIO BaseIRQCOM10x3F8IRQ4COM20x2F8IRQ3

These addresses are part of the IBM PC architecture and remain supported today—even on modern AMD Zen 5 systems.

Applications simply perform:

outb(character, 0x3F8);

without caring whether the underlying UART is inside:

• Super I/O
  

• Embedded Controller
  

• AMD SoC
  

• FPGA
  

• PCIe device
  

The platform firmware hides those implementation details.

Modern AMD UART Architecture

On modern AMD platforms there is no ISA bus anymore.

Instead, communication flows like this:

             AMD SoC
      +----------------------+
      |                      |
      |  CPU                 |
      |                      |
      | PSP                  |
      | SMU                  |
      |                      |
      | UART Controller      |
      +----------+-----------+
                 |
              eSPI/LPC
                 |
      +----------+-----------+
      |     PCH / EC         |
      +----------+-----------+
                 |
          UART Connector

The CPU does not directly expose ISA hardware.

Instead:

• eSPI
  

• LPC bridge
  

• UART controller
  

• IO decoder
  

combine to emulate traditional PC I/O space.

Step 1 — PSP Initializes the UART

The first executable firmware is the PSP ROM.

At this point:

• DRAM is unavailable
  

• x86 cores are still asleep
  

• PCI enumeration hasn’t happened
  

• BIOS has not executed
  

The PSP performs minimal hardware initialization.

Typical operations include:

• clock enable
  

• reset release
  

• UART mux selection
  

• GPIO pin configuration
  

Example:

PSP
 │
 ├── Enable UART Clock
 ├── Configure GPIO
 ├── Set Baud Rate
 ├── Enable FIFO
 └── Output Debug Characters

Many AMD internal debug messages originate here.

Step 2 — AMD ABL Uses the Same UART

Next comes AMD Boot Loader (ABL).

ABL performs:

• DDR initialization
  

• SoC initialization
  

• fabric setup
  

• SMU communication
  

• handing off to BIOS
  

Instead of creating another UART driver, ABL usually reuses the initialized UART.

PSP
    │
UART already configured
    │
    ▼
ABL
    │
Print("Memory Init...")

This allows uninterrupted serial logs from the earliest boot stages.

Step 3 — BIOS Takes Ownership

Once x86 execution begins:

SEC
PEI
DXE

the BIOS becomes responsible for serial output.

The BIOS serial driver usually performs:

16550 Initialization

DLL
DLM
FCR
LCR
MCR
IER

and exposes a standard Serial Port Library.

Example:

SerialPortWrite();

DebugPrint();

ASSERT();

In EDK2:

DebugLib
      │
SerialPortLib
      │
16550 Driver
      │
UART Hardware

From this point onward every DEBUG() macro eventually reaches COM1.

Step 4 — ACPI Describes the UART

Before booting Linux, BIOS must describe the UART.

There are two common methods.

Legacy PC

COM1 simply exists.

Linux probes:

0x3F8
IRQ4

No Device Tree required.

Modern ACPI

BIOS publishes the UART in ACPI.

Example resources include:

Memory Region

Interrupt

Clock

Power Resource

Linux reads ACPI and loads the appropriate driver.

Step 5 — Linux Loads the Driver

After ExitBootServices():

Linux
   │
ACPI Enumeration
   │
8250 Driver
   │
ttyS0

The driver initializes:

FIFO

Interrupt

DMA (optional)

Console

Applications now use:

printf()

dmesg

systemd

login

shell

All through the same UART.

Keeping the Same UART Alive

One challenge is ensuring every stage uses the same hardware configuration.

PSP
 │
 ▼
ABL
 │
 ▼
BIOS
 │
 ▼
Linux

If one stage changes:

• baud rate
  

• clock source
  

• GPIO mux
  

• FIFO mode
  

the serial log becomes unreadable.

Typical bring-up practice is:

• 115200 baud
  

• 8 data bits
  

• no parity
  

• 1 stop bit
  

• leave UART enabled
  

allowing continuous logging throughout boot.

How Does 0x3F8 Actually Reach the UART?

When x86 executes:

OUT 0x3F8, AL

the processor does not directly drive UART pins.

Instead, the transaction passes through several hardware blocks:

CPU
 │
IO Instruction
 │
IO Decode
 │
eSPI/LPC Bridge
 │
UART Controller
 │
TX FIFO
 │
Serial Pin

This compatibility layer allows software written decades ago to continue functioning on modern AMD systems.

Why Does Linux Still Call It ttyS0?

Linux’s 8250/16550 subsystem preserves decades of compatibility.

COM1
 ↓
0x3F8
 ↓
8250 Driver
 ↓
ttyS0

Even on a cutting-edge Zen 5 platform, the familiar /dev/ttyS0 often represents the same logical serial port used by the PSP, ABL, and BIOS during boot.

Debug Flow Across the Entire Boot Chain

A complete serial log typically looks like this:

Power On

↓

PSP ROM
    "PSP Boot..."

↓

PSP Firmware
    "Loading ABL..."

↓

AMD ABL
    "DDR Training..."

↓

UEFI SEC
    "SEC Entry"

↓

PEI
    "Memory Installed"

↓

DXE
    "PCI Enumeration"

↓

BDS
    "Boot Option"

↓

Linux
    "Starting kernel..."

↓

systemd

↓

Login Prompt

Capturing this uninterrupted stream is invaluable when diagnosing early boot failures, memory training issues, or kernel startup problems.

Best Practices for Firmware Engineers

When enabling UART debug on AMD platforms:

• Configure the UART as early as possible in the PSP or ABL stage.
  

• Use a consistent baud rate (typically 115200 8N1) across all boot phases.
  

• Avoid reinitializing the UART unless configuration changes are necessary.
  

• Ensure the BIOS correctly advertises the serial port through ACPI (or Device Tree on embedded platforms).
  

• Use a shared SerialPortLib implementation to keep debug output consistent.
  

• Verify that Linux receives the correct console= kernel parameter (for example, console=ttyS0,115200).
  

• Keep UART enabled until the operating system has fully taken ownership to preserve a continuous debug log.
  

Conclusion

Although COM1 (0x3F8) and COM2 (0x2F8) date back to the original IBM PC, they remain central to modern platform bring-up. On AMD Zen platforms, the same logical UART can be used seamlessly by the PSP, AMD ABL, UEFI BIOS, and Linux, providing an uninterrupted window into the system from the first instruction after reset to the operating system login prompt.

For firmware engineers, understanding this handoff is more than an academic exercise—it is one of the most effective tools for debugging platform initialization, memory training, silicon bring-up, and early kernel boot.

Every x86 system you touch — laptop, server, embedded board — carries a SMBIOS table. It is the single source of truth for “what hardware is in this box.” The BIOS builds it during boot. Linux reads it to populate /sys/class/dmi/id/. dmidecode decodes it for your shell scripts and inventory tools.

But how does it actually get there? What happens between the EDK2 firmware calling SmbiosAdd() and the Linux kernel’s dmi_scan_machine() finding the anchor string?

Let me walk through the full pipeline — from EDK2 driver to Linux sysfs

.

Part 1: EDK2 Side — Building the Table

The SmbiosDxe Driver

The core driver lives at MdeModulePkg/Universal/SmbiosDxe/. It is a standard DXE driver that produces the EFI_SMBIOS_PROTOCOL — the interface platform code uses to register SMBIOS structures.

From SmbiosDxe.c, the driver entry point:

From MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.c, SmbiosDriverEntryPoint():

mPrivateData.Smbios.Add = SmbiosAdd;
mPrivateData.Smbios.UpdateString = SmbiosUpdateString;
mPrivateData.Smbios.Remove = SmbiosRemove;
mPrivateData.Smbios.GetNext = SmbiosGetNext;
mPrivateData.Smbios.MajorVersion = (UINT8)(PcdGet16 (PcdSmbiosVersion) >> 8);
mPrivateData.Smbios.MinorVersion = (UINT8)(PcdGet16 (PcdSmbiosVersion) & 0x00ff);

Status = gBS->InstallProtocolInterface (
&mPrivateData.Handle,
&gEfiSmbiosProtocolGuid,
EFI_NATIVE_INTERFACE,
&mPrivateData.Smbios
);

The driver maintains an internal linked list of all SMBIOS structures — each one an EFI_SMBIOS_ENTRY tracked by the private SMBIOS_INSTANCE.

How Platform Code Populates Tables

Platform code — typically a separate DXE driver like EmulatorPkg/PlatformSmbiosDxe/ — calls SmbiosProtocol->Add() for each SMBIOS type:

▸ Type 0: BIOS Information — vendor string, version, release date

▸ Type 1: System Information — manufacturer, product name, serial, UUID

▸ Type 2: Baseboard — motherboard vendor, product, version

▸ Type 3: Chassis — enclosure type, manufacturer, asset tag

▸ Type 4: Processor Information — socket, family, speed, cores

▸ Type 7: Cache Information — L1/L2/L3, size, associativity

▸ Type 17: Memory Device — DIMM size, speed, manufacturer, serial

Each call to Add() follows the same sequence inside SmbiosDxe:

1. GetSmbiosStructureSize() calculates the total size including the string table area at the end of the structure

2. The record is allocated as an EFI_SMBIOS_ENTRY with an internal EFI_SMBIOS_RECORD_HEADER

3. A SMBIOS_HANDLE_ENTRY is created and inserted into the allocated handle list

4. The structure is inserted into the DataListHead linked list via InsertTailList()

5. SmbiosTableConstruction() is called to rebuild the flattened SMBIOS table

The Anchor and Entry Point Structure

The SMBIOS 2.x Entry Point Structure (EPS) uses the anchor string SM and intermediate anchor DMI. From SmbiosDxe.c:

EntryPointStructureData = {
{ 0x5f, 0x53, 0x4d, 0x5f }, // “SM“ AnchorString
0, // Checksum (filled later)
0x1f, // EntryPointLength
0, // MajorVersion
0, // MinorVersion
0, // MaxStructureSize
0, // EntryPointRevision
{ 0, 0, 0, 0, 0 }, // FormattedArea
{ 0x5f, 0x44, 0x4d, 0x49, 0x5f }, // “DMI“ IntermediateAnchorString
0, // IntermediateChecksum
0, // TableLength
0, // TableAddress (physical)
0, // NumberOfSmbiosStructures
0 // SmbiosBcdRevision
};

For SMBIOS 3.0, the 64-bit EPS uses anchor SM3 and a simpler layout: anchor, checksum, length, major/minor version, document revision, entry point revision, reserved, and a 64-bit structure table maximum size.

Finalization: SmbiosTableConstruction()

When structures are added (or on removal), SmbiosTableConstruction() assembles the final table and publishes it to the UEFI Configuration Table:

if (Smbios32BitTable) {
Status = SmbiosCreateTable ((VOID **)&Eps);
if (!EFI_ERROR (Status)) {
gBS->InstallConfigurationTable (&gEfiSmbiosTableGuid, Eps);
}
}

if (Smbios64BitTable) {
Status = SmbiosCreate64BitTable ((VOID **)&Eps64Bit);
if (!EFI_ERROR (Status)) {
gBS->InstallConfigurationTable (&gEfiSmbios3TableGuid, Eps64Bit);
}
}

This is the critical handoff: the SMBIOS table is registered with the EFI firmware via InstallConfigurationTable(). When the OS bootloader or kernel queries the EFI System Table, it reads the SMBIOS table pointer directly from the list of configuration tables — no memory scanning required on UEFI systems.

The 32-bit table is allocated below 4 GB (AllocateMaxAddress at 0xFFFFFFFF). The 64-bit table can live anywhere in the physical address space.

Part 2: Linux Side — Reading the Tables

Early Boot: dmi_scan_machine()

On x86, the Linux kernel calls dmi_scan_machine() from arch/x86/kernel/dmi_scan.c extremely early in boot — before ACPI, before PCI enumeration. Two paths exist:

▸ UEFI systems: The kernel reads the SMBIOS entry point from the EFI Configuration Table (efi.smbios or efi.smbios3). No scanning needed.

▸ Legacy BIOS systems: The kernel scans physical memory from 0x000F0000 to 0x000FFFFF in 16-byte increments, looking for the SM or SM3 anchor strings.

In either case, the kernel validates the EPS checksum, extracts the structure table physical address and length, and maps the table into kernel virtual address space via early_ioremap(). It then walks the type-length-handle headers to decode each SMBIOS structure.

The Sysfs Interface

Once the kernel finishes decoding, the dmi_id driver creates the /sys/class/dmi/id/ directory with individual files for each field:

▸ bios_vendor — SMBIOS Type 0, vendor string

▸ bios_version — SMBIOS Type 0, BIOS version

▸ bios_date — SMBIOS Type 0, release date

▸ sys_vendor — SMBIOS Type 1, system manufacturer

▸ product_name — SMBIOS Type 1, product name

▸ product_serial — SMBIOS Type 1, serial number

▸ product_uuid — SMBIOS Type 1, UUID

▸ board_vendor — SMBIOS Type 2, baseboard manufacturer

▸ board_name — SMBIOS Type 2, baseboard product name

▸ chassis_vendor — SMBIOS Type 3, chassis manufacturer

▸ chassis_type — SMBIOS Type 3, chassis type enumeration

▸ processor_* — SMBIOS Type 4, multiple CPU info files

These files are plain text, readable without root. Try: cat /sys/class/dmi/id/product_name — it works on your machine right now.

The raw binary tables are also exposed via /sys/firmware/dmi/tables/:

▸ DMI — the raw SMBIOS 2.x entry point structure

▸ smbios_entry_point — the SMBIOS 3.0 entry point (if present)

▸ DMI — the raw structure table

Userspace: dmidecode

The dmidecode tool reads these kernel interfaces. On modern kernels it prefers /sys/firmware/dmi/tables/ (the raw binary tables). On older systems it falls back to reading /dev/mem directly (requires root).

Common queries:

▸ dmidecode -t bios — BIOS vendor, version, release date, ROM size, characteristics

▸ dmidecode -t system — System manufacturer, product name, serial, UUID, wake-up type

▸ dmidecode -t baseboard — Motherboard vendor, product, version, asset tag

▸ dmidecode -t processor — Socket designation, type, family, speed, core count, thread count

▸ dmidecode -t memory — Each DIMM slot: size, type, speed, manufacturer, serial, part number

▸ dmidecode -t 17 — Same as -t memory, but using the raw type number

These queries power inventory scripts in data centers, hardware detection in provisioning systems, and forensic analysis tools.

The Full Flow in Summary

1. Platform DXE driver populates SMBIOS type structures at boot

2. SmbiosProtocol->Add() stores each structure in an internal linked list

3. SmbiosTableConstruction() flattens the list, builds the EPS with correct checksums

4. gBS->InstallConfigurationTable() publishes the table to the EFI System Table

5. Linux kernel reads the table pointer from the EFI Configuration Table

6. dmi_decode() walks the structure table, fills dmi_dev entries

7. /sys/class/dmi/id/ is created with human-readable fields

8. dmidecode (or direct sysfs reads) gives userspace full access

The same SMBIOS table that EDK2 assembled in firmware memory is what you read with dmidecode -t bios — with no intermediate format conversion, no parsing ambiguity, and no configuration. It just works.

#firmware #uefi #edk2 #linuxkernel #smbios #embedded #x86 #gdbplus

Your J-Link can’t connect. The serial download tool times out. The chip powers up but won’t talk.

You start questioning the hardware — is the MCU dead? Is the SWD trace broken? Did you fry something with static?

Then you remember: check the boot pins.

The Situation

I had an STM32 development board. The onboard pulldown resistor ties BOOT0 to GND — factory default, perfectly normal. The chip boots from Flash, as intended.

Two problems appeared simultaneously:

▸ Serial ISP (FlyMCU): No response on UART. The chip never entered the bootloader to listen.

▸ J-Link (SWD): Cannot connect. The debug probe handshake timed out, no matter how many times I power-cycled.

The power LED was on. The 3.3V rail measured fine. The chip wasn’t dead — it just couldn’t hear anything I was sending.

The Root Cause: BOOT0 = 0

STM32 determines its boot source by sampling BOOT0 and BOOT1 at the rising edge of nRST. The truth table is burned into every STM32 reference manual, but worth repeating:

▸ BOOT0=0, BOOT1=X: Main Flash memory (0x0800 0000) — the default

▸ BOOT0=1, BOOT1=0: System Memory bootloader (0x1FFF 0000) — the ISP interface

▸ BOOT0=1, BOOT1=1: Embedded SRAM (0x2000 0000)

When BOOT0=0, the ROM bootloader is completely bypassed. USART1 (PA9/PA10) — the pins your serial ISP tool expects — never gets initialized. The chip boots directly from whatever is in Flash.

If Flash contains corrupted data — bad stack pointer at 0x08000000, invalid reset vector, garbled option bytes that lock SWD — you’re in a Catch-22:

// The boot sequence that traps you:
// 1. Power-on reset occurs
// 2. BOOT0 sampled: 0 → route to Flash
// 3. Core fetches SP from 0x08000000: garbage
// 4. Core fetches PC from 0x08000004: garbage
// 5. Core executes undefined instructions → undefined state
// 6. SWD/JTAG handshake fails (core is incoherent)
// 7. Serial ISP never activates (bootloader was bypassed in step 2)
//
// Result: two independent interfaces, both dead.
// The chip isn't bricked. It can't hear you because
// it never reached a state where anything is listening.

This is the STM32 equivalent of a catch-22: corrupted Flash prevents the debugger from attaching, but you need the debugger to fix the Flash.

The Recovery: One Jumper Wire

The fix requires no soldering, no external programmer, no expensive tools. Just one Dupont wire:

Step 1: Force ISP Mode

Connect BOOT0 to 3.3V with a jumper wire. Ground BOOT1. Press RESET.

At the rising edge of nRST, the MCU samples BOOT0=1, BOOT1=0. This selects System Memory — the factory-programmed ROM bootloader. This bootloader is hardwired silicon — it doesn’t depend on Flash content. It lives in a dedicated ROM region that ST burned at the factory and cannot be corrupted.

// The recovery sequence:
// 1. BOOT0 jumpered to 3.3V
// 2. BOOT1 jumpered to GND
// 3. Press RESET button (NRST low→high)
// 4. At reset edge: BOOT0=1, BOOT1=0 → System Memory
// 5. ROM bootloader activates
// 6. USART1 initialized, waiting for Flash Loader protocol
// 7. FlyMCU now sees the chip

Step 2: Flash via FlyMCU

Open FlyMCU. Select the correct COM port (check Device Manager if unsure). Baud rate 115200 — the reliable default. Load your HEX file. Click “Start Programming.”

The ROM bootloader receives the firmware over UART and writes it to Flash. This works because the bootloader has direct access to the Flash controller — it doesn’t need the Flash to be coherent first.

Step 3: Restore Normal Boot

Remove the BOOT0→3.3V jumper. Remove the BOOT1→GND jumper. Press RESET.

BOOT0 returns to GND via the onboard pulldown resistor. The chip boots from Flash — executing the freshly-written firmware. If your firmware blinks an LED, the LED blinks. Board is functional.

The Bonus: J-Link Comes Back to Life

This is the non-obvious part. J-Link was failing before the ISP recovery — and it works after. Why?

Before ISP: Flash contains garbage. The core fetches a nonsense stack pointer, a nonsense program counter, and executes undefined instructions. The SWD/JTAG debug logic needs a coherent core to negotiate the attach sequence. If the core is executing garbage or stuck in a fault loop, the handshake times out.

After ISP: Flash contains a valid firmware image. Proper stack pointer at 0x08000000. Valid reset vector. Coherent code. The core enters a well-defined state after reset, and the debug probe can attach normally.

The ISP recovery didn’t fix J-Link — it fixed the software state that was preventing J-Link from connecting. The debug interface was always electrically fine. The core just wasn’t in a state where it could respond.

This is why ISP is the “master key” for STM32 recovery: it breaks the Catch-22 by sidestepping Flash entirely.

Practical Takeaways

▸ Measure BOOT0 first. Before assuming a chip is bricked, put a multimeter on BOOT0 at reset. If it reads 0V, serial ISP will never work — the bootloader was never activated, regardless of what your flashing tool reports.

▸ ISP recovery is the lowest-dependency path. It only needs BOOT0=1, BOOT1=0, and a working UART. No external programmer. No special tools. No Segger license.

▸ J-Link failure ≠ dead chip. The debug probe handshake can fail for software reasons. A corrupted Flash state is invisible to your multimeter but fatal to SWD. Clean firmware via ISP restores coherent state.

▸ Keep jumper wires in your kit. Two Dupont wires (BOOT0→3.3V, BOOT1→GND) are the cheapest STM32 recovery tool you can own. They take zero space and cost nothing. When you need them, they’re worth more than a Segger J-Link.

▸ The ROM bootloader is your insurance policy. ST burned it at the factory. It can’t be erased. It can’t be corrupted. It’s always there, waiting for BOOT0=1 and a valid Flash Loader command. Know how to reach it.

Bottom Line

The STM32 boot pin configuration is the first thing that determines whether your chip can hear you. When BOOT0 sits at GND — as it does on most development boards — you’re locked into Flash boot. If Flash is corrupt, you lose both serial ISP and debug access simultaneously.

The fix is mechanically trivial (one jumper wire, one reset button press) but conceptually counterintuitive: you’re not fixing the debug interface. You’re bypassing Flash entirely and using a hardwired ROM path that predates your firmware.

Once you understand that the ROM bootloader is electrically independent of Flash health, the recovery sequence becomes obvious. The jumper wire isn’t a hack — it’s the documented escape hatch that ST designed into every chip.

Stm32 Boot0 Isp Recovery A4

1.27MB ∙ PDF file

Download

Download

David Zhu writes about firmware, embedded systems, and the hardware-software boundary at gdbplus.substack.com. If this saved you an hour of debugging, there’s more where it came from.

#STM32 #Embedded #Firmware #Debugging #Microcontroller

The System Management Bus is easy to overlook. Two wires. Seven-bit addresses. A handful of registers. How complicated can it be?

Very, as it turns out. Because SMBus is not one thing — it’s three things, depending on where you stand.

If you’re a hardware engineer, it’s a physical bus with voltage levels, pull-up resistors, and timing margins. If you’re a firmware engineer, it’s the thing you read SPD from before the memory controller initialises. If you’re a kernel engineer, it’s an i2c-i801 driver and a sysfs node.

Same two wires. Three completely different mental models.

Hardware: The Physics of Two Wires

At the physical level, SMBus is deceptively simple. SMBCLK and SMBDAT, both open-drain, both pulled up to VDDIO — usually 1.8V or 3.3V depending on the platform generation. Standard speed is 100kHz. Fast mode pushes 400kHz. Devices are addressed with 7 bits.

But the simplicity hides teeth. SMBus is not I²C. Here’s what trips people up:

▸ Timeout: SMBus mandates a 25-35ms clock-low timeout. I²C devices can stretch the clock indefinitely. Drop an I²C temperature sensor on an SMBus segment, and it may hold SCL low past the timeout — the SMBus controller declares a failure and the transaction dies mid-byte.

▸ Voltage domains: DDR4 DIMMs typically use 3.3V VDDSPD. But DDR5 moves to 1.8V I3C on the same pins for SPD — it’s not SMBus at all anymore. Plug a DDR5 DIMM into a board expecting to read SPD via SMBus and you get silence on the bus.

▸ Pull-up strength: SMBus high-power mode (SMBus 3.1) requires stronger pull-ups to achieve 400kHz on a loaded bus. The I²C spec assumes a lightly loaded bus. A server with 16 DIMMs per channel has significant bus capacitance — weak pull-ups produce rounded edges that violate timing.

▸ Sideband signals: SMBALERT# lets slaves interrupt the host. The host must issue an Alert Response Address (ARA) read to discover which slave fired. If your firmware ignores SMBALERT# — which many platform bring-ups do — temperature sensors can assert it forever, and the bus stays in an interrupt storm.

The takeaway: if you’re a firmware or kernel engineer, you can’t treat SMBus as “just I²C with a different name.” The physics matter when things break.

Firmware: The Critical Path Through PEI

In UEFI firmware, SMBus matters most in a phase where almost nothing else works: PEI, before main memory is available.

Here’s the boot flow that catches every new platform team at least once:

1. CPU comes out of reset. Cache-As-RAM (CAR) is set up. The PEI core starts.

2. The memory reference code (MRC) needs to know: what DIMMs are installed? How many ranks? What timings?

3. The answer is in the SPD EEPROM on each DIMM — accessible only via SMBus.

4. But the SMBus controller itself requires PCI enumeration to find its I/O base.

5. And PCI enumeration requires... at least some memory to be configured.

This circular dependency is resolved by platform-specific PEI modules (PchSmbusPei on Intel, equivalent on AMD) that hardcode the SMBus controller’s PCI BDF (Bus 0, Device 1Fh, Function 4h) and read the I/O base directly from PCI config space offset 20h. No full enumeration — just one targeted config read, then I/O-space SMBus transactions.

▸ The data path: SmbusPpi->Execute(0x50, ReadByte, offset, &data) — repeated 256 times for a full SPD dump. Each call hits the SMBus Host Controller registers: write slave address to HST_ADD, write command to HST_CMD, set START in HST_CNT, poll BUSY in HST_STS, read HST_DAT0.

▸ In DXE, the SmbusDxe driver publishes EFI_SMBUS_HC_PROTOCOL, wrapping the same I/O port access behind a protocol interface. DXE drivers and applications use SmbusLib for convenience.

▸ The protocol itself: Execute() for transactions, ArpDevice() for address discovery, GetArpMap() for the ARP table, Notify() for SMBALERT# callbacks. Most platforms only use Execute().

Linux Kernel: The Bus Re-emerges

Once Linux boots, SMBus reappears through a completely different code path.

The i2c-i801 driver (for Intel) or i2c-piix4 driver (for AMD) probes the PCI device, maps the same I/O ports the firmware used, and registers an i2c_adapter. Then:

▸ i2c-core-smbus wraps the raw I²C transactions in SMBus protocol semantics: i2c_smbus_read_byte_data(), i2c_smbus_read_word_data(), i2c_smbus_read_block_data(). These functions handle PEC (Packet Error Checking) and the 32-byte block limit.

▸ sysfs exposes devices at /sys/bus/i2c/devices/i2c-0/. Each probed slave appears as a subdirectory with its own attributes. The at24 EEPROM driver creates an eeprom file — cat /sys/bus/i2c/devices/0-0050/eeprom dumps raw SPD bytes.

▸ i2c-tools gives userspace command-line access: i2cdetect -y 0 scans the bus, i2cget -y 0 0x50 0x02 b reads SPD byte 2 (memory type), i2cdump dumps the full device register space.

▸ decode-dimms (from i2c-tools) parses the raw SPD into human-readable timing tables — the CLI equivalent of what MRC does in silicon initialization.

The Connection No One Talks About

Here’s what makes SMBus uniquely interesting as an engineering topic: firmware and the kernel touch the same physical hardware on the same bus, but they are completely disconnected from each other.

EDK2 reads SPD in PEI → trains the memory controller → boots the OS → hands off control. Linux probes i2c-i801 → finds the same SMBus controller → discovers the same SPD EEPROM at 0x50 → reads it fresh.

There is no handoff. No ACPI table that passes SPD data from firmware to kernel. The kernel probes the bus from scratch. This means:

▸ If firmware configured something incorrectly (wrong VDDIO, wrong bus speed), the kernel inherits that broken configuration.

▸ If a device was put into an unexpected state by firmware, the kernel may not be able to recover it.

▸ If the ACPI DSDT declares the SMBus controller’s resources incorrectly (overlapping I/O ranges, wrong interrupt routing), the kernel driver will fail to probe — even though the firmware just used the same controller successfully.

Pitfalls I’ve Hit (So You Don’t Have To)

▸ SPD reads return all 0xFF on a new platform. The VDDIO rail for SMBus wasn’t enabled in the power sequencing. The EEPROM was unpowered. The bus looked idle (both lines high from pull-ups), so the controller read back 0xFF for every byte. Took two days to trace.

▸ i2c-i801 probe failure with “I/O resource conflict.” The ACPI DSDT declared the SMBus I/O range as a MotherboardResource, but the kernel’s resource management treated it as already-in-use. The fix: either fix the _CRS method in the DSDT, or use the acpi_enforce_resources=lax kernel parameter as a temporary workaround.

▸ SMBALERT# storm after a suspend/resume cycle. The firmware put the temperature sensor into a low-power mode during S3, but didn’t clear the SMBALERT# condition. On resume, the sensor immediately re-asserted the interrupt. The kernel’s i2c-i801 driver saw SMBALERT# stuck low and polled ARA in a tight loop — consuming 100% of one CPU core until the offending sensor was power-cycled.

▸ I²C slave on an SMBus segment caused intermittent bus hangs. A third-party I²C GPIO expander held SCL low for 40ms during a multi-byte write — 5ms past the SMBus timeout. The SMBus controller declared a timeout and reset the bus, corrupting the in-flight SPD read from the DIMM. The symptom: memory training would sometimes fail on cold boot, but always work on warm boot.

Bottom Line

SMBus is a great topic for engineers who want to understand how the stack actually works — not just their layer, but the layers above and below.

Hardware engineers who understand what MRC does with SPD data design better power sequencing. Firmware engineers who understand SMBus timing write PEI modules that don’t hang. Kernel engineers who understand the firmware boot path debug i2c-i801 probe failures faster.

Same two wires. Three worlds. Knowing all three makes you better at any one.

David Zhu writes about firmware, platform architecture, and the hardware-firmware boundary at gdbplus.substack.com.

Most developers interact with hardware through kernel drivers. The kernel abstracts away physical addresses behind files, sysfs nodes, and ioctl() interfaces. But there’s a direct path: /dev/mem — the physical memory device — combined with mmap(), lets userspace map arbitrary physical addresses and read or write them as if they were regular memory.

This article explores how that mechanism works, with a real-world example: accessing ACPI MMIO regions (specifically, the PCIe ECAM space) from a userspace tool.

1. What Is /dev/mem?

/dev/mem is a character device (major 1, minor 1) implemented in drivers/char/mem.c. It represents the system’s entire physical address space as a seekable file. Every byte in physical memory — RAM, MMIO ranges, flash, PCI configuration space — is addressable via read()/write() at the corresponding file offset.

// Reading byte at physical address 0xFED00000
fd = open("/dev/mem", O_RDONLY);
lseek(fd, 0xFED00000, SEEK_SET);
read(fd, &value, 4);

But read() and write() are slow for repeated access — each call is a syscall, and the kernel copies data into a temporary buffer. That’s where mmap() changes everything.

2. mmap: Mapping Physical Memory to Userspace

mmap() creates a direct virtual-to-physical mapping in the process’s page tables. After the mmap() call succeeds, every load or store instruction at the mapped address hits the physical device directly — no kernel mediation, no syscall overhead.

fd = open("/dev/mem", O_RDWR | O_SYNC);
void *ptr = mmap(NULL, 0x1000, PROT_READ | PROT_WRITE,
                 MAP_SHARED, fd, 0xFED00000);

// Now userspace can read/write directly:
uint32_t reg = *(volatile uint32_t *)ptr;

How the Kernel Implements It

When mmap() is called on a /dev/mem fd, the kernel’s VFS layer dispatches to the mmap_mem() function in drivers/char/mem.c:

1. Validation: valid_phys_addr_range(offset, size) checks whether the requested physical address is in an allowed range. On systems with CONFIG_STRICT_DEVMEM=y, this restricts access to ranges explicitly listed in the kernel’s iomem_resource tree.

2. Page table setup: remap_pfn_range() creates PTE entries mapping the userspace virtual address to the physical page frame number. The pgprot_uncached attribute ensures MMIO reads bypass the CPU cache — critical for hardware registers.

3. Fault handling: On first access, the CPU’s MMU walks the page tables and finds a valid mapping. From then on, the page is present and no page fault occurs.

The result: a userspace pointer that behaves like a direct window into physical memory.

3. Kernel Guards: STRICT_DEVMEM and Lockdown

Not every physical address is fair game. Linux has several guardrails:

▸ CONFIG_STRICT_DEVMEM — When enabled (default on most distros), /dev/mem rejects reads to arbitrary RAM but allows access to I/O memory (MMIO) ranges listed in /proc/iomem. The function devmem_is_allowed() in arch/x86/mm/init.c governs this on x86.

▸ CONFIG_IO_STRICT_DEVMEM — A stricter variant that also blocks MMIO access. Rarely enabled by default.

▸ Kernel Lockdown — When Secure Boot is active or the kernel is in lockdown mode, /dev/mem is completely disabled. The kernel refuses to open the device, returning -EPERM.

▸ Page alignment: The offset passed to mmap() must be page-aligned. You can still access unaligned addresses by adding an intra-page offset to the returned pointer.

On modern Ubuntu and Fedora, you’ll typically need to either disable Secure Boot, boot with iomem=relaxed, or add nokaslr to the kernel command line to use /dev/mem freely.

4. ACPI MMIO Access: A Concrete Example

Let’s walk through a real use case: reading PCIe device configuration space via the MCFG (Memory-mapped Configuration) table, without using the Linux PCI subsystem.

Step 1: Find the RSDP

The Root System Description Pointer (RSDP) is the entry point for all ACPI tables. It’s located at one of three places:

▸ EBDA (Extended BIOS Data Area): The segment stored at 0x40E in low memory
▸ 0xE0000–0xFFFFF: The BIOS ROM area
▸ UEFI system table: On UEFI systems, available via /sys/firmware/efi/systab

// Find RSDP on legacy BIOS
uint16_t ebda_seg = *(uint16_t *)(0x40E);
uint8_t *ebda = (uint8_t *)(ebda_seg << 4);
// Search for "RSD PTR " signature in EBDA and 0xE0000–0xFFFFF

Step 2: Walk RSDP → XSDT → MCFG

The RSDP contains a pointer to the XSDT (Extended System Description Table). The XSDT is an array of 64-bit pointers to other ACPI tables. Iterate through the entries and find the one with signature “MCFG”:

XSDT *xsdt = (XSDT *)(uintptr_t)rsdp->XsdtAddress;
int entries = (xsdt->Header.Length - sizeof(ACPI_TABLE_HEADER)) / 8;
for (int i = 0; i < entries; i++) {
    ACPI_TABLE_HEADER *hdr = (ACPI_TABLE_HEADER *)(uintptr_t)xsdt->Entry[i];
    if (memcmp(hdr->Signature, "MCFG", 4) == 0) {
        // Found MCFG
    }
}

Step 3: Extract the ECAM Base Address

The MCFG table contains one or more allocation entries, each describing a PCI segment group:

typedef struct {
    uint64_t BaseAddress;
    uint16_t SegmentGroup;
    uint8_t  StartBus;
    uint8_t  EndBus;
    uint32_t Reserved;
} MCFG_ENTRY;

uint64_t ecam_base = mcfg_entry->BaseAddress;  // e.g., 0xE0000000

The ECAM (Enhanced Configuration Access Mechanism) maps the 4KB PCI config space of each device function to a flat MMIO range. The mapping formula is:

ECAM offset = (Bus << 20) | (Device << 15) | (Function << 12) + Register

Step 4: Map the ECAM Region via /dev/mem

Now that we know the physical base address, we map it:

int fd = open("/dev/mem", O_RDONLY | O_SYNC);
size_t ecam_size = (mcfg_entry->EndBus - mcfg_entry->StartBus + 1) * 32 * 8 * 4096;
void *ecam = mmap(NULL, ecam_size, PROT_READ, MAP_SHARED, fd, ecam_base);

Step 5: Read PCI Config Registers

With the mapping in place, we can enumerate every device on the bus:

void read_pci_config(void *ecam, int bus, int dev, int func, int offset) {
    size_t ecam_off = ((size_t)bus << 20) | ((size_t)dev << 15) |
                      ((size_t)func << 12) | offset;
    volatile uint32_t *reg = (uint32_t *)((uint8_t *)ecam + ecam_off);
    uint32_t value = *reg;
    // Check if device exists: Vendor ID != 0xFFFF
    if ((value & 0xFFFF) != 0xFFFF) {
        printf("Bus %02x Dev %02x Func %x: VID=0x%04x DID=0x%04x\n",
               bus, dev, func, value & 0xFFFF, value >> 16);
    }
}

This is precisely what tools like pciutils (lspci) and UEFI firmware do internally — the difference is that we’re doing it from userspace with zero kernel assistance per access.

5. When to Use This (And When Not To)

▸ Use /dev/mem + mmap when:

• You’re performing bare-metal debugging (memory dumps, register inspection)

• You need to access hardware registers that have no kernel driver

• You’re writing a diagnostic tool that reads firmware tables (ACPI, SMBIOS)

• You need the speed: one mmap(), unlimited zero-copy reads

▸ Don’t use /dev/mem when:

• A kernel driver already provides the interface (use sysfs/iio instead)

• The platform has Secure Boot / Lockdown enabled

• You need portability (it’s x86/ARM-specific and requires root)

• The target is production code — this is a debugging and development technique

6. Beyond ECAM: Other ACPI MMIO Targets

The same technique applies to any MMIO region described in ACPI tables:

▸ FADT → PM1a registers: Power management event/control registers at the physical address in FADT.Pm1aEventBlock and FADT.Pm1aControlBlock

▸ FADT → GPE0 registers: General Purpose Event registers for wake and SCI routing

▸ MADT → LAPIC address: Local APIC base for reading APIC IDs and flags

▸ DMAR → IOMMU registers: DMA remapping hardware registers for VT-d inspection

▸ DBG2 → Debug port: Serial debug port MMIO for early boot console output

All of these follow the same pattern: find the table, extract the physical address, open /dev/mem, mmap, and access.

7. Performance: Why mmap Wins

MethodOverhead per AccessSuitable Forread() on /dev/mem1 syscall + kernel copyOccasional register readsmmap() on /dev/mem0 (direct VA→PA in TLB)Repeated register polling, scanpread() on sysfs file1 syscall + driver callback + copyOne-time attribute readsKernel driver + ioctl()1 syscall + context switchProduction device I/O

For any workload that needs more than a handful of register accesses, mmap is orders of magnitude faster. The cost is paid once at mapping time; every subsequent access is a single load/store instruction.

Summary

/dev/mem is the Linux kernel’s most direct interface to physical hardware. Combined with mmap(), it gives userspace unfiltered access to any physical address — including ACPI MMIO regions — with the performance of a direct virtual-to-physical mapping.

The ACPI MMIO example demonstrates the full workflow: locate the RSDP, walk the table chain, extract an ECAM base address from the MCFG, map it via /dev/mem, and read PCI configuration registers from userspace with zero per-access overhead.

It’s a powerful technique for firmware debugging, hardware diagnostics, and low-level system inspection — provided you navigate the kernel’s security guardrails.

Deep-dive content like this, every week. Follow on LinkedIn and subscribe at gdbplus.substack.com.

If you’ve ever debugged a firmware hang by watching serial output, you’ve trusted the 16550 UART to deliver every byte. But here’s the uncomfortable truth: at 115200 bps, that 16-byte RX FIFO fills in 1.4 milliseconds. If your ISR doesn’t drain it in time — and in a BIOS environment, SMI handlers, PCI enumeration storms, and DXE dispatcher overhead all compete for CPU — the bytes are silently gone.

RTS/CTS hardware flow control is the fix. Let’s walk through what the 16550 actually does when FCR[6] and FCR[7] are set

.

1. The Problem: Why BIOS Serial is Fragile

The 16550 is the workhorse UART in PC platforms. The Super I/O (or eSPI-attached EC) exposes it. EDK2’s SerialPortLib talks to it. And it has a 16-byte FIFO.

At 115200 bps, with 8N1 framing:

▸ 1 byte on the wire: (1 start + 8 data + 1 stop) / 115200 = 86.8 μs

▸ 16-byte FIFO fills in: 16 × 86.8 μs = 1.39 ms

▸ Your ISR deadline: drain the FIFO in under 1.39 ms, every time, forever

In a real BIOS boot path, 1.39 ms is nothing. An SMI can hold the CPU for hundreds of microseconds. PEI memory initialization can block for milliseconds. A single PCI config space read that triggers an SERR# can stall long enough to overflow the FIFO.

The result? Silent data loss. The UART’s Line Status Register won’t flag an overrun until it’s already happening — and by then you’ve lost bytes you can’t recover. Your debug log has gaps. Your console redirection drops characters. And you spend hours chasing a bug that doesn’t exist in the code.

2. Out-of-Band Signaling: RTS and CTS

Hardware flow control uses two dedicated signal lines that operate independently of the TXD/RXD data path:

▸ RTS (Request to Send) — UART output. When the 16550 asserts RTS (drives it low), it’s telling the remote peer: “I’m ready, send data.” When RTS goes high, it means: “Stop now.”

▸ CTS (Clear to Send) — UART input. The 16550 monitors this pin. When the remote peer de-asserts CTS, the 16550 stops transmitting — no firmware action needed.

This is out-of-band signaling. The RTS/CTS state changes consume zero bits of the data stream. Unlike XON/XOFF (which embeds 0x11/0x13 in the data), RTS/CTS works identically whether you’re sending ASCII debug text or raw binary firmware capsule updates.

3. The Registers That Matter

In a BIOS codebase (EDK2 or coreboot), you touch these registers:

▸ FCR (FIFO Control Register, offset 2, DLAB=0 required)

• Bit 0: FIFO Enable (must be 1 for auto flow control)

• Bit 6: Auto-RTS Enable — hardware manages RTS autonomously

• Bit 7: Auto-CTS Enable — hardware responds to CTS autonomously

• Bits 7:6 (Write-only FCR): RX FIFO trigger level (00=1, 01=4, 10=8, 11=14 bytes)

▸ MCR (Modem Control Register, offset 4)

• Bit 1: RTS manual control — only relevant when Auto-RTS is off

▸ MSR (Modem Status Register, offset 6)

• Bit 4: CTS pin state (read-only)

▸ IER (Interrupt Enable Register, offset 1, DLAB=0)

• Bit 3: EDSSI — Modem Status Interrupt, fires on CTS/DSR/DCD/RI changes

Real EDK2-style initialization:

//
// Configure 16550: enable FIFO + Auto-RTS + Auto-CTS
// Trigger level: 14 bytes (FCR[7:6] = 11)
//
UINT8 FcrValue = (UINT8)((0x3 << 6) |   // Trigger at 14 bytes
                          (0x1 << 3)  |   // DMA Mode Select
                          (0x1 << 0));     // FIFO Enable
IoWrite8 (gSerialIoBase + FCR_OFFSET, FcrValue);

//
// Read back IIR (offset 2, same address as FCR but read-only)
// to verify FIFOs are enabled (IIR[7:6] = 11 for 16550)
//
UINT8 IirValue = IoRead8 (gSerialIoBase + IIR_OFFSET);
if ((IirValue & 0xC0) == 0xC0) {
  DEBUG ((EFI_D_INFO, "16550 FIFO + Auto Flow Control active\n"));
}

4. Auto-RTS: The Hardware Automaton

When FCR[6] = 1, the 16550 contains a comparator that tracks the RX FIFO fill level against the trigger threshold. The sequence is:

1. RX FIFO crosses the trigger level → hardware de-asserts RTS (drives it high) on the next bit boundary

2. Remote peer detects RTS change → stops transmitting after the current byte completes

3. Your ISR fires, reads the FIFO, FIFO drops below trigger

4. Hardware re-asserts RTS (drives it low) → remote peer resumes

This entire loop runs in hardware. The critical path from “FIFO hits trigger” to “RTS changes” is measured in nanoseconds — it’s comparator → output pin, no firmware in the loop.

Trigger level trade-off for BIOS use:

▸ 1 byte (FCR[7:6]=00): ISR fires for every byte. Lowest latency, highest CPU overhead. Almost never used in BIOS.

▸ 4 bytes (FCR[7:6]=01): Conservative. Many BIOS defaults. Leaves 12 bytes of headroom.

▸ 8 bytes (FCR[7:6]=10): Balanced. About 700 μs between interrupts at 115200 bps.

▸ 14 bytes (FCR[7:6]=11): Fewest interrupts. But only 2 bytes of slack (16 - 14 = 2). At 115200, that’s 174 μs for the remote peer to react to RTS — tight but workable for modern UARTs.

BIOS-specific note: During SMM entry, the CPU saves state and the SMI handler runs in SMRAM. If the SMI handler takes 300 μs, a 14-byte trigger level means you have only ~174 μs of slack after RTS de-asserts. If the remote peer’s RTS detection latency exceeds that window, bytes 15 and 16 can still be lost even with Auto-RTS enabled. For SMI-heavy firmware, consider a 8-byte trigger level for more margin.

5. Auto-CTS: Transparent TX Gating

When FCR[7] = 1, the 16550’s TX state machine is gated by the CTS input:

▸ Remote peer de-asserts CTS → 16550 pauses TX mid-byte if necessary

▸ CTS re-asserted → TX resumes from the exact stopping point

▸ The THR (Transmit Holding Register) maintains its contents

The firmware writes to THR as usual. The hardware handles the rest. Your SerialPortWrite() function in SerialPortLib doesn’t need to check CTS — the chip does it.

Common BIOS bug: I’ve seen platforms where Auto-CTS is enabled but the CTS pin is unconnected (floating) on the board. The 16550 sees a random logic level and either blocks TX permanently or lets it through. The symptom: serial output works on some boards and is completely dead on others. The fix: a pulldown resistor on CTS, or disabling Auto-CTS if RTS/CTS handshake isn’t physically wired.

6. Manual Flow Control: When You Can’t Use Auto

If your platform’s 16550 variant doesn’t support Auto-RTS/CTS (some older clones don’t), you can implement flow control in firmware using MCR and MSR:

Polling approach (PEI phase, before interrupts):

while (BytesToSend > 0) {
  // Wait for THR empty
  while ((IoRead8 (Base + LSR_OFFSET) & B_THR_EMPTY) == 0);
  // Check CTS before writing
  if ((IoRead8 (Base + MSR_OFFSET) & B_CTS) != 0) {
    IoWrite8 (Base + THR_OFFSET, *Buffer++);
    BytesToSend--;
  }
  // If CTS is de-asserted, spin — peer isn't ready
}

Interrupt-driven (DXE phase):

// In SerialPortLib initialization:
// Enable Modem Status Interrupt (EDSSI)
IoWrite8 (Base + IER_OFFSET, (B_RX_AVAILABLE | B_THR_EMPTY |
                                B_RX_STATUS   | B_MODEM_STATUS));

// The ISR checks IIR to identify the interrupt source:
UINT8 IirValue = IoRead8 (Base + IIR_OFFSET);
if ((IirValue & IIR_MODEM_STATUS) != 0) {
  // CTS changed — re-evaluate TX readiness
  UINT8 MsrValue = IoRead8 (Base + MSR_OFFSET);
  if ((MsrValue & B_CTS) != 0) {
    // CTS is asserted, resume transmitting
    ResumeTransmit();
  }
}

The problem with manual flow control: latency. From CTS change to ISR execution, you’ve got interrupt controller latency + CPU interrupt gate delay + potential SMI preemption. In BIOS, this can easily exceed 100 μs. At 115200 bps, that’s a full byte missed.

Auto flow control (FCR[6]=1, FCR[7]=1) eliminates this entirely. The hardware reacts in nanoseconds.

7. Hardware Flow Control vs. XON/XOFF

If you’re debugging a BIOS, you’re sending binary data: firmware capsule updates, memory dumps, PCI config space hex dumps, compressed debug payloads. That makes the choice clear.

▸ Signal path: RTS/CTS uses dedicated physical wires, completely outside the data stream. XON/XOFF injects 0x11 (XON) and 0x13 (XOFF) directly into the byte stream.

▸ Binary compatibility: RTS/CTS works with any data — hex dumps, raw flash images, compressed logs. XON/XOFF breaks catastrophically when 0x11 or 0x13 appears in the payload.

▸ Response latency: RTS/CTS is hardware-level (nanoseconds). XON/XOFF requires the receiving UART to recognize the byte, generate an interrupt, and have the ISR process it — easily 50–100 μs in BIOS.

▸ Hardware requirement: RTS/CTS needs five wires (TXD, RXD, RTS, CTS, GND). XON/XOFF needs only three (TXD, RXD, GND).

▸ Real BIOS scenario: You’re capturing a full PCI config space dump over serial at 921600 bps. The hex dump contains bytes 0x00–0xFF uniformly. XON/XOFF will randomly pause and resume your stream based on data content. RTS/CTS won’t.

Bottom line for BIOS engineers: If you’re doing any serial communication that involves binary data — and most BIOS debugging does — hardware flow control is not optional. It’s the only reliable option.

8. Common Pitfalls in BIOS Environments

▸ DLAB gate: FCR lives at I/O offset 2, but only when LCR[7] (DLAB) = 0. If you write FCR while DLAB is set, you’re writing to the divisor latch instead. Your “flow control enable” silently becomes a garbage baud rate divisor.

▸ FIFO must be enabled first: Auto-RTS and Auto-CTS are features of the FIFO mode. If FCR[0] = 0 (16450 compatibility mode, no FIFO), FCR[6] and FCR[7] are ignored. This catches platforms that set FCR in two separate writes — a “FIFO enable” write followed by a “flow control” write — where an intermediate read flushes the write-only FCR state.

▸ SMI latency breaks Auto-RTS: 14-byte trigger at 115200 bps leaves only 174 μs of slack. If SMI handlers consume 200+ μs, the remote peer may not have time to react to RTS de-assertion before bytes overflow. Test with worst-case SMI duration, not average.

▸ Floating CTS pin: Auto-CTS (FCR[7]=1) with unconnected CTS pin → random TX behavior across boots and boards. Always verify CTS is either physically connected or pulled to an active-low (asserted) state with a resistor.

▸ Super I/O configuration dependency: The 16550 inside a Super I/O (like NCT6796D or IT8625E) may default to RTS/CTS pins disabled. You must configure the Super I/O’s Logical Device registers (usually via LPC/eSPI at 0x2E/0x4E) to enable the UART’s RTS/CTS pins before the 16550 registers have any effect.

▸ EDK2 SerialPortLib: Most SerialPortLib implementations don’t configure flow control — they just set baud rate and enable the FIFO. If your platform needs hardware flow control, you’ll need to customize SerialPortInitialize() to write FCR with the Auto-RTS/CTS bits set.

Summary

Two bits. FCR[6] and FCR[7]. That’s all it takes to transform your serial port from a best-effort debug channel into a reliable transport. The hardware automaton inside the 16550 handles the rest — no ISR latency to worry about, no polling loops, no silent data loss.

For BIOS engineers shipping platform firmware, hardware flow control isn’t a nice-to-have. It’s the difference between debug logs you can trust and debug logs that lie to you.

This article is part of the GDBplus firmware internals series. Full annotated source code walkthroughs: gdbplus.substack.com

#UEFI #BIOS #Firmware #16550 #EDK2 #Embedded

When you enter BIOS Setup and see those configuration menus — the gray-and-blue screens with dropdowns, checkboxes, and numeric inputs — you’re looking at the output of a remarkably elegant pipeline. That pipeline starts with a single .vfr file.

VFR stands for Visual Form Representation. It’s a declarative language in the UEFI specification that describes what a setup page looks like, not how to render it. Think of it as HTML for firmware configuration screens — you declare the form structure, and the UEFI HII (Human Interface Infrastructure) handles all the rendering.

But a .vfr file doesn’t work alone. It’s part of a carefully orchestrated build-time + runtime pipeline involving at least 5 other file types. Here’s how they all fit together

.

The File Cast — Who Does What

▸ Vfr.vfr — The form definition. Declares the visual layout: questions, oneof dropdowns, numeric inputs, checkboxes, ordered lists, and conditional display rules (SuppressIf, GrayOutIf). Written in VFR language — a C-like DSL specified in the UEFI spec.

▸ Strings.uni — Unicode string tokens. Every piece of text visible on the setup page (question prompts, option labels, help text) is stored here as a token. This enables multi-language support — swap the UNI file, and your BIOS speaks Chinese, Japanese, or German without touching the VFR.

▸ Vfr.h / Driver.h — Header with GUIDs and class definitions. VFR needs GUID references for protocols, variable GUIDs, and form set GUIDs. These are defined here so both the VFR and C code share the same constants.

▸ Driver.inf — EDK2 module description. Lists VFR and UNI files as sources so the build system knows to compile them. Defines which protocols the driver consumes and produces.

▸ Driver.c / HiiConfigAccess.c — The runtime driver. Registers forms with the HII Database, publishes EFI_HII_CONFIG_ACCESS_PROTOCOL, and implements the callback functions (ExtractConfig, RouteConfig, Callback) that process user input.

▸ Vfr.vfrbin — The compiled IFR (Internal Forms Representation) binary. This is what actually gets embedded in the firmware volume. It’s a compact, tokenized representation of your VFR + UNI. A full configuration page with 50 questions compiles to about 2KB.

Stage-by-Stage Pipeline

Stage 1 — Author: Write VFR + UNI

You start by writing two files.

The VFR file looks like a structured C header:

formset
  guid = FORMSET_GUID,
  title = STRING_TOKEN(STR_FORM_SET_TITLE),
  help  = STRING_TOKEN(STR_FORM_SET_HELP),

  form
    formid = FORM_ID_MAIN,
    title  = STRING_TOKEN(STR_MAIN_FORM_TITLE);

    oneof varid = MyDriver.EnableFeature,
      prompt = STRING_TOKEN(STR_ENABLE_PROMPT),
      help   = STRING_TOKEN(STR_ENABLE_HELP),
      option text = STRING_TOKEN(STR_DISABLE), value = 0, flags = DEFAULT;
      option text = STRING_TOKEN(STR_ENABLE),  value = 1, flags = 0;
    endoneof;

    numeric varid = MyDriver.BaudRate,
      prompt = STRING_TOKEN(STR_BAUD_PROMPT),
      help   = STRING_TOKEN(STR_BAUD_HELP),
      minimum = 9600, maximum = 115200, step = 0, default = 115200;
    endnumeric;
  endform;
endformset;

Every STRING_TOKEN(...) references the UNI file:

#langdef en-US "English"
#string STR_FORM_SET_TITLE   #language en-US "Serial Port Configuration"
#string STR_ENABLE_PROMPT    #language en-US "Enable Serial Console"
#string STR_ENABLE           #language en-US "Enabled"
#string STR_DISABLE          #language en-US "Disabled"

This separation is critical. The VFR describes structure; the UNI provides content. When Intel needs to ship the same BIOS Setup in 12 languages, they swap the UNI file — the VFR never changes.

Stage 2 — Compile: VfrCompiler → IFR Binary

At build time, VfrCompiler (a tool in EDK2’s BaseTools) takes VFR + UNI and produces:

• Vfr.vfrbin — IFR binary. Compact, token-optimized. Every form, question, option, and conditional is encoded in a byte stream that the HII parser reads at runtime.

• Vfr.h (auto-generated) — C definitions for form IDs, question IDs, and offset calculations, so your driver code can reference form elements by name.

Pitfall: VfrCompiler has notoriously cryptic error messages. A missing semicolon in a VFR file can produce “syntax error at line 1” with no further context. Always compile incrementally — add one form element at a time.

Pitfall: String token IDs are auto-generated from UNI ordering. If you insert a new string at the top of the UNI file, ALL subsequent token IDs shift. Your VFR will silently reference the wrong strings. Solution: use explicit #string TOKEN_NAME and never rely on implicit ordering.

Stage 3 — Package: Embed in Firmware Volume

The build system (GenFfs + GenFv) takes the IFR binary and string package and embeds them as FFS (Firmware File System) sections inside the driver’s FFS file.

Your Driver.inf declares the inputs:

[Sources]
  Driver.c
  Vfr.vfr
  Strings.uni

[Guids]
  gEfiIfrFrameworkGuid            # IFR binary section type
  gEfiStringPackageGuid           # String package section type

The result: a single FFS file containing your driver executable PLUS the IFR form definition PLUS the string package. The HII infrastructure can locate all three at runtime from one FFS file.

Stage 4 — Register: Driver Binds to HII Database

When the DXE dispatcher loads your driver, the driver’s entry point does three things:

1. Installs EFI_HII_DATABASE_PROTOCOL — registers form package (IFR binary) and string package with the database.

2. Installs EFI_HII_CONFIG_ACCESS_PROTOCOL — exposes callback functions the Form Browser calls when the user interacts with your form.

3. Returns EFI_HII_PACKAGE_LIST_PROTOCOL — so the HII infrastructure can discover your forms.

The critical data structure is the HII handle — a handle that groups together your form package, string package, and config access callback.

Status = gHiiDatabase->NewPackageList(
    gHiiDatabase, &PackageListHeader,
    NULL, &mHiiHandle);

At this point, your form exists in the HII database but is not yet visible. Like a web server that’s registered a route but hasn’t received a request yet.

Stage 5 — Parse: HII Infrastructure Reads IFR

When the user enters BIOS Setup (typically F2/Del during POST), the Form Browser (a DXE driver: SetupBrowserDxe or UiApp) activates.

The Form Browser calls EFI_HII_DATABASE_PROTOCOL.GetPackageList() to retrieve ALL registered form packages. It then parses each IFR binary bytecode — walking the opcode stream to build an internal representation:

• EFI_IFR_FORM_SET_OP → new form set begins

• EFI_IFR_ONE_OF_OP → dropdown question

• EFI_IFR_NUMERIC_OP → numeric input question

• EFI_IFR_SUPPRESS_IF_OP → conditional visibility

• EFI_IFR_GRAY_OUT_IF_OP → conditional disable

String tokens are resolved against the string package in real time.

Stage 6 — Render: Form Browser Paints the Page

This is where the magic happens — and where VFR’s declarative nature shines.

The Form Browser has a rendering engine that converts IFR opcodes into on-screen UI elements. You did not write a single line of pixel-drawing code. The Form Browser handles:

• Layout (vertical stacking of questions)

• Widget rendering (dropdown vs. text field vs. checkbox)

• Keyboard navigation (arrow keys, Enter, Escape)

• Default value highlighting

• SuppressIf / GrayOutIf evaluation

• Multi-page form handling

• Help text popup (F1)

This is why every UEFI BIOS Setup screen looks similar — they all use the same Form Browser engine. The VFR only describes content; the rendering is standardized.

Stage 7 — User Interacts: Config Routing Protocol

When the user changes a setting (toggles Enable Serial Console from “Disabled” to “Enabled”) and presses F10 to save, here’s what happens:

1. Form Browser collects all changed values into a configuration string (EFI_HII_CONFIG_ROUTING_PROTOCOL format).

2. Form Browser calls RouteConfig() on your driver’s EFI_HII_CONFIG_ACCESS_PROTOCOL.

3. The config string looks like: GUID=...&OFFSET=...&WIDTH=...&VALUE=...

4. Your RouteConfig() parses this string, validates the input, and applies it.

EFI_STATUS RouteConfig(
    IN CONST EFI_HII_CONFIG_ACCESS_PROTOCOL *This,
    IN CONST EFI_STRING Configuration,
    OUT EFI_STRING *Progress) {
  // Parse Configuration string
  // Validate values
  // Apply to hardware or EFI variable
}

Stage 8 — Callback: Dynamic Form Updates

Sometimes the form needs to respond to user input before F10 is pressed. Example: toggling “Enable Serial Console” from Disabled to Enabled should reveal additional questions (Baud Rate, Data Bits, Parity).

This is handled by the Callback() function:

EFI_STATUS Callback(
    IN CONST EFI_HII_CONFIG_ACCESS_PROTOCOL *This,
    IN EFI_BROWSER_ACTION Action,
    IN EFI_QUESTION_ID QuestionId,
    IN UINT8 Type,
    IN OUT EFI_IFR_TYPE_VALUE *Value,
    OUT EFI_BROWSER_ACTION_REQUEST *ActionRequest) {

  if (Action == EFI_BROWSER_ACTION_CHANGED &&
      QuestionId == QUESTION_ID_ENABLE_SERIAL) {
    // User toggled the checkbox. Tell Form Browser to refresh.
    *ActionRequest = EFI_BROWSER_ACTION_REQUEST_FORM_APPLY;
  }
}

The key action values:

• EFI_BROWSER_ACTION_CHANGED — user changed a value (triggers SuppressIf re-evaluation)

• EFI_BROWSER_ACTION_RETRIEVE — form is about to be displayed (load defaults)

• EFI_BROWSER_ACTION_FORM_OPEN — form is opening (initialize context)

• EFI_BROWSER_ACTION_SUBMITTED — user pressed F10 (final validation)

The Complete File Set

Every UEFI setup page requires these files, minimum:

▸ Vfr.vfr — Form layout declaration (VFR DSL)

▸ Strings.uni — Display text tokens (Unicode string tokens)

▸ Driver.c — Runtime driver logic (C)

▸ Driver.inf — Module build definition (EDK2 INF)

Plus these generated outputs:

▸ Vfr.vfrbin — VfrCompiler → FFS packaging (IFR binary)

▸ Vfr.h — VfrCompiler → Driver.c includes (C definitions)

▸ FFS file — GenFfs / GenFv → DXE Dispatcher (executable + IFR + strings)

▸ String package — Build system → HII String Protocol (runtime display text)

Why This Architecture Matters

The VFR → IFR → HII Browser pipeline is one of UEFI’s most underappreciated design decisions. Here’s why it’s elegant:

1. Separation of content and presentation. The VFR describes the form. The Form Browser owns the rendering. You never write UI code. This is cleaner than Linux kernel’s Kconfig (which mixes menu structure and build logic) or U-Boot’s cmdline approach (no structured forms at all).

2. Localization is free. Swap the UNI file, and your BIOS Setup speaks any language. No code changes. Intel ships the same EDK2 firmware image worldwide — only the UNI packages differ by region.

3. Declarative conditionals. SuppressIf and GrayOutIf are evaluated by the Form Browser at display time. You don’t need to track UI state. When the user toggles a checkbox, Callback() fires → ActionRequest → Form Browser re-evaluates all conditionals → layout updates automatically.

4. Config Routing decouples storage from UI. The form doesn’t care where values are stored — EFI variables, driver buffer, hardware registers. RouteConfig() is your translation layer. Change storage backend without touching the VFR.

5. IFR is compact. A full configuration page with 50 questions compiles to maybe 2KB of IFR binary. Compare this to a JSON or XML representation — the binary opcode format was designed for embedded systems where every byte counts.

Common Pitfalls

▸ VfrCompiler error: “syntax error” with no line number. Add --preprocess flag to see the preprocessed VFR output. The error is usually in a #include‘d header, not the VFR itself.

▸ String token mismatch. UNI file order changed, tokens shifted, wrong strings appear. Use #string TOKEN_NAME (explicit) and never rely on auto-generated token IDs.

▸ Callback not firing. Forgot to set EFI_IFR_FLAG_CALLBACK on the question in VFR. Without it, the Form Browser never calls your Callback() function.

▸ RouteConfig returning EFI_UNSUPPORTED. Your config string parser is rejecting the format. Check the OFFSET field — it must match exactly what ExtractConfig() returns.

▸ Form not appearing in Setup Browser. Driver didn’t register with HII Database, or the HII handle was lost. Ensure NewPackageList() succeeds and mHiiHandle is valid.

▸ SuppressIf never updates. You need to request EFI_BROWSER_ACTION_REQUEST_FORM_APPLY in your Callback() — otherwise the Form Browser doesn’t know to re-evaluate conditionals.

Bottom Line

VFR is a declarative form description language. You write what the form looks like in VFR, provide display strings in UNI, compile to IFR binary, embed in firmware, and the HII Form Browser does everything else at runtime.

Your driver’s job is only three things:

1. Register the form + string packages with HII Database

2. Implement ExtractConfig() / RouteConfig() for reading/writing values

3. Implement Callback() for dynamic form behavior

Everything else — layout, rendering, keyboard navigation, help text — is handled by the standard UEFI HII infrastructure. That’s the power of the VFR pipeline.

Full source code walkthrough of a real EDK2 VFR driver, with annotated VFR/UNI/C files: gdbplus.substack.com

#UEFI #EDK2 #Firmware #BIOS #EmbeddedSystems #HII

SPI NOR flash has been a boot firmware workhorse for decades. But for most of that history, every flash chip was a black box — you either had the datasheet hardcoded into your bootloader, or you were in trouble.

JEDEC fixed this with JESD216: the Serial Flash Discoverable Parameters (SFDP) standard. And the key that unlocks it all is a single command byte: 0x5A.

The Problem: Every Flash Chip Was a Snowflake

Before SFDP, firmware had to maintain a lookup table mapping JEDEC manufacturer IDs to flash capabilities. See ID 0xC2 (Macronix)? Great, now check the model byte. Model 0x20? That’s 3V, 256Mb, Quad I/O. Model 0x19? Different erase sizes, slower max frequency.

This broke in three ways:

• New chips broke old firmware — a new density variant with the same ID bytes needed a code update.

• Dead chips killed boot — if your lookup table was in flash and your flash died, you couldn’t discover a replacement.

• Every vendor had their own quirks — same density, same I/O, different erase granularity. Your table grew endlessly.

The industry needed the flash chip to declare its own capabilities — not rely on the host to already know them.

Enter SFDP: Flash Self-Description

JEDEC JESD216 defines the SFDP standard. Every compliant flash chip stores a structured parameter table in a dedicated internal ROM area. The host reads this table at boot using command 0x5A (Read SFDP, or RDSFDP).

The transaction is straightforward:

▸ CS# low — Assert chip select. The flash is now listening.

▸ 0x5A — Send the RDSFDP command byte on MOSI. This is the magic number.

▸ 24-bit Address — 3 bytes specifying the offset into the SFDP address space. The SFDP table lives in its own memory map, separate from the main flash array. Address 0x000000 reads the SFDP header.

▸ 1 Dummy Byte — One turnaround cycle. The flash switches its internal data path from MOSI (receiving) to MISO (transmitting). On the MX25L25635F, 0x5A always needs exactly 1 dummy cycle — this is declared in the SFDP table itself.

▸ Continuous Clock — Keep toggling SCK. The flash streams SFDP data bytes on MISO until you stop. Pull CS# high to end the transaction.

The SFDP Header: 8 Bytes That Unlock Everything

Reading offset 0x00 returns the 8-byte SFDP header:

From JESD216 Section 6.3:

▸ Signature (Bytes 0–3): 0x50444653. That’s “SFDP” in ASCII, stored little-endian (”S” = 0x53 is byte 0, “P” = 0x50 is byte 1...). If these 4 bytes don’t match, the flash doesn’t support SFDP — fall back to the old ID lookup.

▸ Minor Version (Byte 4): 0x06 on the MX25L25635F. This maps to JESD216B, which added support for 4-byte addressing and additional parameter tables.

▸ Major Version (Byte 5): 0x01. Combined with minor, this tells you which version of the JESD216 spec the table follows.

▸ NPH — Number of Parameter Headers (Byte 6): 0x01 on the MX25L25635F. This chip has one parameter table. High-end flash might have 2–3 (basic SPI + 4-byte addressing + sector map).

▸ Access Protocol (Byte 7): 0xFF. Reserved/unused for standard SPI flash.

The Parameter Header: Where to Go Next

Immediately after the SFDP header (offset 0x08), the parameter header tells you where the actual capability data lives:

From JESD216, each parameter header is 2 DWORDs (8 bytes):

▸ Parameter ID (Byte 0): 0xFF. This is the JEDEC-assigned ID for the “Basic SPI Flash Parameters” table — the one every SPI NOR flash must provide.

▸ Minor Revision (Byte 1): 0x00. Version of this specific parameter table.

▸ Table Length (Byte 2): Number of DWORDs in the table. For basic SPI, typically 16 DWORDs (0x10).

▸ Table Pointer (Bytes 4–6): 3-byte address where this parameter table starts in the SFDP space. On the MX25L25635F, this is 0x000030.

With the pointer in hand, you issue a second 0x5A command — this time with address 0x000030 — and read the 16-DWORD parameter table.

What the Parameter Table Reveals About MX25L25635F

The 16 DWORDs (64 bytes) of the basic SPI parameter table tell you everything:

▸ DWORD[1] — Flash Density: The first DWORD after the parameter header encodes the total memory size as a bit count. For 256 megabits, this field returns 0x1FFFFFFF or similar encoding, allowing the host to compute 2^N bytes. The MX25L25635F reports 256Mb = 32MB = 33,554,432 bytes.

▸ DWORD[2] — I/O Mode Support: Bits [3:0] declare the supported read commands. The MX25L25635F advertises four modes — 1-1-1 (standard SPI, 0x03), 1-1-2 (dual output, 0x3B), 1-1-4 (quad output, 0x6B), and 1-4-4 (quad I/O, 0xEB). This lets the bootloader auto-select the fastest read mode the flash supports.

▸ DWORD[2] — Maximum Frequency: Bit [30] indicates support for >100MHz. The MX25L25635F supports up to 133MHz in quad I/O read mode.

▸ DWORD[4] — Erase Types: Three erase instruction sizes are declared. Type 1 = 4KB subsector erase (0x20), Type 2 = 32KB half-block erase (0x52), Type 3 = 64KB block erase (0xD8). The flash advertises typical erase times for each type, so the host can set appropriate timeouts without guessing.

▸ DWORD[7] — Status Register Polling: Bit [3] declares whether the flash supports software write-in-progress polling via the status register. The MX25L25635F sets this bit, meaning the host can poll SR[0] instead of using fixed delays after each write/erase. This is critical for fast flash update performance.

▸ DWORD[9–10] — 4-Byte Addressing: Since 256Mb fits in a 24-bit address space (2^24 × 8 bits = 128Mb, but 256Mb = 2^28 bits, and with page/block organization, addressing is byte-based: 32MB = 2^25 bytes), the MX25L25635F uses 3-byte addressing natively. Bits in DWORD[9] confirm this — no 4-byte address mode is needed.

▸ DWORD[15] — Quad Enable Requirements: Declares whether QE (Quad Enable) sits in a non-volatile status register (requiring Write Status Register to toggle) or a volatile configuration register. The MX25L25635F uses SR[6] as the QE bit — non-volatile, so it survives power cycles but needs explicit clearing if you want to run in 1-1-1 mode.

Why This Matters in UEFI / EDK2 Firmware

In the EDK2 firmware stack, SPI NOR flash initialization typically happens inside a platform-specific PEIM (Pre-EFI Initialization Module) or early DXE driver. The conventional approach uses the JEDEC ID (command 0x9F) to look up flash parameters from a hardcoded table.

SFDP changes the flow:

▸ Read 0x9F (JEDEC ID) — Get manufacturer and model bytes. This still runs first, because 0x9F works on every SPI flash ever made. But now it’s just for logging and sanity checks.

▸ Read 0x5A (SFDP Header at offset 0x00) — Verify the “SFDP” signature (0x50444653). If it’s there, proceed with SFDP. If not, fall back to the legacy lookup.

▸ Read 0x5A (Parameter Table at pointer offset) — Parse the 16-DWORD basic SPI parameter table. Extract density, supported I/O modes, erase types, timing parameters, and status register layout.

▸ Auto-configure the SPI protocol — Based on DWORD[2], select the fastest supported read command (1-4-4 if available, 1-1-4 as minimum quad). Based on DWORD[4], configure the flash block driver with the correct erase opcodes and timeout values.

▸ Validate with 0x9F — Confirm the manufacturer ID matches and that the model is consistent with the SFDP declarations. Log any discrepancies.

This eliminates the fragile ID→capability lookup table entirely. New Macronix, Winbond, or GigaDevice chips drop in with no firmware change. The flash tells you what it can do.

SPI Bus Details: Why One Dummy Byte?

The dummy byte in the 0x5A transaction isn’t arbitrary — it’s the turnaround cycle where the SPI bus changes direction. On a standard SPI bus, the master controls MOSI (Master Out, Slave In) while the slave drives MISO (Master In, Slave Out).

When you send 0x5A + 3 address bytes, the flash is listening on MOSI. After the address, it needs time to:

1. Decode the SFDP offset address

2. Switch its internal data path from receiving to transmitting

3. Start clocking out the first SFDP data byte on MISO

The dummy byte buys this time. On slower SPI modes (single I/O), one cycle is enough. In quad I/O read mode (command 0xEB), some chips need 4–8 dummy cycles because the quad data path takes longer to set up.

The SFDP table itself tells you how many dummy cycles each command needs — DWORD[2] bits [7:5] specify the mode bits and dummy cycle count for the Read SFDP command specifically. This is self-referential: the parameter table declares how to read the parameter table.

Beyond Basic SPI: SFDP’s Extensible Design

JESD216 isn’t limited to basic SPI parameters. Additional parameter tables cover:

▸ 4-Byte Addressing (Parameter ID 0x84): For flash chips >256Mb that need 32-bit addresses. The table declares which commands support 4-byte addressing mode and how to toggle it.

▸ Sector Map (Parameter ID 0x81): For chips with uniform or hybrid sector layouts. Declares the erase granularity for each address region. Essential for flash file systems that need to know block boundaries.

▸ OTP / Security Registers (Parameter ID 0x8C): One-time programmable regions, serial numbers, and lock bits. The SFDP table declares their location, size, and access protocol.

The MX25L25635F exposes only the basic SPI parameter table (ID 0xFF), but higher-end Macronix chips add 4-byte addressing and sector map tables. The SFDP header’s NPH field tells you how many to expect — just iterate through them.

Real-World Adoption

SFDP is now mandatory for any flash chip targeting modern platforms:

▸ Intel PCH SPI programming guide recommends SFDP-based discovery for all attached SPI NOR flash since Skylake generation (2015+).

▸ Linux kernel’s spi-nor subsystem has been SFDP-first since kernel 4.x. The spi_nor_scan() function in drivers/mtd/spi-nor/core.c reads SFDP before falling back to the legacy ID table.

▸ U-Boot bootloader uses SFDP in its spi-flash framework. The spi_flash_scan() logic reads the SFDP header and parameter tables during the flash probe sequence.

▸ Coreboot calls SFDP “the right way” and strongly discourages new ID-table entries for chips that support SFDP correctly.

The Bottom Line

0x5A is a simple command — one byte, three address bytes, one dummy byte, infinite data out. But it represents a fundamental shift in how firmware interacts with hardware: from “I know what you are” to “tell me what you are.“

For the MX25L25635F, two 0x5A reads replace a 100-entry manufacturer ID lookup table. For the firmware engineer, it means never having to add “just one more flash chip” to the bootloader again.

The flash chip that describes itself is the flash chip that survives firmware updates, silicon revisions, and supply-chain substitutions. 0x5A is how you ask.

#sfdp #spi #norflash #firmware #embedded #macronix #mx25l25635f #jedec #bootloader #uefi #gdbplus

The serial port has been the firmware engineer’s eyes and ears for decades. But the physical path from CPU to UART has fundamentally changed. LPC gave way to eSPI, and the debug UART that used to live on a simple Super I/O chip now hides behind an Embedded Controller on a 4-wire serial bus. This article traces that path — from the eSPI bus to the UEFI driver stack — and shows exactly how to access and enable EC/SIO UARTs on modern platforms

.

Why eSPI Replaced LPC

The Low Pin Count bus served firmware well for 20 years, but it had three fatal flaws for modern platforms.

▸ Pin count: LPC required 7–13 pins. In a world where every pin on a 12×12 mm package is contested real estate, that is a luxury.

▸ Voltage: LPC ran at 3.3V signaling. Modern silicon is 1.8V and below. Level shifters add cost, latency, and board area.

▸ Speed: LPC topped out at 33 MHz. Firmware images grew from 2 MB to 32 MB. Every millisecond of boot time matters.

eSPI solves all three. Four wires (CS#, CLK, MOSI, MISO). 1.8V signaling. 66 MHz with double-data-rate transfers giving effective throughput of 132 Mbps per channel. And critically — it is a packetized serial protocol, not a parallel bus, which means it can carry multiple logical channels over the same physical wires.

The Four eSPI Channels

The eSPI specification (Intel document 327432) defines four virtual channels multiplexed over a single physical bus. Understanding which channel carries what is the key to debugging UART access issues.

▸ Channel 0 — Peripheral Channel: This is the LPC replacement. It carries memory-mapped I/O cycles and I/O-mapped I/O cycles. When UEFI reads or writes a UART register (I/O port 0x3F8 for COM1), the transaction travels over Peripheral Channel as a standard I/O read/write cycle. The EC or SIO decodes it and performs the actual UART hardware access. From the PCH’s perspective, it is talking to an LPC device through a serial tunnel.

▸ Channel 1 — Virtual Wire Channel: Sideband signals that used to have dedicated pins on LPC — SMI#, SCI#, PME#, SERIRQ — are now serialized as virtual wire messages. The UART interrupt line (typically IRQ4 for COM1) rides on Virtual Wire as an SERIRQ message.

▸ Channel 2 — OOB Message Channel: Out-of-band messaging. This replaces SMBus for EC communication. MCTP (Management Component Transport Protocol) packets flow here. Not directly relevant to UART access, but critical for EC firmware updates and BMC interactions.

▸ Channel 3 — Flash Access Channel: Shared SPI flash access. The EC can access the system SPI flash through this channel for firmware updates. BIOS and EC firmware can share a single SPI flash chip.

The critical insight for UART debugging: The UART appears on Channel 0 as standard I/O cycles. The entire pre-existing UEFI serial stack — PciSioSerialDxe, SerialPortLib, DebugLib — works completely unchanged. The EC/SIO translates eSPI I/O transactions into physical UART register reads and writes transparently. If you can talk to the eSPI controller, you can talk to the UART.

Real Hardware: Two Common Configurations

The eSPI ecosystem has converged on two dominant patterns: the EC (Embedded Controller) in mobile platforms, and the SIO (Super I/O) in desktop and server platforms.

Configuration A: EC-Based (Laptop/Notebook)

▸ Chip: Microchip MEC15xx — a dedicated Embedded Controller with eSPI slave interface

▸ Topology: PCH (eSPI Master) → eSPI Bus → MEC15xx (Slave) → Internal UART Block → UART TX/RX pins routed to debug header

▸ UARTs: MEC15xx typically exposes 2–3 16550-compatible UARTs. One is dedicated to debug output, another may be used for serial peripheral communication (touchpad, battery gas gauge).

▸ EC firmware: The MEC15xx runs its own firmware (typically Microchip’s MEC15xx SDK). The EC firmware must configure the UART pin mux and enable the UART clock before UEFI can access it. If UEFI DEBUG() output is silent, the first thing to check is whether EC firmware actually enabled the UART routing.

▸ Register access: From UEFI’s perspective, the UART appears at a standard I/O base address (e.g., 0x3F8). The PCH’s eSPI controller translates I/O cycles in that range into Peripheral Channel transactions targeting the EC. The EC’s hardware auto-decoder routes them to the UART block.

Configuration B: SIO-Based (Desktop/Server)

▸ Chip: ITE IT8628E — a Super I/O controller with eSPI interface

▸ Topology: PCH (eSPI Master) → eSPI Bus → IT8628E (Slave) → Logical Device UART1/UART2 → Physical COM port headers

▸ UARTs: IT8628E typically provides 2–4 fully independent 16550-compatible UARTs, each with its own logical device number (LDN). LDN 0x01 is usually UART1, LDN 0x02 is UART2, and so on.

▸ SIO register model: Unlike the EC model where register access is transparent, the IT8628E uses the classic Super I/O configuration model: enter configuration mode by writing 0x87 to the config port (typically 0x2E or 0x4E), select a logical device, enable it, set the I/O base address, and exit configuration mode. This must be done in PEI or early DXE before PciSioSerialDxe enumerates the device. The EFI_SIO_PROTOCOL’s RegisterAccess() function handles this enter/exit sequence.

▸ eSPI implications: On the IT8628E, configuration register access also goes through eSPI Peripheral Channel. The SIO configuration ports (0x2E/0x2F or 0x4E/0x4F) are routed over eSPI as standard I/O transactions. No special handling is needed — but the eSPI controller must be initialized first.

The UEFI Driver Stack

The EDK2 driver stack for eSPI-based UART access is identical to the legacy LPC stack because eSPI abstracts the transport. Here is the full chain.

Layer 1 — PCI Root Bridge / eSPI Controller

The PCH’s eSPI controller appears as a PCI device (typically Device 1F, Function 0 on Intel platforms, DID 0x1Fxx range). Platform silicon initialization in PEI configures the eSPI frequency, I/O decode ranges, and channel enables. If this layer is misconfigured, all downstream devices are invisible.

Key PEI responsibilities from MdePkg/Include/Ppi/SuperIo.h:

EFI_SIO_REG(ldn, reg)          // Pack logical device + register into a single UINT16
EFI_SIO_LDN_GLOBAL             // Special LDN for global SIO registers (0xFF)

Layer 2 — SioBusDxe

The SioBusDxe driver (OvmfPkg/SioBusDxe/) is the reference implementation for Super I/O bus enumeration. It creates child handles for each logical device on the SIO and installs EFI_SIO_PROTOCOL on them. The SioService.h header defines the core protocol:

EFI_SIO_PROTOCOL.Sio.RegisterAccess()  // Low-level SIO register read/write
EFI_SIO_PROTOCOL.Sio.GetResources()    // ACPI resource descriptors
EFI_SIO_PROTOCOL.Sio.Modify()          // Table-based RMW operations

Layer 3 — PciSioSerialDxe

This is the workhorse. MdeModulePkg/Bus/Pci/PciSioSerialDxe/ produces EFI_SERIAL_IO_PROTOCOL on each SIO child handle that has a UART logical device. The Serial.h header defines the complete UART register map:

#define SERIAL_REGISTER_THR  0   // Transmit Holding Register
#define SERIAL_REGISTER_RBR  0   // Receive Buffer Register
#define SERIAL_REGISTER_DLL  0   // Divisor Latch LSB
#define SERIAL_REGISTER_IER  1   // Interrupt Enable Register
#define SERIAL_REGISTER_FCR  2   // FIFO Control Register
#define SERIAL_REGISTER_LCR  3   // Line Control Register
#define SERIAL_REGISTER_MCR  4   // Modem Control Register
#define SERIAL_REGISTER_LSR  5   // Line Status Register

The driver handles both PCI-native UARTs and SIO-based UARTs through a union type:

typedef union {
  EFI_PCI_IO_PROTOCOL    *PciIo;
  EFI_SIO_PROTOCOL       *Sio;
} PARENT_IO_PROTOCOL_PTR;

This means the same SerialIo protocol implementation works regardless of whether the UART is behind a PCI BAR or an SIO logical device. For eSPI EC/SIO UARTs, the Sio path is used.

Layer 4 — SerialPortLib

Platform-specific. In OVMF, it is OvmfPkg/Library/BaseSerialPortLib16550/. In physical platforms, it is typically a custom library that knows the platform’s UART base address (from PCD), clock rate, and register stride. It uses the fixed PCDs to configure the UART without depending on the DXE driver stack — this is critical because DEBUG() output begins in SEC phase, long before SioBusDxe or PciSioSerialDxe load.

Layer 5 — DebugLib

MdePkg/Library/BaseDebugLibSerialPort/ — every DEBUG((DEBUG_INFO, "...")) call eventually lands in SerialPortWrite() and bytes travel out through the eSPI UART.

Platform Configuration: The PCD Settings

The entire UART access path is controlled by a small set of PCDs. Getting one wrong produces silent failure.

▸ PcdSerialUseMmio — Must be FALSE for eSPI UARTs. eSPI Peripheral Channel carries I/O cycles, not MMIO. Setting this to TRUE is the most common misconfiguration.

▸ PcdSerialRegisterStride — Standard 16550 UARTs use stride 1 (adjacent I/O ports). Some PCI UARTs use stride 4 (DWORD-aligned access). For EC/SIO UARTs, this is always 1.

▸ PcdSerialBaudRate — 115200 is the firmware standard. Do not use 921600 for debug output — the eSPI Channel 0 turnaround time can introduce jitter that the UART’s 16-byte FIFO cannot absorb at very high baud rates.

▸ PcdSerialClockRate — 1.8432 MHz is the 16550 standard. Some ECs use an internal 48 MHz oscillator with a fractional divider. If the divider is off by even 0.1%, baud rate mismatch will cause framing errors. Verify the EC datasheet for the actual UART clock source.

▸ PcdPciSerialParameters — A table of PCI_SERIAL_PARAMETER structures for PCI UARTs. For SIO-based UARTs behind eSPI, this may not be needed; the SIO enumeration path discovers UARTs dynamically.

▸ PcdSerialLineControl — Set to 0x03 for 8 data bits, no parity, 1 stop bit (8N1). The encoding follows the 16550 LCR register format: bits[1:0] for word length (11 = 8 bits), bit[2] for stop bits (0 = 1 stop bit), bits[5:3] for parity (000 = none).

Boot-Time Initialization Sequence

Understanding the exact order of initialization is essential when debugging why the serial console is silent.

Phase 1 — SEC/PEI: Early Debug Output

The platform’s SerialPortLib constructor is called. It reads PcdSerialUseMmio, PcdSerialRegisterBase, PcdSerialBaudRate, and other PCDs, then directly programs the UART hardware via I/O instructions. This works because:

1. The PCH eSPI controller was configured by the boot ROM (hardware straps or early PEI silicon init) to route I/O cycles in the COM1 range (0x3F8–0x3FF) to eSPI Channel 0 targeting the EC/SIO.

2. The EC/SIO was already powered on and its UART clock was enabled by EC firmware or hardware defaults.

If DEBUG() output works in SEC/PEI but stops in DXE, the eSPI routing was reconfigured mid-boot — a common silicon init bug.

Phase 2 — DXE: SioBusDxe Loads

SioBusDxe connects to the PCI-to-ISA/eSPI bridge. It enumerates the SIO chip’s logical devices using the standard Super I/O configuration sequence (enter config mode → read device ID → enumerate LDN → exit config mode). For IT8628E, this means accessing ports 0x2E/0x2F or 0x4E/0x4F over eSPI Peripheral Channel.

For the MEC15xx, the enumeration path is different — the EC is not a classic Super I/O and is typically discovered via ACPI or a platform-specific protocol rather than through config port probing.

Phase 3 — DXE: PciSioSerialDxe Loads

PciSioSerialDxe binds to each SIO child handle that represents a UART logical device. It installs EFI_SERIAL_IO_PROTOCOL and calls SerialPortInitialize() to configure the UART hardware (baud rate, data bits, FIFO enable).

Phase 4 — BDS: Console Connection

During BDS, ConSplitterDxe connects the serial console. TerminalDxe produces the SIMPLE_TEXT_OUTPUT_PROTOCOL on top of the SerialIo protocol, enabling printf-style output to the serial port.

Debugging the Silent Serial Port

When the serial port is silent, work through this checklist in order.

▸ Verify eSPI controller init: Check that the PCH eSPI controller is out of reset and the I/O decode ranges include the COM port base address. On Intel platforms, this is in the LPC/eSPI PCI configuration space at Bus 0, Device 0x1F, Function 0.

▸ Verify EC/SIO is powered: The MEC15xx requires VTR (trickle power) and VCC. If VCC is not up, the eSPI slave interface is dead. Check the platform power sequencing.

▸ Verify EC firmware UART init: On MEC15xx platforms, the EC runs its own firmware. If the EC firmware does not configure the UART pin mux and enable the UART clock, no amount of UEFI configuration will produce output. Dump the EC firmware console if available.

▸ Verify SIO configuration mode: For IT8628E, check that the SIO logical device for UART1 (LDN 0x01) is enabled and its I/O base address is set to 0x3F8. Use the ITE configuration sequence: write 0x87 to 0x2E, write 0x87 to 0x2E (double-write enter), then read LDN 0x01 register 0x30 (enable) and registers 0x60-0x61 (base address).

▸ Check PcdSerialUseMmio: If this is TRUE but the UART is I/O-mapped, all register accesses go to the wrong address space. This produces silent failure — no crash, no output, just nothing. This is the single most common misconfiguration for eSPI UART access.

▸ Scope the eSPI bus: If you have physical access, scope the eSPI CS#, CLK, and MOSI/MISO lines. You should see Channel 0 I/O cycles during DEBUG() output. If the bus is idle, the eSPI controller is not routing UART I/O cycles.

Why This Matters

Firmware debugging without a serial console is like surgery in the dark. On modern platforms, the debug UART is no longer a simple PCI or LPC device — it is an endpoint on a packet-switched serial network. The debugging surface has expanded from one chip (the UART) to four layers (eSPI controller, eSPI bus, EC/SIO firmware, UART hardware).

Understanding the full path — and knowing which layer is responsible for what — turns hours of blind debugging into minutes of targeted investigation.

#firmware #uefi #espi #embedded #debug #bios #edk2 #gdbplus

Subscribe now

You power on a QEMU VM with OVMF firmware. The UEFI Shell appears in the boot menu. You type exit, and your OS boots. But have you ever wondered — how did BDS know the Shell was even there?

Unlike a disk-based OS loader, Shell.efi lives inside the firmware volume (FV). It has no BlockIo handle. No SimpleFileSystem. No LoadFile protocol. BDS’s standard auto-enumeration cannot see it. So how does it become a boot option?

Let’s trace the entire chain from firmware build to boot menu.

The Build-Time Foundation: A GUID is Born

It starts in ShellPkg/Application/Shell/Shell.inf:

FILE_GUID = 7C04A583-9E3E-4f1c-AD65-E05268D0B4D1

This GUID is the unique identifier that will follow Shell.efi through its entire lifecycle. ShellPkg/ShellPkg.dec aliases it as gUefiShellFileGuid so platform code can reference it symbolically.

When the firmware image is built, Shell.efi is embedded as an FFS (Firmware File System) file inside the DXE firmware volume. Its NameGuid in the FV header is that same 7C04A583-... GUID. The platform knows exactly where to look.

BDS Phase: Auto-Enumeration Misses the Shell

When BDS enters PlatformBootManagerAfterConsole(), the first thing it does is call EfiBootManagerRefreshAllBootOption(). This function scans for:

▸ BlockIo devices — disks, USBs, NVMe drives

▸ LoadFile protocols — network boot, HTTP boot

▸ SimpleFileSystem — partitions with recognizable filesystems

For each, it constructs a device path and creates a Boot#### NVRAM variable. This is how your OS loader, network boot, and USB boot options are auto-discovered.

But Shell.efi lives inside the firmware volume — it’s part of the firmware binary itself. It exposes none of the above protocols. Auto-enumeration completely misses it.

The Explicit Registration: PlatformRegisterFvBootOption()

After auto-enumeration, the platform code takes over. In OvmfPkg/Library/PlatformBootManagerLibLight/PlatformBm.c:

// Register UEFI Shell
PlatformRegisterFvBootOption(
    &gUefiShellFileGuid,          // 7C04A583-9E3E-...
    L"EFI Internal Shell",
    LOAD_OPTION_ACTIVE | LOAD_OPTION_CATEGORY_APP,
    ShellEnabled                  // from QEMU fw_cfg
);

This function does four things, in order:

▸ 1. Build a device path. It constructs MemoryMapped(...)/FvFile(7C04A583-9E3E-4f1c-...) by prepending the firmware volume’s memory-mapped device path to an FvFile node containing the GUID.

▸ 2. Verify the file actually exists. It calls FirmwareVolume2->ReadFile() with Buffer=NULL (metadata-only query) and the Shell’s GUID. If the FV doesn’t contain an FFS file with that NameGuid, the function returns immediately — no boot option created.

▸ 3. Deduplicate. It scans all existing Boot#### NVRAM variables. If a boot option with the same device path already exists, it either updates it (if attributes changed) or skips it (if unchanged). You don’t get duplicate Shell entries.

▸ 4. Write to NVRAM. If the file is found and the option is new, it calls EfiBootManagerAddLoadOptionVariable() which writes a new Boot#### variable and appends the option number to BootOrder.

The ShellEnabled flag comes from QEMU’s fw_cfg interface — opt/org.tianocore/EFIShellSupport. This lets you disable the Shell boot option entirely by passing -fw_cfg name=opt/org.tianocore/EFIShellSupport,string=no to QEMU. Without this flag, it defaults to TRUE.

The Cleanup Pass: RemoveStaleFvFileOptions()

Firmware gets rebuilt. The DXE FV might shift in memory. FILE_GUIDs might change. A Shell boot option from a previous firmware build could point to a file that no longer exists.

RemoveStaleFvFileOptions() walks every Boot#### variable and checks:

▸ Does the device path start with MemoryMapped(...) or Fv(...)?

▸ Does the next node begin with FvFile(...)?

If both conditions are met, it calls FileIsInFv() to verify the FFS file still exists. If not — delete the boot option. This prevents stale entries from accumulating across firmware updates.

The Final Order: SetBootOrderFromQemu()

After Shell registration and stale cleanup, the platform reads QEMU’s bootorder fw_cfg file. This determines the final BootOrder variable — which boot option BDS will try first, second, and so on.

The Shell is typically placed after disk and network boot options, so the system boots to your OS by default. But if you want the Shell first, you can control it via fw_cfg.

Why This Matters

Understanding this mechanism explains several practical behaviors:

▸ Why the Shell is always there — even on a “blank” VM with no disks attached, the Shell appears because it’s hard-coded into the platform BDS code.

▸ Why exit drops back to the boot menu — exiting the Shell returns control to BDS, which then tries the next option in BootOrder.

▸ Why you can disable it — the EFIShellSupport fw_cfg knob gives production firmware builds a clean escape hatch.

▸ Why stale firmware builds don’t cause problems — RemoveStaleFvFileOptions() automatically cleans up old GUID references.

The Complete Chain

Build time:
  Shell.inf FILE_GUID = 7C04A583-...
  → FFS file placed in DXE FV with that NameGuid

Boot time (PlatformBootManagerAfterConsole):
  1. EfiBootManagerRefreshAllBootOption()   → disk, net, USB options
  2. PlatformRegisterFvBootOption(gUefiShellFileGuid)
     → Build device path: FvFile(7C04A583-...)
     → FV2->ReadFile() — verify file exists
     → EfiBootManagerAddLoadOptionVariable() → Boot####, BootOrder
  3. RemoveStaleFvFileOptions()             → delete dead FvFile entries
  4. SetBootOrderFromQemu()                 → final boot sequence

The key insight: the Shell is not discovered — it’s hard-coded to be found. BDS explicitly hunts for it by GUID inside the firmware volume, because it knows exactly what it’s looking for.

#firmware #uefi #edk2 #bds #ovmf #bootloader #embeddedsystems #gdbplus

If you’ve written any EDK2 driver, you’ve typed gBS->AllocatePool(...) or gSmst->SmmAllocatePool(...) without ever declaring those variables. They just work. But why?

The short answer: EDK2’s library constructor system auto-initializes them before your module’s entry point even runs. Once you link the right library class, AutoGen wires up the call chain and the globals are ready. Here’s exactly how.

gBS — The Boot Services Pointer

Every DXE and UEFI driver includes UefiBootServicesTableLib.h and gets gBS for free. The mechanism has three layers:

Layer 1: The Header Declares extern

MdePkg/Include/Library/UefiBootServicesTableLib.h:

extern EFI_HANDLE         gImageHandle;
extern EFI_SYSTEM_TABLE  *gST;
extern EFI_BOOT_SERVICES *gBS;

Three globals, all extern. Your code just references them — the actual storage lives in the library.

Layer 2: The Library Owns the Definition and Constructor

MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.c:

EFI_HANDLE         gImageHandle = NULL;
EFI_SYSTEM_TABLE   *gST         = NULL;
EFI_BOOT_SERVICES  *gBS         = NULL;

EFI_STATUS EFIAPI
UefiBootServicesTableLibConstructor (
  IN EFI_HANDLE        ImageHandle,
  IN EFI_SYSTEM_TABLE  *SystemTable
  )
{
  gImageHandle = ImageHandle;
  gST          = SystemTable;
  gBS          = SystemTable->BootServices;   // ← the magic line
  ASSERT (gBS != NULL);
  return EFI_SUCCESS;
}

The constructor receives the same (ImageHandle, SystemTable) pair that your module entry point gets. It caches the Boot Services pointer into the global gBS — simple pointer assignment.

Layer 3: INF Declares CONSTRUCTOR

UefiBootServicesTableLib.inf:

CONSTRUCTOR = UefiBootServicesTableLibConstructor
LIBRARY_CLASS = UefiBootServicesTableLib|DXE_DRIVER UEFI_DRIVER ...

AutoGen reads this, generates ProcessLibraryConstructorList(), and embeds a call to it before your module’s entry point. That’s the whole trick: by the time your MyDriverEntryPoint() executes, the constructor has already run and gBS is valid.

How DXE Core Bootstraps This

The DXE Core itself links UefiBootServicesTableLib. During DxeMain(), it builds the System Table, populates gDxeCoreST, then calls:

ProcessLibraryConstructorList (gDxeCoreImageHandle, gDxeCoreST);

This fires the constructor, which sets gBS = gDxeCoreST->BootServices. For every subsequent DXE driver loaded by the dispatcher, CoreStartImage() calls the module’s entry point with the same SystemTable — and AutoGen’s generated wrapper calls constructors first, in dependency order.

gSmst — The SMM System Table Pointer

Same three-layer pattern, with one extra step: SMM lives in a separate address space, so you can’t just dereference the DXE SystemTable to find the SMM table.

Layer 1: Header

MdePkg/Include/Library/SmmServicesTableLib.h:

extern EFI_SMM_SYSTEM_TABLE2  *gSmst;

Layer 2: Constructor Uses a Protocol Gateway

MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.c:

EFI_SMM_SYSTEM_TABLE2  *gSmst = NULL;

EFI_STATUS EFIAPI
SmmServicesTableLibConstructor (
  IN EFI_HANDLE        ImageHandle,
  IN EFI_SYSTEM_TABLE  *SystemTable
  )
{
  EFI_SMM_BASE2_PROTOCOL  *SmmBase2;

  SystemTable->BootServices->LocateProtocol (
    &gEfiSmmBase2ProtocolGuid, NULL, (VOID **)&SmmBase2
    );
  SmmBase2->GetSmstLocation (SmmBase2, &gSmst);
  ASSERT (gSmst != NULL);
  return EFI_SUCCESS;
}

Notice the comment in the source: “Do not use gBS from UefiBootServicesTableLib on purpose to prevent inclusion of gBS, gST, and gImageHandle from SMM Drivers.” The constructor uses SystemTable->BootServices directly (the parameter, not the global) to locate the SMM Base 2 protocol, then calls GetSmstLocation() to retrieve the SMM System Table pointer. This is the bridge from the DXE world into SMM.

Layer 3: INF with DEPEX

SmmServicesTableLib.inf:

CONSTRUCTOR  = SmmServicesTableLibConstructor
MODULE_TYPE  = DXE_SMM_DRIVER
LIBRARY_CLASS = SmmServicesTableLib|DXE_SMM_DRIVER
[Depex]
  gEfiSmmBase2ProtocolGuid

The DEPEX guarantees EFI_SMM_BASE2_PROTOCOL is installed before the constructor runs. No SmmBase2 → dispatcher waits. SmmBase2 ready → constructor fires → gSmst is alive.

The Full Call Chain, Side by Side

▸ gBS (DXE/UEFI world): AutoGen wrapper → ProcessLibraryConstructorList → UefiBootServicesTableLibConstructor → gBS = SystemTable->BootServices → your EntryPoint

▸ gSmst (SMM world): DEPEX waits for SmmBase2 → AutoGen wrapper → ProcessLibraryConstructorList → SmmServicesTableLibConstructor → LocateProtocol → GetSmstLocation → gSmst filled → your EntryPoint

Same architecture, different protocol for crossing the SMM boundary.

Why This Design Matters

▸ Zero boilerplate: You never write gBS = SystemTable->BootServices in your own code. The library handles it.

▸ Consistent initialization: Every module gets gBS/gSmst the same way — no copy-paste drift across hundreds of drivers.

▸ Dependency ordering: AutoGen resolves library constructor order automatically. If Library A’s constructor needs gBS and Library B provides it, AutoGen calls B’s constructor first.

▸ SMM isolation: By using SystemTable (the parameter) instead of the global gBS, the SMM library constructor avoids pulling the entire DXE global set into SMM drivers. Clean separation.

What You Actually Need to Do

Nothing. Just include the right library class in your INF:

[LibraryClasses]
  UefiBootServicesTableLib    # for gBS, gST, gImageHandle
  SmmServicesTableLib         # for gSmst (SMM drivers only)

Include the header in your source, and call gBS->Whatever() or gSmst->Whatever() — they’re already initialized when your entry point runs.

#firmware #uefi #edk2 #smm #embeddedsystems #gdbplus

The Winbond W25Q256JV is a workhorse 256 Mbit (32 MB) Serial NOR flash. It shows up on motherboards, embedded Linux boards, and anywhere you need reliable, fast non‑volatile storage for firmware. If you’re writing UEFI EDK2 drivers or integrating it into a Linux system, you don’t need the glossy feature list — you need the raw datasheet facts that actually matter when the silicon meets your code. This article distills exactly that, without a single markdown table in sight.

Quick Identification

When your SPI controller probes the bus, here’s what you’ll see:

• JEDEC Manufacturer ID: EFh (Winbond)

• Device ID: 4019h
  Note: The older W25Q256FV shares the same ID, so you can’t tell them apart by JEDEC ID alone. See the SFDP and addressing mode sections for the crucial difference.

• Density: 256 Mbit (32 MiB)

• Supply voltage: 2.7 V – 3.6 V (JV = standard voltage, as opposed to the lower‑voltage JM variant)

• SFDP table location: The mandatory JEDEC SFDP table starts at address 000000h, first header at offset 80h.

• Unique ID: A factory‑programmed 64‑bit serial number, readable with command 4Bh.

Memory Architecture & Erase Operations

The flash is organised as a flat array of 4 KB sectors. Understanding the erase granularity is essential for laying out firmware volumes and UEFI variable stores.

• Sector — 4 KB
  Command: 20h (3‑byte address) or 21h (4‑byte address)
  Typical use: UEFI variable storage, small FFS files, anything that requires fine‑grained updates.

• Block (32 KB) — 32 KB
  Command: 52h / 5Ch (4‑byte)
  Typical use: Less common; useful when 64 KB blocks are too large but you want more than a sector.

• Block (64 KB) — 64 KB
  Command: D8h / DCh (4‑byte)
  Typical use: Large firmware volumes, kernel/initramfs partitions, the bread‑and‑butter erase unit for most firmware layouts.

• Chip Erase — Full 32 MB
  Command: C7h or 60h
  Note: This takes around 200 seconds. Don’t use it in a boot path.

The chip contains exactly 8,192 sectors of 4 KB each.

Write granularity: 1 to 256 bytes per page. A page is 256 bytes, and you must not cross a page boundary in a single program command. Partial page writes are allowed, but the address automatically wraps within the page.

The Essential Command Set

Forget the 200‑page datasheet; these are the opcodes you’ll actually use in firmware and kernel code. All numbers are in hexadecimal.

Read Operations

• Standard Read (03h) — 1‑line input, 1‑line output. Slow (≤50 MHz) but easy to bring up.

• Fast Read (0Bh, 4‑byte addr variant 0Ch) — Adds dummy cycles for higher clock rates (up to 133 MHz). 1‑line data out.

• Dual Output Read (3Bh, 4‑byte 3Ch) — Two data lines.

• Quad Output Read (6Bh, 4‑byte 6Ch) — Four data lines. Requires Quad Enable bit (QE) = 1 in Status Register 2.

• Quad I/O Read (EBh, 4‑byte ECh) — The fastest option. Uses 4 lines for address, mode bits, and data. QE must be set.

Program & Erase

• Write Enable (06h) — Must be issued before every program, erase, or status register write. Sets the Write Enable Latch (WEL). WEL auto‑clears after the operation completes.

• Volatile SR Write Enable (50h) — Required before writing Status Register 1 if the SRP bits lock it.

• Page Program (02h, 4‑byte 12h) — Up to 256 bytes, single data line.

• Quad Page Program (32h, 4‑byte 34h) — Faster programming using 4 data lines. QE must be set.

• Sector Erase 4 KB — 20h / 21h

• Block Erase 32 KB — 52h / 5Ch

• Block Erase 64 KB — D8h / DCh

• Chip Erase — C7h or 60h

Status Register Management

• Read Status Register 1 — 05h

• Read Status Register 2 — 35h

• Read Status Register 3 — 15h

• Write Status Register 1 — 01h

• Write Status Register 2 — 31h

• Write Status Register 3 — 11h

Address Mode Control

• Enter 4‑Byte Address Mode — B7h (immediate, volatile)

• Exit 4‑Byte Address Mode — E9h

Security & Identification

• Read Unique ID — 4Bh (returns 8 bytes)

• Read SFDP — 5Ah (3‑byte address, reads JEDEC parameter table)

• Read Security Registers — 48h

• Program Security Registers — 42h

• Erase Security Registers — 44h

Status Register Bits Demystified

Three status registers govern everything from write protection to quad mode. Here’s the bit‑by‑bit breakdown.

Status Register 1 (read with 05h, write with 01h)

• Bit 0 – WIP (Write In Progress): 1 = the device is busy with an internal program/erase/write cycle. Poll this to know when an operation finishes.

• Bit 1 – WEL (Write Enable Latch): 1 = the device is ready to accept a program or erase command. You set this with 06h.

• Bits 2–4 – BP0, BP1, BP2: Block Protect bits. Together they define a protected area that cannot be programmed or erased. The exact region depends on TB, SEC, and CMP settings.

• Bit 5 – TB (Top/Bottom): Selects whether the protected area starts from the top or the bottom of the memory.

• Bit 6 – SEC (Sector/Block Protect): 0 = protection works in 64 KB blocks; 1 = protection works in 4 KB sectors.

• Bit 7 – SRP0 (Status Register Protect 0): Together with SRP1 (in SR2), it controls whether SR1 can be written or is permanently locked.

Status Register 2 (read 35h, write 31h)

• Bit 4 – QE (Quad Enable): This is the gatekeeper for all quad‑SPI operations. It must be 1 before you issue any quad read or quad page program command. If your quad reads silently return garbage, check this bit first.

• Bit 5 – CMP (Complement Protect): Inverts the block‑protection logic for certain configurations.

• Bit 6 – WPS (Write Protect Selection): Used when external hardware write‑protect pin is active.

• Bit 7 – SRP1: Works with SRP0 to lock the status registers.

Status Register 3 (read 15h, write 11h)

• Bit 1 – ADS (Address Mode): 1 = 4‑byte address mode is active. This bit is non‑volatile, so it survives power cycles. In EDK2 you may prefer the volatile B7h command to avoid permanent changes.

• Bits 2 and 6 – DRV0, DRV1: Output driver strength selection. Useful for signal integrity tuning on high‑speed boards.

• Bit 7 – HOLD/RST: Configures the HOLD#/RESET# pin function.

Important for EDK2: The W25Q256JV powers up in the address mode defined by the non‑volatile ADS bit. If your board ships with 3‑byte mode, you’ll need to enter 4‑byte mode at boot (via B7h) to access the full 32 MB.

Addressing Modes: 3‑Byte vs. 4‑Byte

This is where many bring‑up sessions go off the rails. The chip can operate with either 3‑byte (24‑bit) or 4‑byte (32‑bit) addresses.

• 3‑byte mode: Only the lower 16 MB (128 Mbit) are accessible. Any command with an address above FFFFFFh wraps around. This is the legacy mode.

• 4‑byte mode: Full 32 MB address space is available. You can enter this mode in two ways:

  • Volatile — Command B7h. The mode persists until the next power cycle or hardware reset.

  • Non‑volatile — Write the ADS bit in Status Register 3. This survives power cycles but is a write cycle that wears the flash slightly.

How to pick the right commands: The datasheet defines separate opcodes for many operations when using 4‑byte addresses. For example, Sector Erase is 20h with 3‑byte address but 21h when you’re passing a 4‑byte address directly, without having switched the device into 4‑byte mode via B7h. If you have entered 4‑byte mode with B7h, then you can use the legacy opcodes (20h, 02h, etc.) and they will interpret the address as 4 bytes. The Linux kernel and many EDK2 drivers use the explicit 4‑byte opcodes for clarity.

Linux kernel note: Because the W25Q256FV and JV share the same JEDEC ID, the SPI‑NOR subsystem checks the SFDP header version to decide whether 4‑byte addressing is truly supported. The JV’s SFDP correctly advertises this capability; the FV’s does not. You don’t need to handle this manually — just make sure your kernel prints successfully parsed SFDP during boot.

EDK2 rule of thumb: Most platforms simply send B7h in the PEI or early DXE phase and then use 4‑byte addresses everywhere. If you ever fall back to 3‑byte mode (via E9h or a power cycle), remember to re‑enter 4‑byte mode before accessing firmware volumes above 16 MB.

Security Registers & Unique ID

Beyond the main array, the chip provides three 256‑byte security registers. These are ideal for storing board‑specific data, serial numbers, or public keys.

• Register 1 — Volatile (lost on power‑down). Good for temporary data.

• Registers 2 and 3 — OTP (One‑Time Programmable). You can program them and then lock them permanently by writing a special byte to a lock register. Once locked, they become read‑only forever — ideal for factory‑provisioned keys.

• Unique ID: An 8‑byte, factory‑programmed serial number. Access it with command 4Bh. This can serve as a device identity, UUID seed, or part of a secure boot chain.

SFDP: The Self‑Describing Flash

The Serial Flash Discoverable Parameter (SFDP) table is a standardised data structure inside the flash. It describes all the capabilities we’ve listed above in a machine‑readable format: supported opcodes, erase sizes, voltage ranges, timings, and mode‑switch sequences.

• Read command: 5Ah (needs a 3‑byte address and dummy cycles)

• Linux: The SPI‑NOR subsystem relies heavily on SFDP. If the kernel can parse it, you don’t need to hardcode any opcodes or erase sizes in the device tree. A log message like spi-nor spi0.0: w25q256jv (32768 Kbytes) confirms a happy SFDP parse.

• EDK2: SFDP usage is optional. Many EDK2 SPI flash drivers still use hardcoded tables for known JEDEC IDs. If you’re writing a new driver, consider using SFDP to auto‑configure timings and capabilities — it reduces platform‑specific hacks.

Critical Timing Parameters

You won’t need most of the nanoseconds‑precision numbers until you debug signal integrity, but these typical durations should always be in your head when writing firmware.

• Power‑up to first command: ~5 ms. Don’t try to talk to the chip immediately after power‑on.

• Page Program (256 bytes): ~0.4 ms

• Sector Erase (4 KB): ~45 ms

• Block Erase (64 KB): ~150 ms

• Chip Erase: ~200 seconds (you read that right — a full three minutes)

• Write Status Register: ~10 ms

After issuing an erase or program, poll the WIP bit (Status Register 1, bit 0) until it clears. Never rely on fixed delays unless you’re in a bare‑metal context with no interrupt infrastructure and even then, it’s risky.

Platform Deep Dives

For EDK2 Firmware Developers

1. Driver skeleton: Implement your SpiNorFlashRead(), SpiNorFlashWrite(), and SpiNorFlashErase() around the command set above. Use the appropriate opcode for the current address mode.

2. Write enable ritual: Every program/erase must be preceded by 06h. WEL self‑clears on completion, but a failed command may leave it set — don’t assume state.

3. Page boundaries: Never write across a 256‑byte page boundary. Your write routine should split larger buffers into page‑aligned chunks.

4. Address mode housekeeping: Enter 4‑byte mode (B7h) early in PEI. If your reset vector or SEC phase runs from this flash, ensure the hardware boot ROM or pre‑initialisation stage has already switched to 4‑byte mode, or keep the initial code within the lower 16 MB.

5. Block protection cleanup: After a firmware update, you may need to clear the BP bits in SR1 to allow writes to the entire chip. Check them if writes fail silently.

6. Variable storage: For UEFI variables, use 4 KB sectors and implement wear‑levelling at the firmware level. The chip’s 100,000 cycle endurance per sector is plenty for a well‑designed variable driver.

7. Security registers: Use them for platform manufacturing data. Locking them is irreversible, so test carefully.

For Linux Kernel Developers

1. Device tree binding: The compatible string "winbond,w25q256jv" must be paired with "jedec,spi-nor". The kernel’s SPI‑NOR framework will handle the rest once it reads SFDP.

2. Partitioning: Define MTD partitions either as child nodes in the device tree or via the mtdparts= kernel command line. Align partitions to erase block boundaries (preferably 64 KB) to avoid unwanted erase of adjacent data.

3. Quad mode activation: The QE bit (SR2 bit 4) is set automatically by the framework when your device tree specifies spi-rx-bus-width = <4>; or spi-tx-bus-width = <4>;. Make sure your SPI controller actually supports quad mode.

4. 4‑byte addressing: The kernel handles this transparently if SFDP is parsed. If you’re on a buggy board where SFDP fails, you may need to force it via the m25p,fast-read and address‑width quirks, but that’s rare.

5. Verification tools: After boot, use lsmtd, mtdinfo, or peek at /sys/class/mtd/ to confirm the flash is detected and sized correctly. flashrom is your friend for low‑level read/write tests during bring‑up.

Final Thoughts

The W25Q256JV is a well‑behaved, modern SPI NOR flash that doesn’t hide many surprises once you understand its status register layout and address‑mode quirk. The most common stumbling blocks are:

• Forgetting to set the QE bit before quad operations.

• Assuming 4‑byte addressing works identically on the FV and JV variants (the JV is the one you want for >16 MB).

• Crossing page boundaries during writes.

• Over‑relying on fixed delays instead of polling WIP.

Keep this cheat sheet handy when you’re deep in SpiFlashErase() and the chip is stubbornly not erasing. Chances are, the answer is a single bit flip away.

If you found this useful, consider subscribing for more firmware‑level deep dives. And if you’re wrestling with a different flash chip, drop a comment — I might cover it next.
W25Q256JV.pdf

Subscribe now

The Software SMI (SW SMI) is the primary inter-process communication mechanism between the Normal World (DXE/Runtime) and the Secure World (SMM) in UEFI firmware. Understanding exactly how an SMI gets triggered — and how handlers get dispatched — is essential for anyone writing SMM drivers, debugging firmware issues, or designing platform firmware.

This article walks through all four hardware trigger mechanisms, the protocol architecture that abstracts them, and the handler dispatch chain inside SMM

The Hardware: Four Ways to Assert SMI#

Before any software protocol enters the picture, there has to be a hardware mechanism that pulls the CPU’s SMI# pin. EDK2 supports four distinct approaches, varying by chipset generation and platform.

1. I/O Port — The APM Register (Intel ICH/PCH Classic)

The oldest and most widely recognized mechanism. The Intel ICH and its successors (PCH) expose two I/O ports in the ACPI PM I/O space:

▸ ICH9_APM_STS (0xB3): The “data” or “status” register — a scratchpad that passes a byte to the SMI handler without triggering the SMI on its own.

▸ ICH9_APM_CNT (0xB2): The “command” register — writing to this port causes the chipset to assert SMI# on the CPU.

The sequence matters: write the data byte to APM_STS first, then write the command byte to APM_CNT. The SMM handler reads both back to determine which SW SMI was requested and what data was passed. This is the classic two-register pattern used on virtually all Intel-based platforms for two decades.

From the OVMF implementation in OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.c:

IoWrite8 (ICH9_APM_STS, DataPort    == NULL ? 0 : *DataPort);
IoWrite8 (ICH9_APM_CNT, CommandPort == NULL ? 0 : *CommandPort);

The chipset must be configured to route APM port writes to SMI generation — this is done by setting the APMC_EN and GBL_SMI_EN bits in the SMI_EN register, then locking the SMI_LOCK bit in GEN_PMCON_1 to prevent tampering.

2. SMM IPI — MSR / LAPIC Inter-Processor Interrupt

For multi-processor SMM entry, the BSP needs to bring all APs into SMM synchronously. This is done via an SMM IPI — a special inter-processor interrupt with delivery mode set to SMI.

The BSP writes to either the SMM IPI MSR or the Local APIC ICR (Interrupt Command Register) with the delivery mode field set to SMI (010b). This causes the target CPU(s) to assert their internal SMI# signal without any chipset involvement.

This approach is critical for the PiSmmCpu driver in UefiCpuPkg/PiSmmCpuDxeSmm/SmmMp.c, which uses SendSmiIpiAllExcludingSelf() to synchronize all APs into SMM during initialization and for periodic SMI-based MP services. The PI spec explicitly notes that “the ability to generate this event from a platform chipset agent is an optional capability” — making SMM IPI the processor-level fallback when chipset SMI isn’t available.

3. PCI Configuration Space — Southbridge Registers

Some platforms — particularly AMD-based systems and certain server designs — expose SMI trigger capability through PCI configuration space registers on the southbridge or FCH (Fusion Controller Hub).

Even on Intel platforms, the SMI enable and lock bits are configured via PCI config space. The OVMF SmmControl2Dxe driver uses PciRead32() and PciOr16() on the Q35 MCH (Bus 0, Device 0, Function 0) to read the PMBASE register and configure the SMI_EN and GEN_PMCON_1 registers:

PmBase = PciRead32 (POWER_MGMT_REGISTER_Q35 (ICH9_PMBASE)) &
         ICH9_PMBASE_MASK;
mSmiEnable = PmBase + ICH9_PMBASE_OFS_SMI_EN;

On some AMD platforms, the entire SMI trigger path — not just configuration — goes through PCI config space reads and writes to the southbridge’s SMI generation registers.

4. MMIO — Memory-Mapped Chipset BAR

Modern Platform Controller Hubs (PCH) and Power Management Controllers (PMC) map their registers into MMIO space through a PCI Base Address Register (BAR). Instead of legacy I/O port 0xB2, you write to:

PmcBase + SMI_CTRL_OFFSET

Where PmcBase comes from the PMC device’s PCI BAR. This is the direction all modern Intel platforms (starting with Skylake-era PCHs) have moved toward — MMIO-mapped SMI generation, eliminating the need for the legacy I/O port 0xB2 entirely.

The software interface remains identical — you’re still writing a command byte and optionally a data byte — but the transport is an MMIO write instead of an out instruction.

The Protocol Stack: How EDK2 Abstracts All Four

The elegance of EDK2 is that none of the above hardware differences leak into SMM driver code. Two protocols provide the complete abstraction:

SmmControl2 Protocol — Trigger from DXE

EFI_SMM_CONTROL2_PROTOCOL (MdePkg/Include/Protocol/SmmControl2.h) is a DXE Runtime protocol with two functions:

▸ Trigger(CommandPort, DataPort, Periodic, Interval): Engenders the SMI. The platform-specific implementation writes to whatever hardware register (I/O, PCI, MMIO, or MSR) generates SMI#.

▸ Clear(Periodic): Acknowledges and clears any software status from the previous Trigger(). The PI spec explicitly notes that Clear() is not responsible for deasserting SMI# — that happens automatically on SMM entry.

▸ MinimumTriggerPeriod: Read-only field specifying the minimum periodic interval the hardware supports. Set to MAX_UINTN when periodic SMI is unsupported.

Every SMM consumer — whether it’s SmmCommunication, a variable driver, or a TCG driver — calls the same Trigger() interface. The platform DSC includes the appropriate SmmControl2Dxe implementation for its chipset, and that’s where the hardware-specific write lives.

SmmSwDispatch2 Protocol — Register Handlers in SMM

On the SMM side, EFI_SMM_SW_DISPATCH2_PROTOCOL (MdePkg/Include/Protocol/SmmSwDispatch2.h) lets SMM drivers register callback functions for specific SW SMI values:

typedef struct {
  UINTN    SwSmiInputValue;
} EFI_SMM_SW_REGISTER_CONTEXT;

A driver calls Register(DispatchFunction, &RegisterContext, &DispatchHandle), specifying the SwSmiInputValue it wants to handle. The SMM core maintains a dispatch table, and when an SMI arrives with that command byte, it calls the registered function.

Each SwSmiInputValue can have exactly one handler — it’s a 1:1 mapping. The handler receives an EFI_SMM_SW_CONTEXT containing:

▸ SwSmiCpuIndex: Which CPU generated the SMI

▸ CommandPort: The value written to APM_CNT (0xB2)

▸ DataPort: The value written to APM_STS (0xB3)

The SmmCommunication Layer: Multiplexing Over a Single SMI

Hardware SW SMI values are a scarce resource — Intel ICH supports only values 00h-0FFh, and many are reserved for platform firmware. A single SW SMI number can’t serve dozens of consumers... unless you add a second dispatch layer.

This is exactly what PiSmmCommunication does. It consists of a DXE driver and an SMM driver working together:

On the DXE side (SmmCommunication protocol consumer):

▸ Populate an EFI_SMM_COMMUNICATE_HEADER with a HeaderGuid and MessageLength

▸ Store a pointer to this header in an ACPI NVS memory location

▸ Call SmmControl2→Trigger() with the PiSmmCommunication SW SMI number as the command byte

On the SMM side (PiSmmCommunicationSmm):

▸ The PiSmmCommunicationHandler reads the CommBuffer pointer from ACPI NVS

▸ Validates the buffer is outside SMRAM (security check)

▸ Calls gSmst→SmiManage(&CommunicateHeader→HeaderGuid, NULL, &Data, &CommSize)

SmiManage does a GUID-based dispatch — it looks up the HeaderGuid in the SMM handler database and routes the buffer to whichever driver registered for that GUID. This is how a single hardware SW SMI (e.g., value 0xE3) can serve the variable driver, the TCG driver, the FPDT driver, and any number of other SMM consumers — each with its own GUID-based channel.

The PiSmmCommunicationSmm driver registers for SwSmiInputValue = (UINTN)-1, which tells the SmmSwDispatch2 to auto-assign an available SW SMI number. The assigned number is saved in the SmmCommunicationContext and retrieved by the PEI/DXE side through the SMM Configuration Table.

The Dispatch Chain: End to End

Putting it all together, here’s the complete flow from a DXE driver wanting to communicate with SMM:

1. DXE driver fills an EFI_SMM_COMMUNICATE_HEADER with its GUID and payload

2. DXE driver calls SmmCommunication→Communicate(), which stores the buffer pointer in ACPI NVS

3. SmmCommunication calls SmmControl2→Trigger(SW_SMI_NUMBER, 0)

4. SmmControl2Dxe writes to the platform-specific hardware (I/O port 0xB2, PCI, MMIO, or SMM IPI)

5. CPU asserts SMI#, saves state, jumps to SMBASE+8000h

6. PiSmmCpu entry point reads APM_STS (or equivalent) to get SwSmiInputValue

7. SmiManage dispatches by SwSmiInputValue to PiSmmCommunicationHandler

8. PiSmmCommunicationHandler reads CommBuffer from ACPI NVS, validates it

9. PiSmmCommunicationHandler calls SmiManage(&HeaderGuid, ...) for second-level GUID dispatch

10. The target SMM driver’s registered callback receives the data

Platform Examples

OVMF (QEMU Q35): Uses approach #1 (I/O port 0xB2/0xB3). SmmControl2Dxe in OvmfPkg/SmmControl2Dxe/ configures ICH9 APM registers. Source: SmmControl2Dxe.c lines 115-116.

Intel Reference Platforms: SmmControl2 is typically provided by the PchSmmControl driver in the platform’s silicon package, which writes to the PCH PMC MMIO space (approach #4 on modern platforms).

PiSmmCommunication: The reference implementation in UefiCpuPkg/PiSmmCommunication/ shows the complete DXE/SMM dance — SmmSwDispatch2 registration in PiSmmCommunicationSmm.c (line 184-193) and Trigger in PiSmmCommunicationPei.c (line 337-346).

The SW SMI mechanism may be considered “legacy” — and indeed, newer platforms are moving toward MM Communication over shared memory without SMI — but understanding these four hardware approaches and the EDK2 dispatch architecture remains essential knowledge for anyone working at the firmware level.

#firmware #uefi #edk2 #smm #x86 #gdbplus #systemmanagementmode #bios