引言

BIOS是一組固化到計(jì)算機(jī)主板上一個(gè)ROM芯片中的程 序，它保存著計(jì)算機(jī)最重要的基本輸入輸出的程序、系統(tǒng)設(shè) 計(jì)信息、開機(jī)后自檢程序和系統(tǒng)自啟動(dòng)程序。人們經(jīng)常需要重 新對FLASH芯片進(jìn)行編程以便升級(jí)BIOS，以便獲得新的功能。

UEFI BIOS是目前最主流的一個(gè)BIOS架構(gòu)，約占超過 70%的計(jì)算機(jī)，服務(wù)器和嵌入式市場。它是對老的BIOS開 發(fā)模式的一種徹底的革新，打破了 BIOS只能用匯編語言開發(fā) 和只能應(yīng)用在計(jì)算機(jī)和服務(wù)器市場的局限性，當(dāng)前越來越多的 嵌入式設(shè)備、平板、手持設(shè)備、工控設(shè)備、通信設(shè)備等都在 它的應(yīng)用行列。

采用UEFI BIOS開發(fā)架構(gòu)EDKII的架構(gòu)，可保證同一份 核心代碼運(yùn)行在不同的硬件平臺(tái)之上，僅僅需要針對平臺(tái)的特 定性來設(shè)置一些特定的參數(shù)，這是EDKII架構(gòu)中最難也是最 核心的一個(gè)設(shè)計(jì)部分，也就是要研究全局配置數(shù)據(jù)庫PCD。

1 UEFI 和 EDKII 簡介

2000 年，Intel 向 業(yè)界展 示了 BIOS 的 新 一 代 接口程序 EFI（Extensible FirmwareInterface），并將此技術(shù)應(yīng)用于其安騰服務(wù)器平臺(tái)上。EFI 是由Intel 推出的一種在未來的電腦系統(tǒng)中用來替代 BIOS 的升級(jí)方案。2005 年，在工業(yè)界達(dá)成共識(shí)的基礎(chǔ)上，Intel 將 EFI 規(guī)范交給了一個(gè)由微軟、AMD、惠普等公司共同參與的工業(yè)聯(lián)盟進(jìn)行管理，并將實(shí)現(xiàn)該規(guī)范的核心代碼開源于網(wǎng)站上。與此同時(shí)，EFI 也正式更名為 UEFI（Unified Extensible FirmwareInterface）。UEFI 聯(lián)盟將負(fù)責(zé)開發(fā)、管理和推廣 UEFI 規(guī)范。

UEFI 定義了操作系統(tǒng)與系統(tǒng)硬件平臺(tái)固件之間的開放接口。該規(guī)范定義的接口包括平臺(tái)相關(guān)信息、啟動(dòng)服務(wù)例程以及操作系統(tǒng)運(yùn)行時(shí)服務(wù)例程。操作系統(tǒng)裝載器與操作系統(tǒng)可通過接口調(diào)用這些服務(wù)例程。UEFI 規(guī)范是一個(gè)公開的純接口定義，它不依賴于某個(gè)特定的 BIOS 制造商或某個(gè)特定的 BIOS的實(shí)現(xiàn)，它僅僅定義了平臺(tái)固件必須實(shí)現(xiàn)的接口，以及操作系統(tǒng)可能使用的一系列接口與數(shù)據(jù)結(jié)構(gòu)，其實(shí)現(xiàn)的方式與細(xì)節(jié)均取決于該規(guī)范的實(shí)現(xiàn)者。UEFI 規(guī)范還定義了固件驅(qū)動(dòng)程序模型，使得所有遵循此模型開發(fā)的固件驅(qū)動(dòng)程序能夠互相協(xié)作。

不同于傳統(tǒng)的 BIOS 實(shí)現(xiàn)，EDKII 基于現(xiàn)代軟件體系設(shè)計(jì)的思想，對 UEFI Framework 采用模塊化設(shè)計(jì)，并根據(jù)其執(zhí)行流程主要?jiǎng)澐譃?：SEC、PEI、DXE、BDS、TSL、RT 和AL 等 7 個(gè)階段，其運(yùn)行機(jī)理如圖 1 所示。

SEC（Security）是平臺(tái)上電后最先執(zhí)行的步驟。這個(gè)階段的主要目的是對平臺(tái)固件進(jìn)行驗(yàn)證，確保選擇的平臺(tái)固件映 像沒有被破壞。主要工作是初始化臨時(shí)內(nèi)存區(qū)并對平臺(tái)早期初 始化代碼進(jìn)行驗(yàn)證。

