UEFI Platform Integration Specification, version 1.7 Errata A

1 簡(jiǎn)介

1.1 概述

該規(guī)范定義了實(shí)現(xiàn)平臺(tái)初始化 (PI) 規(guī)范（以下簡(jiǎn)稱“PI 架構(gòu)”）的 Pre-EFI 初始化 (PEI) 階段所需的核心代碼和服務(wù)。

此 PEI 核心接口規(guī)范 (CIS) 執(zhí)行以下操作：

• 描述 PEI 階段的基本組件
• 為 UEFI PI 工作組 (PIWG) 在架構(gòu)上要求的服務(wù)和功能提供代碼定義
• 描述固件執(zhí)行的后續(xù)階段所需的機(jī)器準(zhǔn)備
• 討論描述系統(tǒng)重啟類型的狀態(tài)變量

有關(guān)更多信息，請(qǐng)參閱下面的“PEI CIS 的組織”。

1.2 PEI CIS 的組織

該 PEI 核心接口規(guī)范的組織方式如表 1-1 所示。
由于 PEI Foundation 只是基于 PI 架構(gòu)的固件解決方案的一個(gè)組件，因此本文檔中引用了許多其他規(guī)范。

Table 1-1: Organization of the PEI CIS

1.3 本文檔中使用的約定

本文檔使用下面描述的排版和說(shuō)明約定。

1.3.1 數(shù)據(jù)結(jié)構(gòu)描述

支持的處理器是“l(fā)ittle endian”機(jī)器。
這種區(qū)別意味著內(nèi)存中多字節(jié)數(shù)據(jù)項(xiàng)的低位字節(jié)位于最低地址，而高位字節(jié)位于最高地址。
一些支持的處理器可能被配置為“小端”和“大端”操作。
所有設(shè)計(jì)為符合本規(guī)范的實(shí)現(xiàn)都將使用“小端”操作。
在一些內(nèi)存布局描述中，某些字段被標(biāo)記為保留。
軟件必須將這些字段初始化為零并在讀取時(shí)忽略它們。
在更新操作中，軟件必須保留任何保留字段。

本文檔中描述的數(shù)據(jù)結(jié)構(gòu)一般采用以下格式：

結(jié)構(gòu)名稱：數(shù)據(jù)結(jié)構(gòu)的正式名稱。
摘要：數(shù)據(jù)結(jié)構(gòu)的簡(jiǎn)要說(shuō)明。
原型：數(shù)據(jù)結(jié)構(gòu)的“C 風(fēng)格”類型聲明。
參數(shù)：數(shù)據(jù)結(jié)構(gòu)原型中每個(gè)字段的簡(jiǎn)要說(shuō)明。
描述：對(duì)數(shù)據(jù)結(jié)構(gòu)提供的功能的描述，包括調(diào)用者應(yīng)該注意的任何限制和注意事項(xiàng)。
相關(guān)定義：僅由該數(shù)據(jù)結(jié)構(gòu)使用的類型聲明和常量。

1.3.2 程序說(shuō)明

本文檔中描述的過(guò)程通常采用以下格式：

ProcedureName()：過(guò)程的正式名稱。
摘要：程序的簡(jiǎn)要說(shuō)明。
原型：定義調(diào)用序列的“C 風(fēng)格”過(guò)程頭。
參數(shù)：過(guò)程原型中每個(gè)字段的簡(jiǎn)要說(shuō)明。
描述：對(duì)接口提供的功能的描述，包括調(diào)用者應(yīng)該注意的任何限制和注意事項(xiàng)。
相關(guān)定義：僅由該過(guò)程使用的類型聲明和常量。
返回的狀態(tài)代碼：接口返回的任何代碼的描述。 執(zhí)行此表中列出的任何狀態(tài)代碼都需要該過(guò)程。
可能會(huì)返回額外的錯(cuò)誤代碼，但它們不會(huì)通過(guò)標(biāo)準(zhǔn)一致性測(cè)試進(jìn)行測(cè)試，
并且任何使用該過(guò)程的軟件都不能依賴于實(shí)現(xiàn)可能提供的任何擴(kuò)展錯(cuò)誤代碼。

1.4 Requirements

本文檔是架構(gòu)規(guī)范，是統(tǒng)一 EFI 論壇定義和發(fā)布的平臺(tái)初始化架構(gòu) (PI Architecture) 規(guī)范系列的一部分。
PI 架構(gòu)的主要目的是為可能來(lái)自不同供應(yīng)商的固件組件提供一個(gè)互操作性表面。
因此，符合本規(guī)范的責(zé)任落在作為規(guī)范一部分描述的設(shè)施的生產(chǎn)者和消費(fèi)者身上。

通常，生產(chǎn)者實(shí)現(xiàn)有責(zé)任確保實(shí)現(xiàn)中存在符合要求的消費(fèi)者固件組件可能嘗試使用的任何設(shè)施。
同樣，固件組件的開(kāi)發(fā)人員有責(zé)任確保其實(shí)現(xiàn)僅依賴于定義為 PI 架構(gòu)一部分的設(shè)施。
當(dāng)合規(guī)組件的集合被設(shè)計(jì)為僅使用 PI 體系結(jié)構(gòu)規(guī)范系列中定義的所需設(shè)施時(shí)，可以確保最大的互操作性。

由于本文檔是架構(gòu)規(guī)范，因此已注意以允許生產(chǎn)者和消費(fèi)者在實(shí)現(xiàn)中具有最大靈活性的方式來(lái)指定架構(gòu)。
但是，對(duì)于必須實(shí)現(xiàn)本規(guī)范的哪些元素以確保設(shè)計(jì)用于與此處描述的體系結(jié)構(gòu)接口一起工作的代碼的操作有一致且可預(yù)測(cè)的環(huán)境存在某些要求。

為了描述這些要求，規(guī)范包括必需的設(shè)施，例如接口和數(shù)據(jù)結(jié)構(gòu)，以及標(biāo)記為可選的設(shè)施。

通常，要使實(shí)現(xiàn)符合本規(guī)范，實(shí)現(xiàn)必須包括在所有方面都與作為規(guī)范一部分呈現(xiàn)的所需設(shè)施描述的完整描述相匹配的功能元素。
規(guī)范中沒(méi)有明確標(biāo)記為“可選”的任何部分都被認(rèn)為是必需的設(shè)施。

當(dāng)規(guī)范的某些部分被標(biāo)記為“可選”時(shí)，實(shí)現(xiàn)可以選擇提供匹配元素或?qū)⑺鼈兣懦谕狻?br> 如果一個(gè)元素是由一個(gè)設(shè)施的實(shí)現(xiàn)提供的，那么它必須在所有方面都與相應(yīng)的完整描述相匹配。

實(shí)際上，這意味著對(duì)于規(guī)范中涵蓋的任何設(shè)施，實(shí)現(xiàn)的任何實(shí)例只有在完全準(zhǔn)確地遵循規(guī)范描述的情況下才能聲稱符合。
這并不排除提供超出規(guī)范中描述的附加功能的實(shí)現(xiàn)。
此外，它不排除實(shí)現(xiàn)省略在規(guī)范中標(biāo)記為可選的設(shè)施

因此，設(shè)計(jì)用于在符合 PI 架構(gòu)的實(shí)現(xiàn)中運(yùn)行的固件的模塊化組件僅在它們僅依賴于本規(guī)范和相關(guān) PI 架構(gòu)規(guī)范中描述的設(shè)施時(shí)才符合要求。
換句話說(shuō)，任何沒(méi)有任何超出 PI 架構(gòu)規(guī)范范圍的外部依賴性的模塊化組件都是符合要求的。
如果模塊化組件依賴于對(duì)接口或數(shù)據(jù)結(jié)構(gòu)的引用進(jìn)行正確和完整的操作，
而該接口或數(shù)據(jù)結(jié)構(gòu)既不是其自身映像的一部分，也不是任何 PI 架構(gòu)規(guī)范中描述的，那么它就是不符合標(biāo)準(zhǔn)的。

在某些所需設(shè)施不存在的情況下，可以對(duì)規(guī)范進(jìn)行部分實(shí)現(xiàn)。
這樣的實(shí)現(xiàn)是不符合標(biāo)準(zhǔn)的，并且本身符合標(biāo)準(zhǔn)的其他固件組件可能無(wú)法正確運(yùn)行。
不符合要求的實(shí)現(xiàn)的正確操作明確超出了 PI 架構(gòu)和本規(guī)范的范圍。

1.5 本文檔中使用的約定

1.5.1 數(shù)字格式

在本標(biāo)準(zhǔn)中，二進(jìn)制數(shù)由任何僅由西方阿拉伯?dāng)?shù)字 0 和 1 后跟小寫(xiě) b（例如 0101b）組成的數(shù)字序列表示。
可以在二進(jìn)制數(shù)表示中的字符之間包含下劃線或空格以提高可讀性或描繪字段邊界（例如，0 0101 1010b 或 0_0101_1010b）

在本標(biāo)準(zhǔn)中，十六進(jìn)制數(shù)在任何僅由西方阿拉伯?dāng)?shù)字 0 到 9 和/或大寫(xiě)英文字母 A 到 F（例如，0xFA23）組成的數(shù)字序列之前用 0x 表示。
可以在十六進(jìn)制數(shù)字表示的字符之間包含下劃線或空格，以提高可讀性或描繪字段邊界（例如，0xBFD8C FA23 或 0xB_FD8C_FA23）

在本標(biāo)準(zhǔn)中，十進(jìn)制數(shù)由任何僅由阿拉伯?dāng)?shù)字 0 到 9 組成的數(shù)字序列表示，后面沒(méi)有緊跟小寫(xiě) b 或小寫(xiě) h（例如，25）。

