PCIe Chapter 35: Expansion ROMs and the Boot Path
An Expansion ROM can provide device initialization or boot code. Use Base 6.0 for address decoding, then Firmware 3.3 for image structure and selection. Keep the two sources and their revisions distinct.
- ROM
- Read-Only Memory
- ROM
- Read-Only Memory
Check both decode controls
Base Figure 7-13/Table 7-10 requires a valid base and both ROM Enable and Memory Space Enable for ordinary ROM BAR decoding. VFs do not implement this BAR. Some implementations can share decoders with other resources, bringing additional restrictions while ROM decode is enabled; this lesson limits the example to reading ROM data.
- BAR
- Base Address Register
Find the accessible ROM from Configuration Space
Teaching assumption: An Endpoint Type 0 function implements a conventional Expansion ROM BAR. Firmware has allocated a 64 KiB window; the register reads D0000001h, and Command.Memory Space Enable is 1. The allocation and register value are illustrative, not device measurements.
In Base 6.0 Figure 7-13, bit 0 is Expansion ROM Enable and bits 31:11 hold the base address. Masking the lower 11 bits gives D0000000h; bit 0 requests decoding via the BAR. Table 7-10 also requires Memory Space Enable to be set before the function claims accesses to the ROM through that BAR.
Next check that the upstream routing covers the allocated range before reading the ROM. Both enables describe the function's decode conditions; routing and a responding device are still needed.
The Type 0 register offset is 30h. For a Type 1 header, Base 6.0 §7.5.1.3.12 places it at 38h. An Enhanced Allocation (EA) ROM entry follows different rules and is outside this example.
Keep pointer bases and length units separate
Firmware 3.3 §5.1.1 and §5.1.2 define the image header's +18h pointer relative to the current image, the Device List Pointer relative to the PCI Data Structure, and Image Length in units of 512 bytes. Device List Pointer is present in revision 3 or later structures. The next example follows two images from one ROM base.
How do we find the second image?
Teaching assumption: Using base D0000000h, the following two valid images have PCI Data Structure revision 3. Table offsets are relative to the ROM base; pointer fields are little-endian.
On a phone, scroll the table sideways to see all columns.
| Observation | First image | Second image |
|---|---|---|
| Image start | 0000h | 0800h |
| Pointer at header +18h | 0030h | 0040h |
| PCI Data Structure location | 0030h | 0840h |
| Image Length | 0004h × 512 = 0800h bytes | 0004h × 512 = 0800h bytes |
| Code Type / Last Image Indicator | 00h / bit 7 = 0 | 03h / bit 7 = 1 |
Firmware 3.3 Figure 5-1 shows the image sequence. Section 5.1.1 locates the first PCI Data Structure: 0000h + 0030h = 0030h, or ROM address D0000030h. Verify PCIR there, then use §5.1.2 to read length and the last-image flag.
The first flag is clear, and its length is 0800h bytes, so the next image begins at 0800h. Its pointer is relative to that image's start: 0800h + 0040h = 0840h, or D0000840h. The second image is also 0800h bytes long and ends at ROM offset 1000h (exclusive). Its bit 7 is set, ending the walk.
For each image, check the 55h AAh header, a nonzero usable pointer, DWORD alignment and placement in the first 64 KiB, then PCIR. A safe parser also checks the available data, forward progress, and bounds.
Code Type 03h denotes UEFI; the Device List Pointer must be zero in a revision 3 structure. After finding a matching type, Firmware 3.3 §5.2 also describes Vendor ID, Device ID and applicable image checks. Code Type alone establishes neither platform compatibility nor trust.
- UEFI
- Unified Extensible Firmware Interface
Separate structure from trust
55h/AAh and PCIR are structural signatures. Base 6.0 ROM Validation separately describes validity, trust tests, warnings, and failures; encoding 010b explicitly means valid contents without a trust test. Firmware 3.3 section 5 also says expansion ROM code is copied to RAM rather than executed in place. This lesson demonstrates offline structure interpretation only.
How should hardware validation status be read?
Return to Base 6.0 Table 7-10 and read Expansion ROM Validation Status, bits 3:1. Hardware validation is optional. Its result is separate from the 55h AAh and PCIR format signatures in Firmware 3.3.
On a phone, scroll the table sideways to see all columns.
| Status | Specified meaning |
|---|---|
000b / 001b | Validation unsupported / in progress. |
010b / 011b | Valid; trust test not performed / valid and trusted. |
100b / 101b | Invalid / valid but untrusted. |
110b / 111b | Passed with implementation-specific warning; trust test not performed / valid and trusted. |
Hardware support for some status encodings is optional. 010b does not report a passed trust test; for 001b, apply the waiting conditions in Table 7-10. Hardware status and a platform decision to load an image are separate checks.
Edition and sources
This chapter uses PCI Express Base Specification Revision 6.0 (6.0-1.0-PUB). ROM contents use PCI Firmware Specification Revision 3.3, which references Base 5.0; each claim retains its own edition. Document and PDF page numbers match. Example configurations and values are author assumptions, not device measurements.
Complete source locations
- Base 6.0 §7.5.1.2.4 Expansion ROM Base Address Register, §7.5.1.3.12 Expansion ROM Base Address Register; pp.932–935,942; Figure 7-13 Expansion ROM Base Address Register; Table 7-10 Expansion ROM Base Address Register
- PCI Firmware 3.3 §5 PCI Expansion ROMs, §5.1 PCI Expansion ROM Contents, §5.1.1 PCI Expansion ROM Header Format, §5.1.2 PCI Data Structure Format, §5.1.3 Device List Format, §5.2 Firmware Power-on Self Test (POST) Firmware; pp.98–104; Figure 5-1 PCI Expansion ROM Structure; Table 5-1 Device List Table


Comments