PEI (Pre-EFI Initialization)階段有兩個(gè)主要任務(wù)：確定 重新啟動(dòng)的來源和做盡可能少的工作以便尋找和初始化內(nèi)存, 為DXE階段提供少量的固定內(nèi)存。

DXE (Driver Execution Environment)被設(shè)計(jì)來處理與外 圍設(shè)備的通信，它通過加載驅(qū)動(dòng)的方式(輪詢檢測)來為操作 系統(tǒng)的啟動(dòng)管理構(gòu)建環(huán)境。

BDS (Boot Device Selection)是 UEFI 擁有平臺(tái)控制權(quán) 的最后一個(gè)階段。BDS與DXE階段一起工作，為啟動(dòng)操作系 統(tǒng)建立控制臺(tái)。

TSL (Transient System Load)即操作系統(tǒng)啟動(dòng)管理器嘗 試引導(dǎo)操作系統(tǒng)的階段。

RT (Run Time)是操作系統(tǒng)啟動(dòng)運(yùn)行后，UEFI提供的 一組運(yùn)行時(shí)服務(wù)。

AL (After Life)階段，即最后一個(gè)階段，其提供一種機(jī) 制來保證用戶在有意或者無意的情況下終止操作系統(tǒng)后，讓 UEFI重新獲得系統(tǒng)控制權(quán)。

2全局配置數(shù)據(jù)庫PCD的設(shè)計(jì)實(shí)現(xiàn)

EDKII中PCD根據(jù)其作用的時(shí)間，分兩大類，一類 是在編譯過程中起作用，這類PCD等同于C語言中的全局 靜態(tài)變量，包含 FeatureFlag PCD，F(xiàn)ixedAtBuild PCD 以及 PatchableInModule PCD三種。這類PCD跟全局配置數(shù)據(jù)庫 沒有關(guān)系，所以本文不做過多介紹。另一類是平臺(tái)初始化過 程中起作用，包括 DynamicDefault PCD，DynamicHII PCD， 和DynamicVpd PC三種應(yīng)用在源代碼組件發(fā)布的PCD，以及 與之對應(yīng)的 DynamicExDefault PCD，DynamicExHII PCD 和 DynamicExVpd PCD――專門應(yīng)用在編譯好的二進(jìn)制組件發(fā)布 中的三種PCD。

2.1 PCD的分類和區(qū)別

從大面上，全局配置數(shù)據(jù)庫中存放的PCD被分為兩個(gè)大 類Dynamic和DynamicEx,每個(gè)大類又各分三個(gè)小類Default PCD，HII PCD 和 VPD PCD。

Dynamic和DynamicEx的作用局域完全一樣，唯一的區(qū) 別就是源代碼級(jí)別的發(fā)布還是編譯好的代碼發(fā)布。如果上層開 發(fā)者給二級(jí)開發(fā)者提供的是所有驅(qū)動(dòng)的源代碼，那么二級(jí)開 發(fā)者可以直接修改源代碼來改變某個(gè)參數(shù)的值，此時(shí)只要把 該配置參數(shù)設(shè)置為Dynamic形式的即可滿足要求。否則，必 須用DynamicEx的。DynamicEx的PCD在保護(hù)上層開發(fā)者 的版權(quán)和代碼發(fā)布權(quán)限提供了更多層次的選擇空間。

Default PCD :在初始化過程中，可以被PEI，DXE和 RT階段的幾乎所有驅(qū)動(dòng)所使用，一般是前面的驅(qū)動(dòng)修改，后 面的驅(qū)動(dòng)讀取。這是不同的驅(qū)動(dòng)，不同的階段之間有效信息交 互和傳遞的一種方法。該P(yáng)CD的作用空間是一次加電過程, 所修改的數(shù)值在系統(tǒng)斷電后會(huì)自動(dòng)回復(fù)到默認(rèn)初始狀態(tài)。

HII PCD :作用空間和Default PCD 一樣，主要的區(qū)別是 HII的PCD可以把修改的數(shù)值直接保存到BIOS NOR Flash芯 片的NVRAM區(qū)域。這樣一旦修改,再計(jì)算機(jī)下次啟動(dòng)的時(shí)候, 訪問的就是上次修改的新數(shù)值。