本標(biāo)準(zhǔn)使用以下約定來(lái)表示十進(jìn)制數(shù)：

• 小數(shù)分隔符（即，分隔數(shù)字的整數(shù)部分和小數(shù)部分）是句點(diǎn)；
• 千位分隔符（即，在數(shù)字的一部分中分隔三位數(shù)字組）是一個(gè)逗號(hào)；
• 千位分隔符用于整數(shù)部分，不用于數(shù)字的小數(shù)部分

1.5.2 Binary prefixes

2 Overview

PI 體系結(jié)構(gòu)規(guī)范（以下稱為“PI 體系結(jié)構(gòu)”）的預(yù) EFI 初始化 (PEI) 階段在啟動(dòng)流程的早期被調(diào)用。
具體來(lái)說(shuō)，在安全 (SEC) 階段進(jìn)行一些初步處理后，任何機(jī)器重啟事件都會(huì)調(diào)用 PEI 階段。
PEI 階段最初將與處于新生狀態(tài)（nascent state）的平臺(tái)一起運(yùn)行，僅利用處理器上的資源（例如作為調(diào)用堆棧的處理器緩存）來(lái)調(diào)度 Pre-EFI 初始化模塊 (PEIM)。
這些 PEIM 負(fù)責(zé)以下內(nèi)容：

• 初始化一些持久化內(nèi)存補(bǔ)充
• 描述 Hand-Off Blocks (HOB) 中的內(nèi)存
• 描述 HOB 中的固件卷位置(FV)
• 將控制傳遞到驅(qū)動(dòng)程序執(zhí)行環(huán)境 (DXE) 階段

從設(shè)計(jì)角度來(lái)說(shuō)，PEI 階段旨在成為實(shí)現(xiàn)上述目的的最少量代碼。
因此，任何更復(fù)雜的算法或處理都應(yīng)推遲到 DXE 執(zhí)行階段。

PEI 階段還負(fù)責(zé)危機(jī)恢復(fù)(crisis recovery)和從 S3 睡眠狀態(tài)恢復(fù)。
對(duì)于危機(jī)恢復(fù)，PEI 階段應(yīng)該駐留在固件存儲(chǔ)的一些小的、容錯(cuò)的塊中。
因此，必須使 PEI 階段的占用空間盡可能小。

此外，對(duì)于成功的 S3 恢復(fù)而言，恢復(fù)的速度至關(guān)重要，因此應(yīng)盡量減少通過(guò)固件的代碼路徑。
這兩個(gè)引導(dǎo)流程還說(shuō)明需要將 PEI 階段的處理和代碼路徑保持在最低限度。

PEI 階段的實(shí)現(xiàn)比任何其他階段都更依賴于處理器架構(gòu)。
特別是，處理器在其初始或接近初始狀態(tài)提供的資源越多，PEI Foundation 和 PEIM 之間的接口就越豐富。
因此，以下討論的幾個(gè)部分說(shuō)明了對(duì)體系結(jié)構(gòu)的要求，但在其他方面與體系結(jié)構(gòu)相關(guān)。

2.2 Design Goals

PI 架構(gòu)需要 PEI 階段來(lái)配置系統(tǒng)以滿足 PI 架構(gòu)架構(gòu)的驅(qū)動(dòng)程序執(zhí)行環(huán)境 (DXE) 階段的最低先決條件。
通常，需要 PEI 階段來(lái)初始化一個(gè)足夠大的線性 RAM 陣列，以便成功執(zhí)行 DXE 階段元素。

PEI 階段提供了一個(gè)框架，允許供應(yīng)商為每個(gè)功能不同的系統(tǒng)硬件提供單獨(dú)的初始化模塊，
這些模塊必須在 PI 架構(gòu)中的 DXE 執(zhí)行階段之前進(jìn)行初始化。

PEI 階段提供了一個(gè)通用框架，通過(guò)該框架可以獨(dú)立設(shè)計(jì)、開(kāi)發(fā)和更新單獨(dú)的初始化模塊。
PEI 階段的開(kāi)發(fā)是為了滿足 PI 架構(gòu)中的以下目標(biāo)：

• 維護(hù)“信任鏈”。 這包括防止對(duì) PEI 階段或其模塊進(jìn)行未經(jīng)授權(quán)的更新，以及在 PEI 階段對(duì) PEI Foundation 及其模塊進(jìn)行認(rèn)證。
• 提供核心 PEI 模塊（PEI Foundation），該模塊對(duì)于特定處理器架構(gòu)或多或少保持不變，但將支持來(lái)自不同供應(yīng)商的插件模塊，特別是處理器、芯片組、RAM 初始化等。
• 允許獨(dú)立開(kāi)發(fā)早期初始化模塊。

2.3 Pre-EFI Initialization (PEI) Phase

PI 架構(gòu)兼容引導(dǎo)的預(yù) EFI 初始化 (PEI) 階段的設(shè)計(jì)本質(zhì)上是 PI 架構(gòu)的 DXE 階段的微型版本，并解決了許多相同的問(wèn)題。
PEI 階段設(shè)計(jì)為分幾個(gè)部分進(jìn)行開(kāi)發(fā)。PEI 階段包括以下內(nèi)容：

• 一些稱為 PEI Foundation 的核心代碼
• 稱為 Pre-EFI 初始化模塊 (PEIM) 的專用插件

與 DXE 不同，PEI 階段不能假設(shè)有合理數(shù)量的 RAM，因此 DXE 中的豐富功能在 PEI 中不存在。
PEI 階段將其支持限制為以下操作：

• 定位、驗(yàn)證和調(diào)度 PEIM
• 促進(jìn) PEIM 之間的通信
• 向后續(xù)階段提供移交數(shù)據(jù)

下面顯示了在 PEI 階段完成的過(guò)程:

PEI-operations-diagram.png

2.4 PEI Services

PEI Foundation 建立了一個(gè)名為 PEI Services Table 的系統(tǒng)表，
該表對(duì)系統(tǒng)中的所有預(yù) EFI 初始化模塊 (PEIM) 可見(jiàn)。
PEI 服務(wù)被定義為 PEI Foundation 在滿足該服務(wù)的初始化要求時(shí)表現(xiàn)出來(lái)的功能、命令或其他能力。
由于 PEI 階段在接近結(jié)束時(shí)沒(méi)有永久內(nèi)存可用，因此在 PEI 階段創(chuàng)建的服務(wù)范圍不會(huì)像在后期階段創(chuàng)建的那樣豐富。
由于 PEI Foundation 及其臨時(shí) RAM 的位置在構(gòu)建時(shí)未知，
指向 PEI 服務(wù)表的指針被傳遞到每個(gè) PEIM 的入口點(diǎn)以及每個(gè) PEIM 到 PEIM 接口 (PPI) 的一部分。

PEI 基礎(chǔ)服務(wù)類

2.5 PEI Foundation

PEI Foundation 是負(fù)責(zé)以下事項(xiàng)的實(shí)體：

• 成功調(diào)度 EFI 前初始化模塊 (PEIM)
• 維持引導(dǎo)模式
• 初始化永久內(nèi)存
• 調(diào)用驅(qū)動(dòng)程序執(zhí)行環(huán)境 (DXE) 加載程序

PEI Foundation 被寫(xiě)入為可在給定指令集架構(gòu)的所有平臺(tái)上移植。
因此，32 位英特爾 ? 架構(gòu) (IA-32) 的二進(jìn)制文件應(yīng)適用于所有奔騰 ? 處理器，從采用 MMX? 技術(shù)的奔騰 II 處理器到最新的奔騰 4 處理器。
同樣，用于 Itanium? 處理器系列的 PEI Foundation 二進(jìn)制文件應(yīng)適用于所有 Itanium 處理器。
無(wú)論處理器微架構(gòu)如何，PEI Foundation 公開(kāi)的服務(wù)集應(yīng)該是相同的。
PEI Foundation 周圍的統(tǒng)一表面區(qū)域允許 PEIM 用 C 編程語(yǔ)言編寫(xiě)并跨任何微體系結(jié)構(gòu)編譯。

2.6 PEI Dispatcher

PEI Dispatcher 本質(zhì)上是一個(gè)在 PEI Foundation 中實(shí)現(xiàn)的狀態(tài)機(jī)。
PEI Dispatcher 評(píng)估正在檢查的固件卷中的 Pre-EFI 初始化模塊 (PEIM) 中的依賴關(guān)系表達(dá)式。
依賴表達(dá)式是 PEIM 到 PEIM 接口 (PPI) 的邏輯組合。
這些表達(dá)式描述了在調(diào)用給定 PEIM 之前必須可用的 PPI。
為了評(píng)估 PEIM 的依賴表達(dá)式，PEI Dispatcher 參考 PEI Foundation 中的 PPI 數(shù)據(jù)庫(kù)來(lái)確定已安裝哪些 PPI。

如果已經(jīng)安裝了 PPI，依賴表達(dá)式的計(jì)算結(jié)果為 TRUE，它告訴 PEI Dispatcher 它可以運(yùn)行 PEIM。
此時(shí)，PEI Foundation 將控制權(quán)傳遞給具有真正依賴表達(dá)式的 PEIM。
一旦 PEI Dispatcher 評(píng)估了所有公開(kāi)固件卷中的所有 PEIM 并且不再有 PEIM 可以被調(diào)度（即，依賴表達(dá)式不會(huì)從 FALSE 評(píng)估為 TRUE），PEI Dispatcher 將退出。
正是在這一點(diǎn)上，PEI Dispatcher 不能調(diào)用任何額外的 PEIM。
然后 PEI Foundation 重新獲得 PEI Dispatcher 的控制權(quán)，并調(diào)用 DXE IPL PPI 將控制權(quán)傳遞給 DXE 執(zhí)行階段。

