PCIe Chapter 35：Expansion ROM 與開機路徑

ROM Enable=1，就一定能讀到 ROM 嗎？

先看Base Figure 7-13／Table 7-10。普通ROM BAR的基址須有效，Memory Space Enable具有優先控制；兩個Enable都設好才解碼。VF不支援這個ROM BAR，須硬接為0；虛擬化中介是否模擬PF的ROM另有分工。

BAR

Base Address Register，基底位址暫存器

VF

Virtual Function，虛擬功能

PF

Physical Function，實體功能

Base同時允許部分實作共用ROM與其他資源的解碼器，因此ROM啟用時還有不得存取其他BAR的限制及例外。這裡先限定只讀ROM資料，完整裝置操作仍須保留原文條件。

先從 Configuration Space 找到可讀的 ROM

教學假設：某 Endpoint 的 Type 0 Function 實作一般 Expansion ROM BAR（擴充 ROM 基底位址暫存器）；韌體已為它配置 64 KiB 的位址區間，讀到 D0000001h，Command Register 的 Memory Space Enable 也為 1。這些是示範用的配置與讀值，並非實機測量。

先看 Base 6.0 Figure 7-13：bit 0 是 Expansion ROM Enable，bits 31:11 是位址欄位。把低 11 bits 遮掉後，範例的 ROM 基底位址是 D0000000h；bit 0 為 1 代表要求透過此 BAR 解碼。Table 7-10 還要求 Memory Space Enable 為 1，Function 才會接受透過此 BAR 指向 ROM 的存取。

下一步確認上游路由可涵蓋這段已配置的位址，再從 ROM 基底開始讀內容。兩個 Enable 均為 1 只解決 Function 的解碼條件；仍需路由正確、裝置可回應，才能讀到映像。

本例採 Type 0 Header，ROM Register 位於 Configuration Space 的 30h。若是 Type 1 Header，先改讀 Base 6.0 §7.5.1.3.12，位址是 38h。若 Function 的 Enhanced Allocation（EA，增強資源配置）含 ROM entry，則須另依 EA 規則處理，不能沿用本例。

指標有兩種基準，要怎麼避免讀偏？

讀取映像前，先分清楚每個指標的起算位置。Firmware 3.3 §5.1.1 與 §5.1.2 定義下列欄位；Device List Pointer 適用於 Revision 3 或更新的 PCI Data Structure。

下面的雙映像案例會用同一個 ROM 基底，示範如何依序讀取指標、長度與最後映像旗標。

一個 ROM 有兩個映像時，怎麼找到第二個？

教學假設：沿用基底 D0000000h；下表是作者建立的兩個有效映像，PCI Data Structure 的版本均為 3。偏移量均以 ROM 基底為零點，指標欄位本身則使用 little-endian（低位元組在前）編碼。

手機閱讀時，可左右滑動表格查看完整內容。

先從 Firmware 3.3 Figure 5-1 看到映像串接的關係，再用 §5.1.1 讀第一個映像的 +18h：0000h + 0030h = 0030h。在 ROM 位址空間，這對應 D0000030h。該處應有 PCIR 簽章；接著用 §5.1.2 讀長度與最後映像旗標。

第一個映像的旗標為 0，長度是 0800h bytes，因此下一個映像從 0800h 開始。第二個映像的指標相對於第二個映像起點：0800h + 0040h = 0840h，對應 D0000840h。第二個映像的長度同樣是 0800h bytes，結束位置為 ROM 偏移 1000h（不含該位置）。它的 bit 7 為 1，走訪到此結束。

每次走訪都先確認映像標頭的 55h AAh、指標非零且位置可用、PCI Data Structure 在映像前 64 KiB 內且 DWORD 對齊，並核對 PCIR。解析器也需要檢查資料是否完整、長度是否足以推進及是否超出已取得的範圍；這些是安全解析所需的邊界檢查。

第二個映像的 Code Type 03h 表示 UEFI 類型；在 Revision 3 結構中，Device List Pointer 須為零。找到類型相符的映像後，還要依 Firmware 3.3 §5.2 檢查 Vendor ID、Device ID 與適用的映像條件。Code Type 不會單獨證明映像適合目前機器或已通過平台信任政策。

UEFI

Unified Extensible Firmware Interface，統一可延伸韌體介面

ROM 有正確簽章，是否就通過信任檢查？

55h／AAh與PCIR是結構簽章，用來定位與辨識格式。Base 6.0的Expansion ROM Validation另分有效內容、已做信任測試，以及警告／失敗等狀態；p.934的010b明確表示內容有效，但未執行信任測試。

因此，格式符合、內容完整與平台信任必須分開記錄。讀完內容也不表示直接從ROM執行；Firmware 3.3 §5說明PCI Expansion ROM程式會先複製到RAM，再初始化／執行。本章只示範離線結構判讀。

如何讀硬體回報的驗證結果？

回到 Base 6.0 Table 7-10，讀 Expansion ROM Validation Status（ROM 驗證狀態，bits 3:1）。此功能是可選的；狀態描述硬體驗證結果，與 Firmware 3.3 的 55h AAh、PCIR 格式簽章是不同資訊。

手機閱讀時，可左右滑動表格查看完整內容。

硬體可選擇不回報部分狀態編碼。若讀到 010b，不能把尚未執行的信任測試視為通過；若狀態仍為 001b，則依 Table 7-10 的條件處理等待。驗證狀態與平台是否允許載入映像，仍是兩個要分開確認的問題。

版本與來源

本章以 PCI Express Base Specification Revision 6.0（6.0-1.0-PUB）為準，ROM內容另依PCI Firmware Specification Revision 3.3；該版參考Base 5.0，本文逐項保留版本。文件頁與 PDF 頁相同。案例的配置與讀值均為作者假設，並非實機測量。