VPD PCD :作用空間和上面兩種相同，主要區(qū)別是VPD PCD是只讀的不能修改，但是它也有自己的優(yōu)勢。因?yàn)閂PD PCD是的初始值是保存在BIOS固件的一段二進(jìn)制數(shù)據(jù)空間 上的所以在固件編譯完成后，可以在不依賴編譯器重新編譯 情況下，對該P(yáng)CD的數(shù)值進(jìn)行直接的重復(fù)設(shè)置。

2.2設(shè)計(jì)原理分析

在EDKII源代碼編譯中，編譯工具集的AutoGen會(huì) 遍歷整個(gè)平臺(tái)所有驅(qū)動(dòng)和頂層結(jié)構(gòu)文件生成AutoGen.h和 AutoGen.c兩個(gè)關(guān)鍵文件。這兩個(gè)文件將作為后面C編譯器的 自動(dòng)包換的頭文件輸入，參與C語言的系統(tǒng)級(jí)編譯過程，最 終生成這個(gè)平臺(tái)的全局配置數(shù)據(jù)庫。

下面通過一個(gè)NT32模擬平臺(tái)中的例子來進(jìn)行過程說明。

首先在NT32的頂層平臺(tái)文件DEC, DSC和INF文件中 依次做如下聲明。

MdeModulePkg.dec

[PcdsFixedAtBuild, PcdsDynamic, PcdsDynamicEx]

gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariabl eBase|0x0|UINT32|0x30000001

Nt32Pkg.dsc

[PcdsDynamicExDefault.common.DEFAULT]

gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariabl eBase|0xf000

WinNtFlashMapPei.inf

[Pcd]

gEfiNt32PkgTokenSpaceGuid.PcdWinNtFlashNvStorageVariable

Base

通過該聲明，定義了一個(gè)DynamicExDefault類型的 PCD,其類型為UINT32,初始默認(rèn)數(shù)值為0xf000,并且驅(qū) 動(dòng)模塊WinNtFlashMapPei要使用該配置數(shù)據(jù)。

接著用EDKII的BaseTools對該源代碼架構(gòu)進(jìn)行編譯, AutoGen工具會(huì)在遍歷完整個(gè)代碼之后，在相應(yīng)的PCD驅(qū)動(dòng) 編譯目錄下面自動(dòng)生成AutoGen.h和AutoGen.c兩個(gè)文件，如下所示：

Aut oGe n.h （Bu ild \ NT32\ DEBUG_MYTOOLS\I A32\

MdeModulePkg\Universal\PCD\Pei\Pcd\DEBUG）

#define PEI_LOCAL_TOKEN_NUMBER_TABLE_SIZE 3

TOC \o "1-5" \h \z

typedef struct {

UINT32PcdFlashNvStorageVariableBase_a1aff049_

fdeb_442a_b320_13ab4cb72bbc[1]；

DYNAMICEX_MAPPING ExMapTable[PEI_EXMAPPING_ TABLE_SIZE]；

UINT32LocalTokenNumberTable[PEI_LOCAL_

TOKEN_NUMBER_TABLE_SIZE]；

GUIDGuidTable[PEI_GUID_TABLE_SIZE]；

UINT8StringTable[1] ； /* _ */

SIZE_INFO SizeTable[PEI_SIZE_TABLE_SIZE]；

UINT8SkuIdTable[PEI_SKUID_TABLE_SIZE]；

SKU_ID SystemSkuId ；

} PEI_PCD_DATABASE_INIT ；

AutoGen.c (Build\NT32\DEBUG_MYTOOLS\IA32\

MdeModulePkg\Universal\PCD\Pei\Pcd\DEBUG)

PEI_PCD_DATABASE_INIT gPEIPcdDbInit = {

{ OxfOOOU ), /* PcdFlashNvStorageVariableBase_a1aff049_ fdeb_442a_b320_13ab4cb72bbc[1] */

/* ExMapTable */ {{ 0x30000001U, 2U, 0U }, },

/* LocalTokenNumberTable */

{

offsetof( PEI_PCD_DATABASE , Uninit. PcdFlashNvStorageFtwSpareBase_a1aff049_fdeb_442a_ b320_13ab4cb72bbc) | PCD_TYPE_DATA | PCD_DATUM_ TYPE_UINT32,

offsetof ( PEI_PCD_DATABASE , Init. PcdFlashNvStorageVariableBase_a1aff049_fdeb_442a_ b320_13ab4cb72bbc) | PCD_TYPE_DATA | PCD_DATUM_ TYPE_UINT32,

},

/* GuidTable */

{{ 0xA1AFF049, OxFDEB, 0x442a, { 0xB3, 0x20, 0x13, 0xAB, 0x4C, 0xB7, 0x2B, 0xBC }}, },

//gEfiMdeModulePkgTokenSpaceGuid

/* StringTable */ /* SizeTable *//* SkuIdTable */

};