2.7 Pre-EFI Initialization Modules (PEIMs)

Pre-EFI 初始化模塊 (PEIM) 是專門(mén)的驅(qū)動(dòng)程序，可將 PEI Foundation 個(gè)性化到平臺(tái)。
它們類似于 DXE 驅(qū)動(dòng)程序，通常對(duì)應(yīng)于正在初始化的組件。
PEI Foundation 代碼負(fù)責(zé)按順序分發(fā) PEIM 并提供基本服務(wù)。PEIM 旨在鏡像正在初始化的組件。

在“內(nèi)存不足”的環(huán)境中，PEIM 之間的通信并不容易。
盡管如此，如果沒(méi)有彼此之間的某種交互，就無(wú)法對(duì) PEIM 進(jìn)行編碼，即使可以，這樣做也是低效的。
PEI 階段為 PEIM 提供了從其他 PEIM 定位和調(diào)用接口的機(jī)制。

由于 PEI 階段存在于可用硬件資源最少且從引導(dǎo)固件設(shè)備執(zhí)行的環(huán)境中，
因此強(qiáng)烈建議 PEIM 執(zhí)行最少必要的工作以將系統(tǒng)初始化為滿足 DXE 階段先決條件的狀態(tài).

預(yù)計(jì)在未來(lái)，通常的做法是由軟件或硬件組件的供應(yīng)商提供 PEIM（可能以源代碼形式），以便客戶可以快速調(diào)試集成問(wèn)題。

2.8 PEIM-to-PEIM Interfaces (PPIs)

PEIM 使用稱為 PEIM 到 PEIM 接口 (PPI) 的結(jié)構(gòu)相互通信。
PPI 包含在 EFI_PEI_PPI_DESCRIPTOR 數(shù)據(jù)結(jié)構(gòu)中，該數(shù)據(jù)結(jié)構(gòu)由 GUID/指針對(duì)組成。
GUID“命名”接口，關(guān)聯(lián)的指針為該 PPI 提供關(guān)聯(lián)的數(shù)據(jù)結(jié)構(gòu)和/或服務(wù)集。
PPI 的使用者必須使用 PEI 服務(wù) LocatePpi() 來(lái)發(fā)現(xiàn)感興趣的 PPI。
PPI 的生產(chǎn)者使用 PEI 服務(wù) InstallPpi() 或 ReinstallPpi() 在其 PEIM 中發(fā)布可用的 PPI。

所有 PEIM 都以相同的方式注冊(cè)和定位，即通過(guò)上面列出的 PEI 服務(wù)。
在 PPI 的這個(gè)命名空間中，有兩類 PPI：

• Architectural PPI
• Additional PPI

Architectural PPI 是其 GUID 在 PEI CIS 中描述的 PPI，并且是 PEI Foundation 已知的 GUID。
這些 Architectural PPI 通常為具有特定平臺(tái)實(shí)現(xiàn)的服務(wù)的 PEI Foundation 提供通用接口，
例如 PEI 服務(wù) ReportStatusCode()。

Additional PPI 是對(duì)互操作性很重要但不受 PEI Foundation 依賴的 PPI。
它們可以分為強(qiáng)制性或可選性。
具體來(lái)說(shuō)，要擁有一大類可互操作的 PEIM，最好以某種標(biāo)準(zhǔn)方式安裝最終引導(dǎo)模式，
以便 PEIM 可以在其依賴項(xiàng)表達(dá)式中使用此 PPI。
在 PEI CIS 中定義這些額外 PPI 的另一種方法是使用不同名稱的類似服務(wù)的激增。

2.9 Firmware Volumes

Pre-EFI 初始化模塊 (PEIM) 駐留在固件卷 (FV) 中。
PEI 階段支持 PEIM 駐留在多個(gè)固件卷中的能力。
其他 PEIM 可以公開(kāi)固件卷以供 PEI 基金會(huì)使用。

3 PEI Services Table

3.1 簡(jiǎn)介

PEI 基金會(huì)建立了一個(gè)名為 PEI Services Table 的系統(tǒng)表，該表對(duì)系統(tǒng)中的所有 Pre-EFI 初始化模塊 (PEIM) 可見(jiàn)。
PEI 服務(wù)被定義為 PEI 基金會(huì)在滿足該服務(wù)的初始化要求時(shí)表現(xiàn)出來(lái)的功能、命令或其他能力。
由于 PEI 階段在接近結(jié)束時(shí)沒(méi)有永久內(nèi)存可用，因此在 PEI 階段創(chuàng)建的服務(wù)范圍不會(huì)像在后期階段創(chuàng)建的那樣豐富。
因?yàn)樵跇?gòu)建時(shí) PEI 基金會(huì)及其臨時(shí) RAM 的位置是未知的，所以指向 PEI 服務(wù)表的指針被傳遞到每個(gè) PEIM 的入口點(diǎn)以及每個(gè) PEIM 到 PEIM 接口 (PPI) 的一部分。

注意：在 PEI 基金會(huì)將 EFI_TABLE_HEADER 用于 PEI 服務(wù)表時(shí)，對(duì) CRC32 字段進(jìn)行了特殊處理。 此值對(duì)于 PEI 是可忽略的，應(yīng)設(shè)置為零。

3.2 PEI Services Table

3.2.1 EFI_PEI_SERVICES

總結(jié)

PEI 服務(wù)表包括一個(gè)表中的函數(shù)指針列表。
該表位于臨時(shí)或永久存儲(chǔ)器中，具體取決于 PEI 的能力和執(zhí)行階段。
此表中的功能在第 20 頁(yè)的“服務(wù) - PEI”中定義。

Related 定義

//
// PEI Specification Revision information
//
#define PEI_SPECIFICATION_MAJOR_REVISION 1
#define PEI_SPECIFICATION_MINOR_REVISION 70
//
// UEFI PEI Services Table
//
#define PEI_SERVICES_SIGNATURE 0x5652455320494550
#define ((PEI_SPECIFICATION_MAJOR_REVISION<<17) |
(PEI_SPECIFICATION_MINOR_REVISION))
typedef EFI_PEI_SERVICES {
 EFI_TABLE_HEADER Hdr;
 //
 // PPI Functions
 //
 EFI_PEI_INSTALL_PPI InstallPpi;
 EFI_PEI_REINSTALL_PPI ReInstallPpi;
 EFI_PEI_LOCATE_PPI LocatePpi;
 EFI_PEI_NOTIFY_PPI NotifyPpi;
 //
 // Boot Mode Functions
 //
 EFI_PEI_GET_BOOT_MODE GetBootMode;
 EFI_PEI_SET_BOOT_MODE SetBootMode;
 //
 // HOB Functions
 //
 EFI_PEI_GET_HOB_LIST GetHobList;
 EFI_PEI_CREATE_HOB CreateHob;
 //
 // Firmware Volume Functions
 //
 EFI_PEI_FFS_FIND_NEXT_VOLUME2 FfsFindNextVolume;
 EFI_PEI_FFS_FIND_NEXT_FILE2 FfsFindNextFile;
 EFI_PEI_FFS_FIND_SECTION_DATA2 FfsFindSectionData;
 //
 // PEI Memory Functions
 //
 EFI_PEI_INSTALL_PEI_MEMORY InstallPeiMemory;
 EFI_PEI_ALLOCATE_PAGES AllocatePages;
 EFI_PEI_ALLOCATE_POOL AllocatePool;
 EFI_PEI_COPY_MEM CopyMem;
 EFI_PEI_SET_MEM SetMem;
 //
 // Status Code
 EFI_PEI_REPORT_STATUS_CODE ReportStatusCode;
  //
 // Reset
 //
 EFI_PEI_RESET_SYSTEM ResetSystem;
 //
 // (the following interfaces are installed by publishing PEIM)
 //
 // I/O Abstractions
 //
 EFI_PEI_CPU_IO_PPI *CpuIo;
 EFI_PEI_PCI_CFG2_PPI *PciCfg;
 //
 // Additional File System-Related Services
 //
 EFI_PEI_FFS_FIND_BY_NAME FfsFindFileByName;
 EFI_PEI_FFS_GET_FILE_INFO FfsGetFileInfo;
 EFI_PEI_FFS_GET_VOLUME_INFO FfsGetVolumeInfo;
 EFI_PEI_REGISTER_FOR_SHADOW RegisterForShadow;
 EFI_PEI_FFS_FIND_SECTION_DATA3 FindSectionData3;
 EFI_PEI_FFS_GET_FILE_INFO2 FfsGetFileInfo2;
 EFI_PEI_RESET2_SYSTEM ResetSystem2;
 EFI_PEI_FREE_PAGES FreePages;

} EFI_PEI_SERVICES;

參數(shù)：

• Hdr:PEI 服務(wù)表的表頭。 此標(biāo)頭包含 PEI_SERVICES_SIGNATURE 和 PEI_SERVICES_REVISION 值以及 EFI_PEI_SERVICES 結(jié)構(gòu)的大小和 32 位 CRC，以驗(yàn)證 PEI 基金會(huì)服務(wù)表的內(nèi)容是否有效。 |
• InstallPpi:通過(guò) GUID 在 PEI PEIM 到 PEIM 接口 (PPI) 數(shù)據(jù)庫(kù)中安裝接口。 請(qǐng)參閱本文檔中的 InstallPpi() 函數(shù)說(shuō)明。
• ReInstallPpi:通過(guò) GUID 在 PEI PPI 數(shù)據(jù)庫(kù)中重新安裝接口。 請(qǐng)參閱本文檔中的 ReinstallPpi() 函數(shù)說(shuō)明。
• LocatePpi 通過(guò) GUID 在 PEI PPI 數(shù)據(jù)庫(kù)中定位接口。 請(qǐng)參閱本文檔中的 LocatePpi() 函數(shù)說(shuō)明。
• NotifyPpi 安裝通知服務(wù)，在安裝或重新安裝給定接口時(shí)回調(diào)。 請(qǐng)參閱本文檔中的 NotifyPpi() 函數(shù)說(shuō)明。
• GetBootMode 返回引導(dǎo)模式的當(dāng)前值。 請(qǐng)參閱本文檔中的 GetBootMode() 函數(shù)說(shuō)明。
• SetBootMode 設(shè)置引導(dǎo)模式的值。 請(qǐng)參閱本文檔中的 SetBootMode() 函數(shù)說(shuō)明。
• GetHobList 返回指向內(nèi)存中切換塊 (HOB) 列表的指針。請(qǐng)參閱本文檔中的 GetHobList() 函數(shù)說(shuō)明。
• CreateHob 抽象 HOB 頭的創(chuàng)建。請(qǐng)參閱本文檔中的 CreateHob() 函數(shù)說(shuō)明。
• FfsFindNextVolume 發(fā)現(xiàn)系統(tǒng)中固件卷的實(shí)例。請(qǐng)參閱本文檔中的 FfsFindNextVolume() 函數(shù)說(shuō)明。
• FfsFindNextFile 發(fā)現(xiàn)系統(tǒng)中固件文件的實(shí)例。請(qǐng)參閱本文檔中的 FfsFindNextFile() 函數(shù)說(shuō)明。
• FfsFindSectionData 搜索固件文件中的部分。請(qǐng)參閱本文檔中的 FfsFindSectionData() 函數(shù)說(shuō)明。
• InstallPeiMemory 向 PEI 基金會(huì)注冊(cè)找到的內(nèi)存配置。請(qǐng)參閱本文檔中的 InstallPeiMemory() 函數(shù)說(shuō)明。
• AllocatePages 分配由 PEI 基金會(huì)管理的內(nèi)存范圍。請(qǐng)參閱本文檔中的 AllocatePages() 函數(shù)說(shuō)明。
• AllocatePool 釋放由 PEI 基金會(huì)管理的內(nèi)存范圍。請(qǐng)參閱本文檔中的 AllocatePool() 函數(shù)說(shuō)明。
• CopyMem 將一個(gè)緩沖區(qū)的內(nèi)容復(fù)制到另一個(gè)緩沖區(qū)。請(qǐng)參閱本文檔中的 CopyMem() 函數(shù)說(shuō)明。
• SetMem 用指定的值填充緩沖區(qū)。請(qǐng)參閱本文檔中的 SetMem() 函數(shù)說(shuō)明。
• ReportStatusCode 提供一個(gè)接口，PEIM 可以調(diào)用該接口來(lái)報(bào)告狀態(tài)代碼。 請(qǐng)參閱本文檔中的 ReportStatusCode() 函數(shù)說(shuō)明。這是由提供商 PEIM 通過(guò)將接口復(fù)制到 PEI 服務(wù)表中來(lái)安裝的。
• ResetSystem 重置整個(gè)平臺(tái)。 請(qǐng)參閱本文檔中的 ResetSystem() 函數(shù)說(shuō)明。 這是由提供商 PEIM 通過(guò)將接口復(fù)制到 PEI 服務(wù)表中來(lái)安裝的。
• ResetSystem2 重置整個(gè)平臺(tái)。 請(qǐng)參閱本文檔中的 ResetSystem2() 函數(shù)說(shuō)明。 這是由提供商 PEIM 通過(guò)將接口復(fù)制到 PEI 服務(wù)表中來(lái)安裝的。
• CpuIo 提供一個(gè)接口，PEIM 可以調(diào)用該接口來(lái)執(zhí)行 I/O 事務(wù)。 此接口由提供商 PEIM 通過(guò)將接口復(fù)制到 PEI 服務(wù)表中來(lái)安裝。
• PciCfg 提供一個(gè)接口，PEIM 可以調(diào)用該接口來(lái)執(zhí)行 PCI 配置事務(wù)。 此接口由提供商 PEIM 通過(guò)將接口復(fù)制到 EFI_PEI_SERVICES 表中來(lái)安裝。
• FfsFindFileByName 按名稱發(fā)現(xiàn)卷中的固件文件。 請(qǐng)參閱本文檔中的 FfsFindFileByName()。
• FfsGetFileInfo 返回有關(guān)特定文件的信息。 請(qǐng)參閱本文檔中的 FfsGetFileInfo()。
• FfsGetFileInfo2 返回有關(guān)特定文件的信息。 請(qǐng)參閱本文檔中的 FfsGetFileInfo2()。
• FfsGetVolumeInfo 返回有關(guān)特定卷的信息。 請(qǐng)參閱本文檔中的 FfsGetVolumeInfo()。
• RegisterForShadow 注冊(cè)要在內(nèi)存可用時(shí)重新加載的驅(qū)動(dòng)程序。 請(qǐng)參閱本文檔中的 RegisterForShadow()。
• FindSectionData3 在固件文件中搜索一個(gè)部分。 請(qǐng)參閱本文檔中的 FfsFindSectionData3() 函數(shù)說(shuō)明。
• FreePages 釋放先前使用 AllocatePages() 分配的內(nèi)存。

描述：

EFI_PEI_SERVICES 是一組函數(shù)，其實(shí)現(xiàn)由 PEI 基金會(huì)提供。 這些服務(wù)分為不同的類別，包括：

• 管理引導(dǎo)模式
• 分配早期和永久內(nèi)存
• 支持固件文件系統(tǒng) (FFS)
• 抽象 PPI 數(shù)據(jù)庫(kù)抽象
• 創(chuàng)建切換塊 (HOB)

當(dāng) PEI 基金會(huì)調(diào)用 PEIM 時(shí)，將指向 EFI_PEI_SERVICES 表的指針傳遞到每個(gè) PEIM .
因此，每個(gè) PEIM 都可以訪問(wèn)這些服務(wù)。
與 UEFI 引導(dǎo)服務(wù)不同，PEI 服務(wù)沒(méi)有調(diào)用限制，例如 UEFI 2.0 任務(wù)優(yōu)先級(jí) (TPL) 限制。
具體來(lái)說(shuō)，可以從 PEIM 或通知服務(wù)調(diào)用服務(wù)。
一些服務(wù)也是平臺(tái)提供服務(wù)的代理，例如重置服務(wù)、狀態(tài)代碼服務(wù)和 I/O 抽象。
這種分區(qū)旨在提供一個(gè)與所有 PEIM 的接口一致，而無(wú)需使用特定于平臺(tái)的知識(shí)來(lái)妨礙 PEI 基金會(huì)的實(shí)施。
任何超出此表中集合的可調(diào)用服務(wù)都應(yīng)使用 PPI 調(diào)用。
后面的 PEIM 安裝的服務(wù)將返回 EFI_NOT_AVAILABLE_YET，直到 PEIM 將接口的實(shí)例復(fù)制到 EFI_PEI_SERVICES 表中。

4 Services - PEI

4.1 簡(jiǎn)介

PEI 服務(wù)被定義為 PEI 基金會(huì)在階段完成后保持可用的功能、命令或其他能力。
由于 PEI 階段在接近結(jié)束時(shí)沒(méi)有永久內(nèi)存可用，因此在 PEI 階段創(chuàng)建的 PEI 基金會(huì)服務(wù)的范圍不會(huì)像后期階段創(chuàng)建的那樣豐富。

• PPI 服務(wù)：管理 PEIM 到 PEIM 接口 (PPI) 以促進(jìn) PEIM 之間的模塊間調(diào)用。 接口在臨時(shí) RAM 中維護(hù)的數(shù)據(jù)庫(kù)上安裝和跟蹤。
• 引導(dǎo)模式服務(wù)：管理系統(tǒng)的引導(dǎo)模式（S3、S5、正常引導(dǎo)、診斷等）。
• HOB 服務(wù)：創(chuàng)建稱為切換塊 (HOB) 的數(shù)據(jù)結(jié)構(gòu)，用于將信息傳遞到 PI 架構(gòu)的下一階段。
• 固件卷服務(wù)：遍歷固件卷中的固件文件系統(tǒng) (FFS) 以查找閃存設(shè)備中的 PEIM 和其他固件文件。
• PEI 內(nèi)存服務(wù)：提供一組內(nèi)存管理服務(wù)，供在發(fā)現(xiàn)永久內(nèi)存之前和之后使用。
• 狀態(tài)代碼服務(wù)：提供常見(jiàn)的進(jìn)度和錯(cuò)誤代碼報(bào)告服務(wù)（例如，端口 080h 或用于調(diào)試的簡(jiǎn)單文本輸出的串行端口）。
• 重置服務(wù)：提供啟動(dòng)系統(tǒng)熱重啟或冷重啟的常用方法。

PEI 服務(wù)的調(diào)用約定類似于 PPI。 有關(guān) PPI 的更多詳細(xì)信息，請(qǐng)參閱“PEIM 到 PEIM 通信”。
將服務(wù)調(diào)用綁定到服務(wù)的方法涉及一個(gè)調(diào)度表，EFI_PEI_SERVICES。指向該表的指針被傳遞到 PEIM 入口點(diǎn)。

4.2 PPI Services

以下服務(wù)提供了用于抽象 PPI 數(shù)據(jù)庫(kù)的接口集：