AutoGen.h自動(dòng)生成的是該數(shù)據(jù)庫的結(jié)構(gòu)定義文件，它 定義了各個(gè)PCD在該數(shù)據(jù)庫中存放的數(shù)據(jù)位置、類型、偏移 量等信息。AutoGen.c則配合AutoGen.h詳細(xì)列出了各個(gè)比特 位置存放的具體數(shù)值。

當(dāng)WinNtFlashMapPei驅(qū)動(dòng)模塊中想要訪問該P(yáng)CD數(shù)值

的時(shí)候，只需要在C語言中引用PcdGet32Ex (gEfiMdeModul ePkgTokenSpaceGuid, 0x30000001)。這時(shí)就會(huì)自動(dòng)掃描 Init. ExMapTable和Init.GuidTable兩張數(shù)據(jù)庫表取得該P(yáng)CD對應(yīng) 的 LocalTokenNumber 數(shù)值"2U"。

而后根據(jù)映射LocalTokenNumber的數(shù)值 找 到“ offsetof ( PEI_PCD_DATABASE , Init. PcdFlashNvStorageVariableBase_a1aff049_fdeb_442a_ b320_13ab4cb72bbc) | PCD_TYPE_DATA | PCD_DATUM_ TYPE_UINT32"。

通過在 C 語言中解析 “offsetof (PEI_PCD_DATABASE, Init.PcdFlashNvStorageVariableBase_a1aff049_fdeb_442a_ b320_13ab4cb72bbc) | PCD_TYPE_DATA | PCD_DATUM_ TYPE_UINT32"的定義，就可以得到該P(yáng)CD在數(shù)據(jù)庫中的 偏移量、PCD類型和數(shù)據(jù)類型信息。

其過程如圖 2 所示 ：

3設(shè)計(jì)局限性和改進(jìn)方法

在該數(shù)據(jù)庫生成過程中，離不開對MS, ICC或者GCC 編譯器的支持，這樣DynamicEx所宣稱的二進(jìn)制固件發(fā)布模 式受到約束。換言之，想要完全的二進(jìn)制驅(qū)動(dòng)組件的發(fā)布，必 須讓EDKII整個(gè)平臺(tái)PCD的生成過程脫離對任何編譯器的 依賴性。

針對這個(gè)設(shè)計(jì)要求，提出了新的設(shè)計(jì)架構(gòu)，其流程圖如圖3 所示 ：

在新的架構(gòu)中，主要改變的是AutoGen的組件，EDKII 的編譯工具集依然會(huì)遍歷整個(gè)架構(gòu)的所有驅(qū)動(dòng)和上層配置 文件，但它會(huì)直接生成PCD數(shù)據(jù)庫，同時(shí)生成一份包含改 數(shù)據(jù)庫結(jié)構(gòu)的AutoGen.h文件和一份空的只包含注釋信息AutoGen.c 文件。AutoGen.h 和 AutoGen.c 依然采用 PEI/DXE驅(qū)動(dòng)的源代碼編譯，只不過 PCD 數(shù)據(jù)庫不在依賴該過程產(chǎn)生，因此稍加改動(dòng)，就可使 DynamicEx 真正發(fā)揮其所宣稱的作用。

4 結(jié) 語

EDKII 的 PCB 數(shù)據(jù)庫目前在國內(nèi)沒有任何論文研究發(fā)表過，本文主要針對這個(gè)空白領(lǐng)域，分析和研究了 EDKII 最核心、最關(guān)鍵的全局?jǐn)?shù)據(jù)設(shè)置數(shù)據(jù)庫 PCD 的設(shè)計(jì)和實(shí)現(xiàn)，并指出了其設(shè)計(jì)的不足。隨著 UEFI BIOS 的廣泛應(yīng)用，越來越多的軍用板卡、通信主板、嵌入式設(shè)備和服務(wù)器也會(huì)轉(zhuǎn)移到這個(gè)架構(gòu)上。如果用一個(gè)穩(wěn)定不變的核心代碼來支持不同的設(shè)備，必然會(huì)減少維護(hù)成本，提高開發(fā)效率，以及提高設(shè)備的質(zhì)量，這就是本文所研究的 PCD 技術(shù)的意義所在。

20211223_61c35c0e24e78__UEFI