• InstallPpi()
• ReinstallPpi()
• LocatePpi()
• NotifyPpi()

InstallPpi()

摘要：此服務(wù)是 PEI 基金會(huì)提供的第一個(gè)服務(wù)。
此函數(shù)通過(guò) GUID 在 PEI PPI 數(shù)據(jù)庫(kù)中安裝一個(gè)接口。
該服務(wù)的目的是發(fā)布一個(gè)接口，其他方可以使用它來(lái)調(diào)用其他 PEIM。

原型：

typedef
EFI_STATUS
(EFIAPI *EFI_PEI_INSTALL_PPI) (
 IN CONST EFI_PEI_SERVICES **PeiServices,
 IN CONST EFI_PEI_PPI_DESCRIPTOR *PpiList
 );

參數(shù):

• PeiServices 指向 PEI 基金會(huì)發(fā)布的 EFI_PEI_SERVICES 表的間接指針。
• PpiList 指向調(diào)用者應(yīng)安裝的接口列表的指針。 EFI_PEI_PPI_DESCRIPTOR 類型在第 110 頁(yè)的“PEIM 描述符”中定義。

描述:

此服務(wù)使給定的 PEIM 能夠向 PEI 基金會(huì)注冊(cè)接口。
該接口采用指向符合 EFI_PEI_PPI_DESCRIPTOR 格式的記錄列表的指針。
由于 PEI 基金會(huì)維護(hù)一個(gè)指向該列表的指針而不是復(fù)制該列表，該列表必須要么位于 PEIM 的主體中，要么從臨時(shí)或永久 RAM 中分配。
由 EFI_PEI_PPI_DESCRIPTOR 描述的列表的長(zhǎng)度，在其 Flags 字段中設(shè)置了 EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST 標(biāo)志。
列表中至少應(yīng)有一個(gè) EFI_PEI_PPI_DESCRIPTOR。
可以安裝兩種類型的 EFI_PEI_PPI_DESCRIPTOR，
包括 EFI_PEI_PPI_DESCRIPTOR_NOTIFY_DISPATCH 和 EFI_PEI_PPI_DESCRIPTOR_NOTIFY_CALLBACK。

返回的狀態(tài)代碼

• EFI_SUCCESS 接口安裝成功。
• EFI_INVALID_PARAMETER PpiList 指針為 NULL。
• EFI_INVALID_PARAMETER 列表中的任何 PEI PPI 描述符都沒(méi)有在 Flags 字段中設(shè)置 EFI_PEI_PPI_DESCRIPTOR_PPI 位。
• EFI_OUT_OF_RESOURCES PPI 數(shù)據(jù)庫(kù)中沒(méi)有額外的空間。

4.3 Boot Mode Services

4.4 HOB Services

4.5 Firmware Volume Services

4.6 PEI Memory Services

4.7 Status Code Service

4.8 Reset Services

4.9 I/O and PCI Services

PEI 基金會(huì)發(fā)布 CPU I/O 和 PCI 配置服務(wù)。

5 PEI Foundation

5.1 簡(jiǎn)介

PEI 基金會(huì)以 PEI Dispatcher 為中心。
調(diào)度員的工作是有序地將控制權(quán)交給 PEIM。
PEI 基金會(huì)還協(xié)助 PEIM 到 PEIM 的交流。
模塊到模塊通信的核心資源涉及 PPI。
可以使用可安裝或通知界面對(duì) PPI 的引用進(jìn)行編組。
PEI Foundation 構(gòu)建為一個(gè)自治二進(jìn)制映像，文件類型為 EFI_FV_FILETYPE_PEI_CORE，由以下部分組成：

• 身份驗(yàn)證部分
• 可能是 PE32 的代碼映像

有關(guān)部分和文件的信息，請(qǐng)參閱 Platform Initialization Specification，第 3 卷 。
如果構(gòu)成 PEI 基金會(huì)的代碼不是 PE32 映像，則它是原始二進(jìn)制文件，其最低地址是 PEI 基金會(huì)的入口點(diǎn)。
PEI 基金會(huì)由安全 (SEC) 階段發(fā)現(xiàn)和驗(yàn)證。

5.1.1 先決條件

PEI 階段由符合 PI 架構(gòu)的引導(dǎo)過(guò)程的安全 (SEC) 階段控制。
PEI 階段在開(kāi)始執(zhí)行之前必須滿足以下最低先決條件：

• 處理器執(zhí)行模式
• 訪問(wèn)包含 PEI 基金會(huì)的固件卷

期望 SEC 基礎(chǔ)設(shè)施代碼和 PEI 基金會(huì)不會(huì)鏈接在一起作為單個(gè) ROMable 可執(zhí)行文件鏡像。
從 SEC 到 PEI 的入口點(diǎn)在架構(gòu)上不是固定的，而是取決于 FV0 中的 PEI 基金會(huì)位置，或引導(dǎo)固件卷。

5.1.2 Processor Execution Mode

5.1.2.1 IA-32 英特爾 ? 架構(gòu)中的處理器執(zhí)行模式

在 IA-32 英特爾架構(gòu)中，PI 架構(gòu)的安全 (SEC) 階段負(fù)責(zé)將處理器置于原生線性地址模式，
通過(guò)該模式，處理器的完整地址范圍 處理器可訪問(wèn)代碼、數(shù)據(jù)和堆棧。
例如，“flat 32”是 IA-32 處理器生成模式，PEI 階段將在其中執(zhí)行。
處理器必須處于其最高特權(quán)的“ring 0”模式或等效模式，并且能夠訪問(wèn)所有內(nèi)存和 I/O 空間。
這個(gè)先決條件嚴(yán)格依賴于處理器代架構(gòu)。

5.1.2.2 Itanium? 處理器系列中的處理器執(zhí)行模式

PEI 基金會(huì)將在安全 (SEC) 階段完成后開(kāi)始執(zhí)行。 SEC 階段包含了 Itanium? 中的系統(tǒng)抽象層入口點(diǎn) (SALE_ENTRY)。
此外，SEC 階段進(jìn)行適當(dāng)?shù)奶幚砥鞒橄髮?(PAL) 調(diào)用或平臺(tái)服務(wù)以啟用臨時(shí)內(nèi)存存儲(chǔ)。
SEC 將其切換狀態(tài)以物理模式傳遞給 PEI 基金會(huì)，其中包含一些已配置的內(nèi)存堆棧，例如將處理器緩存配置為內(nèi)存。

5.1.2.3 訪問(wèn)引導(dǎo)固件卷 (BFV) 和其他引導(dǎo)關(guān)鍵 FV

安全 (SEC) 階段控制的程序被稱為 PEI 基金會(huì)。
PEIM 可能駐留在 BFV 或其他 FV 中。
BFV 中必須有一個(gè)“特殊”P(pán)EIM，以提供有關(guān)其他 FV 位置的信息。
在 BFV 和其他關(guān)鍵 FV（例如 PEI 基金會(huì)所在的位置）中啟動(dòng)所需的每個(gè)文件都必須能夠被 PEI 階段發(fā)現(xiàn)和驗(yàn)證。
這允許 PEI 階段確定這些 FV 是否已損壞。
PEI 基金會(huì)和 PEIM 預(yù)計(jì)將存儲(chǔ)在一些合理的防篡改（盡管不一定在嚴(yán)格的基于安全的術(shù)語(yǔ)定義中）非易失性存儲(chǔ) (NVS) 中。
預(yù)計(jì)存儲(chǔ)將非常類似于具有唯一 ID 代替名稱的平面文件系統(tǒng)。
使用特定 NVS 的規(guī)則可能會(huì)影響某些存儲(chǔ)注意事項(xiàng)，但需要一種用于通過(guò) ID 定位 PEIM 的標(biāo)準(zhǔn)純數(shù)據(jù)機(jī)制。
PI 架構(gòu)架構(gòu)描述了 PI 固件卷格式和 PI 固件文件系統(tǒng)格式，以及命名文件的 GUID 約定。
這些標(biāo)準(zhǔn)是 PEI 的架構(gòu)標(biāo)準(zhǔn)，因?yàn)?PEI 階段需要直接支持該文件系統(tǒng)。
BFV 只能構(gòu)造為 EFI_FIRMWARE_FILE_SYSTEM2_GUID 類型。
PEI 基金會(huì)和恢復(fù)所需的一些 PEIM 必須要么鎖定在不可更新的 FV 中，要么必須能夠通過(guò)“容錯(cuò)”機(jī)制進(jìn)行更新。
容錯(cuò)機(jī)制被設(shè)計(jì)成這樣，如果系統(tǒng)在任何時(shí)候停止，舊的（更新前的）PEIM 或新更新的 PEIM 都是完全有效的，
并且 PEI 階段可以確定哪個(gè)是有效的。

5.1.2.4 訪問(wèn) IA-32 Intel 架構(gòu)中的引導(dǎo)固件卷

在 IA-32 Intel 架構(gòu)中，安全 (SEC) 文件位于引導(dǎo)固件卷 (BFV) 的頂部。
此 SEC 文件將具有 IA-32 的 16 字節(jié)入口點(diǎn)，并在地址 0xFFFFFFF0 處重新啟動(dòng)。

5.1.2.5 訪問(wèn)安騰處理器家族中的引導(dǎo)固件卷

在安騰處理器家族中，微碼啟動(dòng)處理器抽象層 A（PAL-A）代碼，這是第一層 PAL 代碼，由處理器供應(yīng)商提供，駐留在引導(dǎo)固件卷 (BFV) 中。
此代碼最低限度地初始化處理器，然后查找并驗(yàn)證稱為 PAL-B 的第二層 PAL 代碼。
PAL-A 和 PAL-B 的位置可以通過(guò)查閱以下任一方法找到：

• ROM 中的架構(gòu)指針（4 GiB 區(qū)域附近）
• ROM 中的固件接口表 (FIT) 指針 PAL 層使用稱為系統(tǒng)抽象層入口點(diǎn) (SALE_ENTRY) 的單個(gè)入口點(diǎn)與 OEM 啟動(dòng)固件進(jìn)行通信。

PEI Foundation 將位于基于 Itanium 的系統(tǒng)的引導(dǎo)固件設(shè)備上的 SALE_ENTRY 點(diǎn)。
Itanium 處理器系列 PEIM 與其他 PEIM 一樣，可以駐留在 BFV 或其他固件卷中。
“特殊”P(pán)EIM 必須駐留在 BFV 中，以提供有關(guān)其他固件卷位置的信息；這將在 EFI_PEI_FIND_FV_PPI 的上下文中描述

還必須注意的是，在基于 Itanium 的系統(tǒng)中，每個(gè)節(jié)點(diǎn)中的所有處理器都啟動(dòng)并執(zhí)行 PAL 代碼，然后進(jìn)入 PEI 基金會(huì)。
特定節(jié)點(diǎn)的 BFV 必須可由該節(jié)點(diǎn)中運(yùn)行的所有處理器訪問(wèn)。
這也意味著 Itanium? 體系結(jié)構(gòu)引導(dǎo)路徑中的某些 PEIM 將支持多處理器 (MP)。
在基于 Itanium 的系統(tǒng)中，BFV 中固件模塊的組織也必須如此，至少 PAL-A 包含在容錯(cuò)區(qū)域中。
此特定于處理器的 PAL-A 代碼驗(yàn)證 PAL-B 代碼，該代碼通常包含在固件系統(tǒng)的非容錯(cuò)區(qū)域中。
PAL-A 和 PAL-B 二進(jìn)制組件在上電時(shí)始終對(duì)節(jié)點(diǎn)中的所有處理器可見(jiàn)； 系統(tǒng)結(jié)構(gòu)不需要初始化。

5.2 PEI Foundation Entry Point

5.2.1 PEI 基金會(huì)入口點(diǎn)

安全 (SEC) 階段使用以下信息調(diào)用 PEI 基金會(huì)的入口點(diǎn)：

• 一組 PPI
• 引導(dǎo)固件卷 (BFV) 的大小和位置
• 其他 boot-critical 固件卷的大小和位置 ，通過(guò)將固件卷添加到具有 EFI_PEI_FIRMWARE_VOLUME_PPI 類型的 PpiList。
• 臨時(shí) RAM 的大小和位置
• 可供 PEI 基金會(huì)使用的臨時(shí) RAM 的大小和位置
• 堆棧的大小和位置

入口點(diǎn)在下面的“代碼定義”中描述。

Prototype

typedef
VOID
EFIAPI
(*EFI_PEI_CORE_ENTRY_POINT)(
 IN CONST EFI_SEC_PEI_HAND_OFF *SecCoreData,
 IN CONST EFI_PEI_PPI_DESCRIPTOR *PpiList
 );

參數(shù):

• SecCoreData 指向包含有關(guān) PEI 內(nèi)核操作環(huán)境信息的數(shù)據(jù)結(jié)構(gòu)，
  例如臨時(shí) RAM 的大小和位置、堆棧位置和 BFV 位置。 EFI_SEC_PEI_HAND_OFF 類型在下面的“相關(guān)定義”中定義。
• PpiList 指向一個(gè)或多個(gè) PPI 描述符的列表。
  這些 PPI 描述符可以是 EFI_PEI_PPI_DESCRIPTOR 類型的描述符的組合，
  用于最初由 PEI 核心安裝的 PPI 和類型 EFI_PEI_NOTIFY_DESCRIPTOR 的描述符用于通知，PEI 核心將在安裝 PPI 服務(wù)時(shí)通知。
  一個(gè)空的 PPI 列表由一個(gè)帶有結(jié)束標(biāo)簽 EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST 的描述符組成。
  EFI_PEI_PPI_DESCRIPTOR 和 EFI_PEI_NOTIFY_DESCRIPTOR 類型在“PEIM 描述符”中定義。
  作為初始化階段的一部分，PEI 基金會(huì)將這些 SEC 托管的 PPI 添加到其 PPI 數(shù)據(jù)庫(kù)中，
  這樣 PEI 基金會(huì)和任何模塊都可以利用相關(guān)的服務(wù)調(diào)用和/或代碼。
  這應(yīng)該包含將通過(guò) EFI_PEI_FIRMWARE_VOLUME_PPI 從 SEC 傳遞到 PEI Foundation 的所有啟動(dòng)關(guān)鍵 FV。

描述:

此函數(shù)是 PEI 基金會(huì)的入口點(diǎn)，它允許 SEC 階段傳遞有關(guān)堆棧、臨時(shí) RAM 和引導(dǎo)固件卷的信息。

此外，它還允許 SEC 階段以一個(gè)或多個(gè) PPI 的形式轉(zhuǎn)發(fā)服務(wù)和數(shù)據(jù)以供 PEI 階段使用。
這些 PPI 將被安裝和/或編碼在這些早期的 PPI 中。

最后，平臺(tái)演化的后期階段可能需要 SEC 階段可能擁有的許多功能和數(shù)據(jù)。
為了支持這一點(diǎn)，SEC 階段可以構(gòu)造一個(gè) EFI_PEI_PPI_DESCRIPTOR 并將其地址作為最終參數(shù)傳遞給 PEI 基金會(huì)。

在這些 PPI 中，SEC 可以傳遞一個(gè)可選的 PPI，EFI_SEC_PLATFORM_INFORMATION_PPI，
作為傳遞給 PEI 基金會(huì)入口點(diǎn)的 PPI 列表的一部分。

該 PPI 抽象了平臺(tái)特定的信息，PEI 基金會(huì)需要這些信息來(lái)發(fā)現(xiàn)從哪里開(kāi)始分發(fā) PEIM。
傳遞給 PEI 基金會(huì)的其他可能值包括任何安全或驗(yàn)證服務(wù)，例如可信計(jì)算組 (TCG) 訪問(wèn)服務(wù)，
因?yàn)?SEC 將在符合 TCG 的情況下構(gòu)成核心信任根模塊 (CRTM) 系統(tǒng)。

此外，SEC 可以將 EFI_SEC_HOB_DATA_PPI 作為 PPI 列表的一部分傳遞。
在任何 PEIM 被分派之前，該 PPI 可以檢索要添加到 HOB 列表的零個(gè)或多個(gè) HOB。

5.3 PEI Calling Convention Processor Binding

除非另有說(shuō)明，用于 PEI 函數(shù)的調(diào)用約定與 UEFI 規(guī)范中指定的調(diào)用約定相同。 但是，對(duì)于某些處理器，建議為新的 PPI 定義使用替代調(diào)用約定。

5.4 PEI 服務(wù)表檢索

本節(jié)描述用于檢索指向 PEI 服務(wù)表 (EFI_PEI_SERVICES**) 的指針的處理器特定機(jī)制，如 PEIM 中常用的。
存儲(chǔ)和檢索方式是特定于處理器的。

5.4.4 ARM Processor Family – Register Mechanism

對(duì)于 ARM 處理器系列處理器，(EFI_PEI_SERVICES) 存儲(chǔ)在 ARMv7-A 架構(gòu)參考手冊(cè)中定義的 TPIDRURW 讀/寫(xiě)軟件線程 ID 寄存器中。
可以使用以下代碼片段檢索 EFI_PEI_SERVICES，可以將其放置在庫(kù)例程中以實(shí)現(xiàn)架構(gòu)之間的可移植性：

CpuReadTPIDRURW:
 MRC p15, 0, r0, c13, c0, 2
 bx lr
EFI_PEI_SERVICES **
GetPeiServicesTablePointer (
 VOID
 )
{
 return (EFI_PEI_SERVICES **)(UINTN)CpuReadTPIDRURW ();
}

5.4.4.1 ARM 向量表

對(duì)于 ARM 處理器，向量表?xiàng)l目是指令，因此限于分支指令的 24 位相對(duì)偏移量。
PI 規(guī)范要求定義的 8 個(gè)向量包含以下指令 LDR pc, [pc, #0x20]。
這意味著處理程序的 32 位地址位于向量地址的 32 字節(jié)偏移處。
當(dāng) PI 代碼掛接到向量表中時(shí)，它必須確保與向量相距 32 字節(jié)的 32 位絕對(duì)地址偏移量是更新的內(nèi)容。
平臺(tái)中初始化向量表的第一個(gè)代碼必須用 8 個(gè) LDR pc, [pc, #0x20] 指令填充它。

5.5 PEI Dispatcher Introduction

PEI 調(diào)度員的工作是有序地將控制權(quán)交給 PEIM。PEI Dispatcher 由單個(gè)階段組成。
在此階段，PEI 基金會(huì)將檢查固件卷中包含 EFI_FV_FILETYPE_PEIM 或 EFI_FV_FILETYPE_COMBINED_PEIM_DRIVER 類型文件的每個(gè)文件（有關(guān)文件類型定義，請(qǐng)參閱平臺(tái)初始化規(guī)范，第 3 卷）。
它將檢查每個(gè)固件文件中的依賴表達(dá)式 (depex) 和可選的先驗(yàn)文件，以確定何時(shí)可以分發(fā) PEIM。
depex 的二進(jìn)制編碼將與與 PEIM 關(guān)聯(lián)的 depex 的二進(jìn)制編碼相同。

5.6 Ordering

5.6.1 要求

除了 a priori 文件規(guī)定的順序外，期望 PEIM 以任何順序執(zhí)行都是不合理的。
芯片組初始化 PEIM 通常需要處理器初始化，而存儲(chǔ)器初始化 PEIM 通常需要芯片組初始化。
另一方面，滿足這些要求的 PEIM 可能由不同的組織編寫(xiě)并且可能駐留在不同的 FV 中。
因此，要求是在沒(méi)有內(nèi)存的情況下創(chuàng)建一種機(jī)制來(lái)允許定義不同 PEIM 之間的排序，
以便在 PEIM 執(zhí)行時(shí)，它執(zhí)行的所有要求都已得到滿足。

盡管更新和構(gòu)建過(guò)程有助于解決排序問(wèn)題，但不能完全依賴它們。
考慮一個(gè)帶有可拆卸處理器卡的系統(tǒng)，其中包含插入主系統(tǒng)板的處理器和固件卷。
如果處理器卡被升級(jí)，即使沒(méi)有執(zhí)行更新程序，用戶也應(yīng)該期望系統(tǒng)工作是完全合理的。

5.6.2 需求表示和符號(hào)

需求由 GUID 表示，每個(gè) GUID 代表一個(gè)特定的需求。
這些要求由兩組數(shù)據(jù)結(jié)構(gòu)表示：

• 給定 PEIM 的依賴表達(dá)式 (depex)
• PEI 基金會(huì)在 PPI 數(shù)據(jù)庫(kù)中維護(hù)的已安裝 PPI 集

該機(jī)制提供了 PEIM 之間的“弱排序”。
如果 PEIM A 和 B 消耗 X（寫(xiě)成 AcX 和 BcX），一旦執(zhí)行了產(chǎn)生 X（CpX）的 PEIM（C），A 和 B 就可以被執(zhí)行。
A 和 B 的執(zhí)行順序沒(méi)有定義。

5.6.3 PEI a priori File Overview

PEI 先驗(yàn)文件是一個(gè)特殊文件，可以選擇存在于固件卷中，其主要目的是在平臺(tái)的固件設(shè)計(jì)中提供更大程度的靈活性。
具體來(lái)說(shuō)，先驗(yàn)文件通過(guò)規(guī)定一系列需要按規(guī)定順序調(diào)度的模塊來(lái)補(bǔ)充 PEI 的依賴表達(dá)機(jī)制。

平臺(tái)中存在的每個(gè)固件卷最多可能有一個(gè) PEI 先驗(yàn)文件。
先驗(yàn)文件具有已知的 GUID 文件名 PEI_APRIORI_FILE_NAME_GUID，使 PEI 基金會(huì)調(diào)度行為能夠找到先驗(yàn)文件（如果存在）。
文件的內(nèi)容應(yīng)包含格式為 PEI_APRIORI_FILE_CONTENTS 的數(shù)據(jù)，可能有零個(gè)條目。
每次 PEI Dispatcher 發(fā)現(xiàn)固件卷時(shí)，它首先查找先驗(yàn)文件。
在先驗(yàn)文件中列舉的 PEIM 必須與先驗(yàn)文件本身存在于同一固件卷中；不允許跨卷映射。
PEI 基金會(huì)將按照此文件中的順序調(diào)用 PEI_APRIORI_FILE_CONTENTS 中列出的 PEIM。

在沒(méi)有先驗(yàn)文件的情況下，PEIM 僅僅因?yàn)樗鼈兊囊蕾嚤磉_(dá)式而被執(zhí)行是弱排序的。
這意味著執(zhí)行順序在引導(dǎo)之間或平臺(tái)之間不是完全確定的。
在某些情況下，需要確定性的執(zhí)行順序。

PEI 先驗(yàn)文件使用以下兩種實(shí)現(xiàn)方法提供了 PEIM 的確定性執(zhí)行順序。
所有 PEI 基金會(huì)實(shí)現(xiàn)都必須支持先驗(yàn)?zāi)Ｐ停慌懦~外的先驗(yàn)調(diào)度方法，
只要后一種模型使用不同的機(jī)制和/或文件名 GUID 來(lái)替代先驗(yàn)?zāi)K列表。

先驗(yàn)文件格式如下：

PEI_APRIORI_FILE_NAME_GUID

Summary

GUID PEI_APRIORI_FILE_NAME_GUID 定義是存儲(chǔ)在固件卷中的 PEI 先驗(yàn)文件的文件名。

GUID

#define PEI_APRIORI_FILE_NAME_GUID \
 {0x1b45cc0a,0x156a,0x428a,0xaf62,0x49,0x86,\
 0x4d,0xa0,0xe6,0xe6}
typedef struct {
EFI_GUID FileNamesWithinVolume[NumberOfModulesInVolume];
 // Optional list of file-names
} PEI_APRIORI_FILE_CONTENTS;

參數(shù)：

• FileNamesWithinVolume[] 與同一固件卷中 PEIM 模塊的文件名匹配的零個(gè)或多個(gè) EFI_GUID 類型條目的數(shù)組。
  NumberOfModulesInVolume 的最大條目數(shù)由 FV 中的模塊數(shù)決定

5.6.3.1 Dispatch Behavior

先驗(yàn)文件可以包含 EFI_GUID 列表，它們是同一固件卷中 PEIM 文件的名稱。
此處，PEI 基金會(huì)調(diào)度邏輯從先驗(yàn)文件中讀取名稱列表，并按照先驗(yàn)文件中列舉的順序調(diào)用適當(dāng)命名的模塊。
這個(gè)值可以通過(guò) PEI_APRIORI_FILE_CONTENTS 的大小來(lái)計(jì)算。這應(yīng)該是 GUID 大小的整數(shù)。

如果 PEI_APRIORI_FILE_CONTENTS 中存在處于刪除狀態(tài)或不存在的文件名，
則該特定文件名將被 PEI 基金會(huì)調(diào)度邏輯忽略并調(diào)用后續(xù)條目。

在先驗(yàn)文件中派發(fā) PEIM 期間，新發(fā)布的固件卷中的任何 PEIM 將被忽略，直到先驗(yàn)文件派發(fā)完成。
不過(guò)，這些接口將在后續(xù)模塊調(diào)度期間進(jìn)行評(píng)估。
除了忽略在先驗(yàn)調(diào)度期間發(fā)布的任何其他卷之外，與列在 PEI_APRIORI_FILE_CONTENTS 中的 PEIM 關(guān)聯(lián)的任何依賴表達(dá)式都將被忽略。

在先驗(yàn) PEIM 列表的調(diào)度期間，PEI 調(diào)度程序應(yīng)調(diào)用 EFI_PEI_SECURITY2_PPI AuthenticationState 服務(wù)（如果存在）以限定每個(gè)模塊的調(diào)度。
這與普通的基于依賴的調(diào)度行為相同。
對(duì)于啟動(dòng)固件卷中的先驗(yàn)文件，例如，EFI_PEI_SECURITY2_PPI 可以由 SEC 通過(guò)可選的 EFI_PEI_PPI_DESCRIPTOR 列表傳遞到 PEI 基金會(huì)。
后一種情況允許對(duì)先驗(yàn)文件中的 PEIM 進(jìn)行身份驗(yàn)證。

在執(zhí)行完先驗(yàn)文件中指定的所有 PEIM 后，PEI Dispatcher 在固件卷中搜索任何其他 PEIM 并根據(jù)它們的依賴表達(dá)式執(zhí)行它們。

5.6.4 固件卷映像文件

對(duì)于 PEI，在處理固件卷時(shí)，如果發(fā)現(xiàn)類型為 EFI_FV_FIRMWARE_VOLUME_IMAGE 的文件，
PEI Dispatcher 將檢查該固件卷映像文件是否已經(jīng)被處理。如果是，則忽略該文件。

否則，PEI 調(diào)度程序?qū)⒃谖募兴阉黝愋蜑?EFI_SECTION_PEI_DEPEX 的部分，
如果找到，則根據(jù) PPI 數(shù)據(jù)庫(kù)中當(dāng)前安裝的條目評(píng)估表達(dá)式。
如果文件有一個(gè)評(píng)估為 TRUE 的依賴表達(dá)式（或沒(méi)有 EFI_SECTION_PEI_DEPEX 部分），
那么 PEI Dispatcher 將在文件中搜索類型為 EFI_SECTION_FIRMWARE_VOLUME_IMAGE 的部分，
將其內(nèi)容復(fù)制到內(nèi)存中，并安裝 EFI_PEI_FIRMWARE_VOLUME_INFO_PPI 和 EFI_PEI_FIRMWARE_VOLUME_INFO_PPI 的固件卷 映像，
并將 EFI_HOB_FIRMWARE_VOLUME 和 EFI_HOB_FIRMWARE_VOLUME2 類型的 HOB 添加到固件卷映像的 HOB 列表中。

5.6.5 PEIM 依賴表達(dá)式

PEIM 的排序是通過(guò)評(píng)估與每個(gè) PEIM 關(guān)聯(lián)的依賴表達(dá)式來(lái)確定的。
該表達(dá)式描述了 PEIM 運(yùn)行所需的要求，這對(duì) PEIM 施加了弱排序。
在這種弱排序中，PEIM 可以按任何順序初始化。

5.6.6 依賴的類型

依賴表達(dá)式的基本單元是依賴。 以下部分顯示了每個(gè)依賴項(xiàng)的代表性語(yǔ)法（在本文檔中用于描述目的）。
語(yǔ)法不區(qū)分大小寫(xiě)，并且使用助記符代替非人類可讀的數(shù)據(jù)，例如 GUID?？瞻资强蛇x的。

操作數(shù)是 PPI 的 GUID。 當(dāng)注冊(cè)具有 GUID 的 PPI 時(shí)，操作數(shù)變?yōu)椤癟RUE”。

5.7 Dependency Expressions

5.8 Dispatch Algorithm

5.8.1 概述

5.8.1.1 排序算法

調(diào)度算法反復(fù)掃描 PEIM 以找到那些尚未調(diào)度的 PEIM。
對(duì)于找到的每個(gè) PEIM，它會(huì)掃描已發(fā)布的 PPI 的 PPI 數(shù)據(jù)庫(kù)，
在尚未分發(fā)的 PEIM 的 depex 中搜索元素。
如果 depex 中的所有元素都在 PEI 基金會(huì)的 PPI 數(shù)據(jù)庫(kù)中，則調(diào)度 PEIM。
當(dāng)所有 PEIM 都被掃描并且沒(méi)有被調(diào)度時(shí)，該階段終止。

5.8.1.2 多固件卷支持

為了暴露新的固件卷，PEIM 應(yīng)該安裝一個(gè) EFI_PEI_FIRMWARE_VOLUME_INFO_PPI 實(shí)例，
其中包含固件卷格式 GUID、起始地址和固件卷窗口的大小。
公開(kāi)固件卷格式而不是 PI 架構(gòu)固件卷格式的固件卷的 PEIM 應(yīng)在其依賴項(xiàng)表達(dá)式中包含固件卷格式 GUID。
如果固件卷在 PEI 內(nèi)存之外，則暴露內(nèi)存映射固件卷的 PEIM 應(yīng)為固件卷占用的內(nèi)存創(chuàng)建內(nèi)存資源描述符 HOB。

對(duì)于每個(gè)新公開(kāi)的固件卷，PEI 基金會(huì)將采取以下步驟：

1. 創(chuàng)建新的固件卷句柄。 固件卷句柄可以由 PEI 基金會(huì)或可選的 EFI_PEI_FIRMWARE_VOLUME_PPI 創(chuàng)建。
2. 創(chuàng)建一個(gè)新的固件卷 HOB。
3. 如果 PEI 基金會(huì)不直接支持固件卷的格式（由其 GUID 標(biāo)識(shí)），并且任何已安裝的 EFI_PEI_FIRMWARE_VOLUME_PPI 都不支持，則跳過(guò)固件卷。
4. 否則，固件卷中的所有 PEIM 都被調(diào)度調(diào)度。
5. 查找先驗(yàn)文件（如果存在），并分發(fā)其中列出的任何 PEIM。

5.8.2 要求

5.8.2.1 調(diào)度算法要求

調(diào)度算法必須滿足以下要求：

1. 保持調(diào)度弱排序。
2. 防止無(wú)限循環(huán)。
3. 控制處理器資源。
4. 保持正確的分發(fā)順序。
5. 利用可用內(nèi)存。
6. 調(diào)用每個(gè) PEIM 的入口點(diǎn)。
7. 知道 PEI Dispatcher 任務(wù)何時(shí)完成。

5.8.2.2 保留弱排序

算法必須保留 depex 隱含的弱排序。

5.8.2.6 使用可用內(nèi)存

PEI 基金會(huì)使用臨時(shí)內(nèi)存存儲(chǔ)開(kāi)始操作，該存儲(chǔ)包含來(lái)自安全 (SEC) 階段的初始調(diào)用堆棧。
SEC 階段必須傳遞堆棧的大小和位置以及臨時(shí)內(nèi)存存儲(chǔ)的大小和位置。
PEI 堆?？捎糜诤罄m(xù)的 PEIM 調(diào)用，而 PEI 堆將用于 PEIM 內(nèi)存分配和切換塊 (HOB) 創(chuàng)建。
在 PEIM 使用 PEI 服務(wù) InstallPeiMemory() 注冊(cè)永久內(nèi)存范圍之前，不能有內(nèi)存寫(xiě)入超出此初始臨時(shí)內(nèi)存的地址空間。
當(dāng)安裝永久內(nèi)存時(shí)，PEI 基金會(huì)會(huì)將位于臨時(shí)內(nèi)存中的調(diào)用堆棧復(fù)制到一段永久內(nèi)存中。
如有必要，可以擴(kuò)展調(diào)用堆棧的大小，以支持后續(xù)過(guò)渡到 DXE。
除了調(diào)用堆棧之外，PEI 基金會(huì)還將以下內(nèi)容從臨時(shí)內(nèi)存復(fù)制到永久內(nèi)存：

• PEI 基金會(huì)私有數(shù)據(jù)
• PEI 基金會(huì)堆
• HOB 列表
• 已安裝的固件卷

將描述 PEI 基金會(huì)以這種方式消耗的任何永久內(nèi)存在 PEI 基金會(huì)將創(chuàng)建的 HOB 中。

PEI 基金會(huì)會(huì)將任何已安裝的固件卷從臨時(shí)內(nèi)存位置復(fù)制到永久內(nèi)存位置，并按照固件卷標(biāo)頭中指定的對(duì)齊方式進(jìn)行。
這些固件卷中 PEIM 中任何未壓縮的 PE32 或 TE 部分都將被修復(fù)。
這確保這些 PEIM 中的任何靜態(tài) EFI_PEI_PPI_DESCRIPTOR 或 PPI 接口指針指向永久內(nèi)存地址。

此外，如果在臨時(shí)內(nèi)存堆中創(chuàng)建了任何 EFI_PEI_PPI_DESCRIPTOR 或在 PEIM 中靜態(tài)聲明，
則它們各自的位置已被轉(zhuǎn)換為偏移量，該偏移量等于臨時(shí)內(nèi)存中的原始位置與永久內(nèi)存中的目標(biāo)位置之間的差值。
除了這個(gè)堆副本，PEI 基金會(huì)還會(huì)遍歷 PEI PPI 數(shù)據(jù)庫(kù)。
任何對(duì)臨時(shí)內(nèi)存中 EFI_PEI_PPI_DESCRIPTORs 的引用將由 PEI 基金會(huì)修復(fù)，
以反映 EFI_PEI_PPI_DESCRIPTORs 目的地在永久內(nèi)存中的位置。

PEI 基金會(huì)將在調(diào)度所有候選 PEIM 后調(diào)用 DXE IPL PPI。
DXE IPL PPI 可能必須從永久內(nèi)存中分配額外的區(qū)域，以便能夠從其固件存儲(chǔ)中加載和重新定位 DXE Foundation。
DXE IPL PPI 將在適當(dāng)?shù)?HOB 中描述這些內(nèi)存分配，以便當(dāng)控制權(quán)傳遞給 DXE 時(shí)，DXE 基金會(huì)將知道內(nèi)存使用的準(zhǔn)確記錄。

5.8.2.7 調(diào)用 PEIM 的入口點(diǎn)

PEIM 的入口點(diǎn)使用 UEFI 2.0 規(guī)范中指定的調(diào)用約定，其中詳細(xì)說(shuō)明了如何將參數(shù)傳遞給函數(shù)。
在評(píng)估 PEIM 的依賴表達(dá)式以查看它是否可以被調(diào)用后，PEI 基金會(huì)會(huì)將控制權(quán)傳遞給 PEIM 的入口點(diǎn)。
該入口點(diǎn)是在 PEIM 的圖像標(biāo)頭中描述的值。

PEI 基金會(huì)在調(diào)用 PEIM 時(shí)將傳遞一個(gè)指向 PEI 服務(wù)表和固件文件句柄的間接指針。
在 PEIM 的入口點(diǎn)，PEIM 有機(jī)會(huì)執(zhí)行以下操作：

• 定位其他 PPI
• 在此 PEIM 的主體內(nèi)安裝引用服務(wù)的 PPI
• 注冊(cè)通知
• 從 PEIM 的入口點(diǎn)返回后，它返回 到 PEI 基金會(huì)。
• 有關(guān) PE 的信息，請(qǐng)參閱 Microsoft Portable Executable and Common Object File Format Specification

5.8.4 當(dāng)內(nèi)存存在時(shí)分派

PEI 執(zhí)行階段的目的是發(fā)現(xiàn)和初始化主內(nèi)存。
在幾種情況下，PEIM 的陰影和將該圖像重新定位到內(nèi)存中是有意義的。
這可以包括但不限于壓縮 PEIM，例如 DXE IPL PPI、危機(jī)恢復(fù)所需的那些模塊以及從臨時(shí)內(nèi)存執(zhí)行代碼的平臺(tái)。
PEI 架構(gòu)不應(yīng)規(guī)定要使用什么壓縮機(jī)制，但某些 PEIM 會(huì)發(fā)布一個(gè)解壓縮服務(wù)，PEI 基金會(huì)將在該服務(wù)可用時(shí)發(fā)現(xiàn)并使用該服務(wù)。
此外，加載圖像還需要完整的圖像重定位服務(wù)和刷新緩存的能力。
前者將允許重定位到 RAM 中的 PEIM 根據(jù)新的加載地址調(diào)整其重定位。
后一種服務(wù)將由 PEI 基金會(huì)調(diào)用，以便可以運(yùn)行重新定位的代碼，
尤其是在沒(méi)有一致數(shù)據(jù)和代碼緩存的基于 Itanium 的平臺(tái)上。
壓縮部分應(yīng)隱含依賴于已安裝的永久內(nèi)存。
但是，為了加快啟動(dòng)時(shí)間，可以對(duì)該依賴項(xiàng)進(jìn)行顯式注釋

5.8.5 PEIM Dispatching

5.8.6 PEIM Authentication

6 Architectural PPIs