前言

上一章我們講了ug1137的第5章和第6章，兩章實質上的內容也很少，也還都是介紹性的內容。這一章我們來閲讀第7章節，有關係統引導的章節，這一章的內容非常非常多，所以可能很多我覺得不重要的地方我可能都不進行翻譯了，就只提一句了，我們下面開始。

Chapter 7: System Boot and Configuration 系統引導和配置

這一章節講的東西很多，歸納來看有這幾個方面：

• 引導過程
• 引導鏡像創建
• 引導模式
• FSBL的建立過程

我們下面就按照文檔分節來講。

7.1 Boot Process Overview 引導過程概述

這一節描述了引導過程的三個階段，原文描述的很詳細，我這裏直接翻譯原文：

平台管理單元（PMU）和配置安全單元（CSU）管理和執行多階段引導。您可以以安全（使用經過驗證的引導鏡像）或非安全（使用未經驗證的引導鏡像）模式引導設備。引導階段如下：

• 預配置階段(Pre-configuration stage)：PMU主要控制運行PMU ROM以設置系統的預配置階段。PMU控制與復位和喚醒相關的所有過程。
• 配置階段(Configuration stage)：該階段負責將PS的第一階段引導加載程序（FSBL）代碼加載到片上RAM（OCM）中。它支持安全和非安全啓動模式。通過引導頭，您可以在Cortex®-R5F-0/R5-1處理器或Cortex®-A53處理器上執行FSBL。Cortex-R5F-0處理器還支持鎖步模式。
• 後配置階段(Post-configuration stage)：FSBL執行開始後，MPSoC進入後配置階段。

這裏可以看到，在第一階段，PMU會首先執行PMU ROM以完成預配置，然後第二階段才會加載FSBL到OCM中進行執行，我們在之前的章節的一個NOTE中就提到FSBL的代碼在編譯完成後需要被標記到OCM的特定地址才能正常執行。在第三階段則是完成了FSBL的配置。

7.2 Boot Flow 啓動流

這一小節就是緊跟着上一小節的概述，開始詳細描述引導過程了。引導主要分為兩種引導方式，非安全引導和安全引導，但兩種方式都遵循一個共同的流程，這個共同的流程如下：

能看到，在這共同的流程中，PMU最先運行，在釋放CSU後就進行功耗監控而把工作轉交給CSU，CSU則加載FSBL到OCM，之後將工作轉交給RPU並進行篡改監控，RPU則正式的執行FSBL，FSBL執行後就可以開始執行APU任務了，圖中的任務有ATF(Arm Trusted Firmware)，U-Boot，Linux三個。

下面就詳述非安全和安全的引導流程。

7.2.1 Non-Secure Boot Flow 非安全引導流程

原文描述如下：

在非安全引導模式下，PMU釋放配置安全單元（CSU）的復位，並進入監控電源的PMU服務模式。在PMU將CSU從復位中釋放後，CSU將FSBL加載到OCM中。PMU硬件將運行PMU RAM，該過程將同步於FSBL在OCM中運行。FSBL在APL或RPU上運行。FSBL在APL/RPU和TF-A上運行; U-Boot和Linux在APU上運行。其他引導配置允許RPU完全獨立於APU啓動和運行，反之亦然。

• 在APU上，TF-A將在FSBL移交給TF-A後執行。TF-A移交給U-Boot等第二階段引導加載程序，該加載程序執行和加載Linux等操作系統。
• 在RPU上，FSBL將移交給軟件應用程序。
• Linux反過來加載可執行軟件。

7.2.2 安全引導流程 Secure Boot Flow

原文描述如下：

在安全引導模式下，PMU釋放配置安全單元（CSU）的復位，並進入用於監視電源的PMU服務模式。PMU將CSU從復位中釋放後，CSU將檢查以確定FSBL或用户應用程序是否需要身份驗證。
CSU採取以下措施：

• 執行身份驗證檢查，並僅在身份驗證檢查通過時繼續。然後檢查圖像是否有任何加密分區。
• 如果CSU檢測到已加密的分區，CSU將執行解密並將FSBL加載到OCM中。

運行在APU上的FSBL將移交給TF-A。在RPU上運行的FSBL加載TF-A。在這兩種情況下，TF-A都會加載U-Boot，U-Boot會加載OS。然後TF-A執行U-Boot並加載Linux等操作系統。然後Linux反過來加載可執行軟件。同樣，FSBL檢查其嘗試加載的每個分區的身份驗證和加密。FSBL僅在成功驗證和解密（如果之前加密）後才加載分區。

可以看到，兩種引導其在流程上並沒有本質的區別，主要的區別在於安全引導下CSU會進行FSBL的檢查和應用程序身份的檢查，還有對加密FSBL內容的解密，然後FSBL接手對後續分區的身份驗證和解密，然後加載這些分區，而非安全引導是直接進行執行的。

7.3 Boot Image Creation 引導鏡像創建

這一節主要是講了鏡像創建工具Bootgen的用途和使用方法，也都是介紹性的內容，而且我對安全驗證的內容不熟，所以就還是以原文翻譯為主：

Bootgen是一個工具，可以讓您將二進制文件縫合在一起並生成設備引導圖像。Bootgen定義了在創建在設備中使用的引導圖像時輸入的多個屬性、屬性和參數。

設備的安全引導功能使用公鑰和公鑰加密算法。Bootgen為每個分區提供特定目標內存地址的分配和對齊要求。它還支持加密和身份驗證，如Bootgen User Guide (UG1283)中所述。Bootgen User Guide (UG1283)的“Using HSM Mode”部分討論了更高級的身份驗證流程和密鑰管理選項，其中Bootgen可以輸出中間哈希文件，這些文件可以使用私人密鑰離線簽名，以簽署引導圖像中包含的身份驗證證書。該程序通過將標頭塊添加到分區列表來組裝引導鏡像。

可選地，每個分區都可以使用Bootgen進行加密和驗證。輸出是一個可以直接編程到系統的引導閃存中的單個文件。

該工具可以生成各種輸入文件以支持身份驗證和加密。

Bootgen同時配備了一個圖形界面和一個命令行選項。該工具集成到軟件開發工具包集成開發環境（IDE）中，用於使用GUI生成基本引導映像，但大多數Bootgen選項都是命令行驅動的。命令行選項可以編寫腳本。Bootgen工具由引導映像格式（BIF）配置文件驅動，文件擴展名為 *. bif。與SoC、自適應SoC和Bootgen一起，它能夠為以後的FPGA加密和驗證分區，如FPGA支持中所述。除了定義引導鏡像行為的支持命令和屬性外，還有一些實用程序可以幫助您使用Bootgen。Bootgen代碼現已在GitHub上提供。

總的來説，Bootgen用於為不同分區提供執行地址以及對該分區的加密功能，這部分還有一小節是創建鏡像文件的步驟，但是內容比較少其比較基礎，這裏就不寫了，具體在第57頁。

7.4 Boot Modes 引導模式

這一章大致介紹了幾種用於boot的外部存儲設備，但是在本節開頭也聲明瞭這些介紹並不完整，要進行細緻的瞭解還是要看技術參考手冊，不過我們還是挑稍微重點的內容來翻譯一下：

7.4.1 QSPI24 and QSPI32 Boot Modes

BootROM在x8模式下搜索前256Mb。在QSPI24和QSPI32引導模式下（QSPI24/32設備<128Mb），要使用MultiBoot，請放置多個鏡像，使其適合小於128 Mb的內存位置。QSPI24引導模式的管腳配置為0x1。

Note1：不支持QSPI雙堆疊（x8）引導。僅支持QSPI單傳輸速率（STR）。單個Quad-SPI內存（x1、x2和x4）是唯一支持就地執行（XIP）的引導模式。
Note2:QSPI24引導模式的管腳配置為0x1，QSPI32為0x2。

7.4.2 SD Boot Mode

Note：FSBL和U-Boot中的SD引導不支持exFat。
下圖顯示了在SD模式下引導Linux的示例。

IMPORTANT! 要從SD1啓動，請將啓動管腳配置為0x5。要從SD0啓動，請將啓動管腳配置為0x3。要從帶有level shifter的SD啓動，請將啓動管腳配置為0xE。

7.4.3 eMMC18 Boot Mode

下圖顯示了以eMMC18模式啓動Linux的示例。
(PS:我發現和SD那張圖一模一樣，不過確實兩者都是用SD協議)

7.4.4 NAND Boot Mode

NAND Boot僅支持8位寬度來讀取引導鏡像，並支持MultiBoot的鏡像搜索。下圖顯示了以NAND模式啓動Linux的示例。

IMPORTANT! 要使用NAND引導，請將引導管腳配置為0x4

7.4.5 JTAG Boot Mode

您可以使用JTAG手動下載PS所需的任何軟件鏡像和PL上的任何硬件鏡像。有關TAG引導模式設置，請參閲Zynq UltraScale+ Device Technical Reference Manual (UG1085).中的“Boot Modes”部分。

IMPORTANT! JTAG模式下不支持安全引導。

7.4.6 USB Boot Mode

USB引導模式僅支持USB2.0。在USB引導模式下，支持安全和非安全引導模式。DDR-less系統不支持USB引導模式。不支持Multi Boot、後備鏡像和XIP等功能。

USB啓動模式需要一台安裝了dfu-utils的主機PC。主機和設備需要通過USB2.0或USB3.0電纜連接。主機必須包含一個要由bootROM加載的boot.bin，其中只包含fsbl.elf和另一個要由FSBL加載的boot_all.bin。在USB引導模式下啓動電路板時，發出以下命令：

• 在Linux主機上：

• dfu-util-D Boot.bin：這將文件下載到設備，由BootROM處理。
• dfu-util-D Boot_all.bin：這將文件下載到設備，由FSBL處理。

在Windows主機上：

• dfu-util. exe-D Boot.bin：這將文件下載到設備，由BootROM處理。
• dfu-util. exe-D start_all.bin：這將文件下載到設備，然後由FSBL處理。

7.5 Detailed Boot Flow 詳細的引導流程

這一節比較重要，是MPSOC啓動流程的具體描述，這一節我也會重點的來分析。首先我們要複習一下，在之前的啓動流程概述中提到過MPSOC的啓動有三個階段，預配置階段(Pre-configuration stage)，配置階段(Configuration stage)和後配置階段(Post-configuration stage)。

這其中的預配置階段(Pre-configuration stage)主要是由PMU（平台管理單元）來進行控制的，具體描述如下：

PMU ROM將在引導期間從ROM執行，以配置設備的默認電源狀態、初始化RAM以及測試內存和寄存器。在PMU執行這些任務並將系統控制權移交給配置安全單元（CSU）後，它將進入服務模式。在此模式下，PMU響應由系統軟件通過寄存器接口或由硬件專用I/O發出的中斷請求，以執行平台管理服務。

下面我們來看預配置階段(Pre-configuration stage)的詳細步驟。

7.5.1 Pre-Boot Sequence 預引導步驟

預引導階段的PMU其任務序列如下圖：

我們來簡要分析一下，PMU會使能並激活一大堆的基礎設備，例如LPD，FPD，PLL以及供電等等，在完成這些任務後，就會是否CSU單元使其進行工作，或者進入發生錯誤模式，然後進入服務模式開始進行功耗監控，而在CSU復位被釋放後，CSU會馬上執行bootROM並執行下面的任務：

1. 初始化OCM。
2. 通過讀取引導模式寄存器來確定引導模式，該寄存器會在POR(上電覆位)時捕獲引導模式管腳。
3. CSU繼續執行FSBL負載和可選的PMU Firmware負載。PMU Firmware是可以由PMU單元執行的軟件，其在PMU的RAM中執行。

具體的執行流程如下圖所示，我已經在圖中做了對應的中文註釋：

7.6 Disabling FPD in Boot Sequence 在引導序列中失效FPD(Full Power Domain)

這一節的內容是講在引導時為了防止FPD短暫的上電造成的FPD鎖定的操作，具體如下：

執行以下操作以避免暫時施加FPD電源時發生FPD鎖定：

• 通電直到BootROM執行完成。
• To power down the FP during FSBL execution, set FPD bit '22' of PMU_GLOBAL REQ_PWRDWN_STATUS register.
• To bring the FP domain up in a later stage of the boot process, set the PMU_GLOBAL REQ_PWRUP_STATUS bit to '22’.
  （PS：最後這兩句我沒翻譯，因為我也沒看懂原文到底是要説講該寄存器置位22還是説置位寄存器的第22位，這裏就放原文大家自己判別）

如果FSBL啓動前未施加FPD電源，請執行以下操作

1. 啓動R5。
2. 一個寄存器被置位來指示FPD由於復位或清除命令無法執行而被鎖定，只能等待POR。
3. R5可以從SAL_GLOBAR_ISO_SAL寄存器第4位來讀取FP鎖定狀態。
4. 在此階段，將不會置位SAL_GlobAL RST_PWURA_SAL位22。
5. 要恢復FPD節點，必須向該節點供電併發出POR。

7.7 Setting FSBL Compilation Flags 設置FSBL編譯標誌

這一部分內容是為了解決MPSOC引導中的兩個問題，一個是FSBL文件過大的問題，另一個是需要多個鏡像文件進行引導的問題，我們來一個個解決。

首先是FSBL文件過大的問題，這個問題可以通過設置編譯標誌，將一些不需要的內容隔離在編譯之外，從而縮小FSBL文件大小，具體的設置界面和標誌類型如下面兩張圖所示，這裏不翻譯了：

通過設置標誌去除某些不需要的代碼，就能減少編譯文件的大小，這裏有一點注意事項：

Note:無需更改任何FSBL源文件或頭文件來包含這些標誌。

7.7.1 Fallback and MultiBoot Flow

這一小節就是講如何進行fallback boot（備份引導）和multiboot（多引導），這部分原文介紹比較關鍵，我們來看原文：

在AMD Zynq UltraScale+ MPSoC中，CSU BootROM支持MultiBoot和後備引導鏡像搜索，其中配置安全單元CSU ROM或BootROM搜索引導設備，尋找要加載的有效鏡像。順序如下：

• BootROM在flash中以32KB的偏差搜索有效圖像識別字符串（XLNX作為圖像ID）。
• 找到有效的標識值後，驗證標識頭的校驗和。
• 如果檢驗和有效，則BootROM加載該鏡像。這允許flash中出現多個鏡像。

也就是説，CSU中的bootROM會自動在flash(這泛指閃存存儲器)中鏡像鏡像的搜索，在搜索到第一個鏡像後，就進行校驗，校驗成功則加載鏡像進行執行（按照流程應該會加載FSBL到RPU執行）。我們再來看multiBoot的原文：

在進行multiBoot時：

• CSU ROM或FSBL或用户應用程序必須啓動引導鏡像搜索以選擇要引導的不同鏡像。
• 要啓動此鏡像搜索，CSU ROM或FSBL更新MultiBoot偏置以指向預期的引導圖像，並通過寫入CRL_APB寄存器來生成軟重置。

下圖顯示了使用MultiBoot進行回退的示例

在示例後備引導流程圖中，發生以下序列：

• 最初，CSU BootROM加載位於0x000_0000處的引導鏡像。
• 如果發現此鏡像已損壞或解密和身份驗證失敗，CSU BootROM將MultiBoot偏差增加一，並在0x000_8000（32KB偏差）處搜索有效引導圖像。
• 如果CSU BootROM找不到有效的標識值，它將再次將MultiBoot偏差增加1，並在下一個32 KB對齊地址處搜索有效的引導圖像。
• CSU BootROM重複此操作，直到找到有效的引導圖像或達到圖像搜索限制。在此示例流程中，下一個圖像顯示在0x002_0000處，對應於MultiBoot偏置值四。
• 在示例MultiBoot流中，要加載地址0x002_0000處的第二個鏡像，FSBL/CSU-ROM將MutiBoot偏差更新為4。更新MultiBoot偏差時，軟重置系統。

下表顯示了不同引導設備的MultiBoot圖像搜索範圍。

我現在來總結下multiBoot的流程，如果我們要使用multiBoot，就需要在特定的以32KB為偏置的位置上放置鏡像，CSU ROM會依據32KB的偏置從低地址到高地址進行鏡像搜索，如果搜索到鏡像頭則進行解析驗證然後執行，而且要注意的是，CSU ROM在不同的存儲設備上能夠搜索的範圍是有限的，也就是我們針對不同器件所能進行的multiBoot有限。

7.8 FSBL Build Process FSBL構建流程

這一節講了FSBL的構建和其具體的執行流程，也是比較重要的內容，我先翻譯一下本節開篇，內容比較重要，原文如下：

（CSU）驗證和/或解密後，FSBL被加載到OCM中並由CSU BootROM移交。第一階段引導加載程序(FSBL)用比特流（如果存在）配置該FPGA，並將Standalone（SA）鏡像或第二階段引導加載程序圖像從非易失性存儲器（NAND/SD/eMMC/QSPI）加載到RAM（DDR/TCM/OCM）。它會使Cortex-R5F-0/R5F-1處理器或Cortex-A53處理器單元脱離復位。它支持多個分區。每個分區可以是代碼鏡像或比特流。如果需要，這些分區中的每一個都將被認證和/或解密。

注意：如果您正在創建自定義FSBL，則應該注意OCM大小為256KB，並且可用於CSU BootROM。FSBL大小接近170KB，適合OCM。使用USB引導模式時，您應確保由FSBL而不是CSU bootROM加載PMU firmware(PS：PMU firmware是一段運行在PMU RAM中的軟件)。這是因為CSU BootROM加載的Boot.bin大小應該小於256 KB。

注意：即使設計中存在DDR，用户也可以從OCM加載未加密的情況下的比特流。默認情況下，在xfsbl_config.h中，FSBL_PL_ADD_OF_OCM_EXCLUDE_VAR值設置為0，從而在未加密的情況下使比特流從DDR複製和加載。通過將FSBL_PL_ADD_LOS_OCM_EXCLUDE_VAR值設置為1，用户可以確保從OCM塊加載比特流，而不是從DDR加載比特流。此外，如果設計中不存在DDR，則無論FSBL_PL_ADD_LOS_OCM_EXCLUDE_VAR值如何，都將從OCM加載比特流。

7.8.1 Creating a New Zynq UltraScale+ MPSoC FSBL Application Project

沒實際內容不説了。

7.8.2 Phases of FSBL Operation FSBL運行階段

這一小節講了FSBL運行過程中的具體流程，我們來詳細看一下。

首先FSBL在運行時主要有四個階段:

• 初始化
• 引導設備(如SD，eMMC，QSPI)初始化
• 加載分區
• 移交（也就是將代碼執行移交給APU或RPU）

下面這張圖表展示了各個階段的運行，內容比較直白我就沒做標註：

這裏我用文字稍微解釋一下，在CSU將運行移交到FSBL後，FSBL會進行如之前所説的4階段運行步驟，這4步的內容都寫在左下角方框內了，而一旦每個階段執行出來問題，就會轉入黑圈所示的狀態，如果此時沒有後備鏡像可以加載，則運行會直接結束，否則應該會回到CSU加載鏡像的狀態，而如果四個步驟都正常，則程序會正常的被移交給APU或者RPU的應用程序。

文檔下面的內容是挨個階段的介紹每個階段下FSBL會運行什麼代碼並執行什麼操作，且每個操作中又有對應的流程圖指示該操作的流程，內容非常繁雜，而且我也沒有完全理解，為了內容精簡，我就不再貼流程圖了，只是對每個步驟的原文描述進行翻譯了，具體的內容要參考ug1137的原文，我會將每個步驟寫成小小節以便於在目錄中查看流程。

7.8.2.1 Initialization 初始化

初始化階段有着4個內部階段：

7.8.2.1.1 XFsbl_SystemInit

該功能為1.0和2.0silicon的PL供電，並消除PS-PL隔離。它按照psu-init中的規定來初始化時鐘和外圍設備。該函數在僅復位的APU中不被調用。

7.8.2.1.2 XFsbl_ProcessorInit

處理器初始化將在此階段開始。它將為R5-0設置指令和數據緩存、L2緩存、MMO設置、堆棧指針（如果是A53的話還有I/D緩存）、MPU設置、內存區域、堆棧指針和TCM設置。這些設置中的大部分將在BSP代碼初始化中執行。如果處理器為是A53，IVT（應該是中斷向量表）向量指向OCM的起點，如果是R5-0，IVT指向為TCM的起點（lowvec中為0x0，highvec中為0xffff000）。

7.8.2.1.3 Initialize DDR

DDR將在此階段初始化。該函數在Master only reset中不會被調用。

7.8.2.1.4 XFsbl_BoardInit

此功能執行所需的開發板特定初始化。最重要的是，它配置GT（Gigabit Transceiver）通道和IIC。

7.8.2.2 Boot Device Initialization 引導設備初始化

7.8.2.2.1 XFsbl_PrimaryBootDeviceInit

此階段涉及讀取引導模式寄存器以識別主引導設備並初始化相應的設備。每個引導設備驅動程序都提供init、copy和release函數，這些函數在此階段被初始化為DevOps函數指針。

7.8.2.2.2 XFsbl_ValidateHeader

使用提供的複製函數，FSBL讀取引導標頭屬性和鏡像偏置地址。它讀取EFUSE位來檢查身份驗證。它讀取鏡像標頭並驗證鏡像標頭表。然後，它讀取鏡像標頭的Partition Present File屬性。非零值表示次級引導設備。零值表示次級引導設備與主引導設備相同。

7.8.2.2.3 XFsbl_SecondaryBootDeviceInit

當圖像頭表的Partition Present Unit屬性非零值時，調用該函數。它初始化輔助引導設備驅動程序，輔助引導設備將用於通過FSBL加載所有分區。
XFsbl_SetATFHandoffParams
假設TF-A是FSBL之後的下一個可加載的分區。它能夠加載U-Boot和安全操作系統，因此，它傳遞了切換結構。

應用程序的第一個分區將具有非零執行地址。該應用程序的所有剩餘分區將以0作為執行地址。因此，為不是第一個分區的分區查找非零執行地址，並確保CPU為A53。

此函數將切換參數設置為Trusted Firmware-A（TFA）。第一個參數取自FSBL分區頭。指向包含這些參數的切換結構的指針存儲在TF-A讀取的PMU_GLOBAL.GLOBAL_GEN_STORAGE6寄存器中。該結構填充了magic characters“X”、“L”、“N”和“X”，後面是分區總數和每個分區的執行地址。

7.8.2.3 Partition Loading 分區加載

7.8.2.3.1 XFsbl_PartitionHeaderValidation

分區標頭通過各種檢查進行驗證。所有所需的分區變量都會在此階段更新。如果分區所有者不是FSBL，則分區將被忽略，FSBL將繼續加載其他分區。

7.8.2.3.2 XFsbl_PartitionCopy

分區將被複制到DDR或TCM或OCM或PMU RAM。

7.8.2.3.3 XFsbl_PartitionValidation

分區將根據分區屬性進行驗證。如果啓用了校驗和，則將首先驗證該分區校驗和的正確性，然後根據身份驗證標誌對其進行身份驗證。如果設置了加密標誌，則分區將被解密，然後複製到目的地。

7.8.2.4 Handoff 移交/切換

在此階段，將執行psu_inits的protection_connect函數，然後執行任何handoff功能。PS-PL隔離也被無條件取消。如果R5的核心上應該運行任何分區，則R5將退出重置。R5-0/R5-1將根據您在構建引導鏡像時提供的設置配置為以lowvec模式或highvec模式引導。lowvec模式下的移交地址為0x0，highvec模式下的移交地址為0xffff0000。構建引導鏡像時應指定Lowvec/Highvec信息。完成所有其他PS鏡像後，運行的中央處理器將通過PC值的更新來實現handoff。如果沒有鏡像要移交到中央處理器，則FSBL將進入wfe循環中。

任何正在運行的處理器都不能將任何參數傳遞給任何其他處理器。各個分區之間的任何通信都可以通過讀取（或寫入）PMU全局寄存器來發生。

正在運行的處理器上的移交操作涉及到對程序計數器（PC）的更新，類似於在對APU進行復位的情況。切換到其他處理器涉及也都涉及更新其PC並使處理器脱離復位。

7.8.2.4.1 XFsbl_PmInit

該功能初始化並配置處理器間中斷（IPI）。然後，它將PM配置對象地址寫入IPI緩衝區，並觸發目標的IPI。然後，PMU firmware讀取並配置對象中指定的設備節點。

7.8.2.4.2 Protection Configuration

在此階段，將執行psu_init中的protection_connect函數。保護的應用發生在這個階段。

7.8.2.4.3 Handoff

正在運行的處理器上的切換涉及更新正在運行的處理器的程序計數器（PC），就像在APL重置的情況下所做的那樣。切換到其他處理器涉及更新其PC並使處理器脱離重置。A53如果有任何分區可在R5上運行，FSBL將使R5退出重置。R5將根據您在構建引導鏡像時提供的設置配置為以低vec模式或高vec模式引導。低vec模式下的切換地址為0x 0，高vec模式下的切換地址為0xffff 0000。

構建引導鏡像時必須指定Lowvec/Highvec信息。完成所有其他PS鏡像後，運行的中央處理器鏡像將被移交給該中央處理器，並更新PC值。如果正在運行的中央處理器沒有鏡像，則它將處於wfe循環中。

7.8.2.4.4 Supported Handoffs

下表顯示了FSBL中支持的各種移交組合。

7.8.2.4.5 Error Lock Down

XFsbl_errorLockDown函數處理FSBL中的錯誤。每當函數的返回值不成功時，就會調用此函數。如果不支持回退(fallback)，此函數會更新錯誤狀態寄存器，然後無限期循環。

如果引導模式支持回退，則更新MultiBoot偏置寄存器，然後等待WDT復位發生。重新啓動時，BootROM和FSBL從根據MultiBoot偏差計算的新地址讀取鏡像，從而加載新鏡像。

7.8.2.5 Miscellaneous Functions 輔助函數

這個小節講了一堆FSBL中肯會用到的函數，差不多總的有十幾個，這裏就不一一介紹了，因為我感覺能夠用到的概率可能不大，所以不展開講了，具體內容常看第91~95頁

7.8.3 Using the Ethernet-Based Recovery Tool 使用基於以太網的恢復工具

這一節講了使用以太網來對MPSOC進行鏡像更新或者恢復的方法，這裏簡單翻譯一下：

SOM(system on module)解決方案堆棧包括基於以太網的恢復模式，可與主機PC上的應用程序一起使用，以提供完整的工廠QSPI鏡像重置/重新加載機制。恢復工具將保存在QSPI內存的保留部分中。之所以選擇基於以太網的恢復而不是USB，是因為許多有安全意識的客户更喜歡禁用USB，而在其應用程序中使用以太網。以太網恢復應用程序是一種運行簡化以太網堆棧的應用程序，用於與客户/工程師的主機（例如筆記本電腦）交互，以允許手動更新/重寫SOM上QSPI上的圖像A和圖像B。

除了網絡瀏覽器之外，基於以太網的恢復不需要PC上的任何增量工具。您的PC必須在其本地文件系統中具有新的硬件二進制文件。您應該能夠處理從AMD存儲庫下載相關的AMD工廠引導文件更新，而目標固裝將處理給定文件到物理地址的映射以及寫入閃存的行為。圖像恢復實用程序使用固定IP地址192.168.0.111。

基於以太網的恢復工具能夠讀取邊帶控制EEPROM以驗證SOM的品牌和型號。以太網工廠回退/恢復過程通過在通電重置序列期間按住FWUEN按鈕來啓動。該工具需要按下硬件更新按鈕才能重寫任何硬件內容。它將相應的A/B持久寄存器更新為適當的狀態。

總結

在寫這章之前我就知道boot部分的內容應該是非常多且複雜的，到真的上手寫才發現內容不僅多，而且很多地方都有些理解不了是最難受的，感覺還得加把勁學。不過學了這章還是大致理解了FSBL對器件的啓動過程，還是有幫助的。下一章節的Security Features説實話我可能會先跳過不講，因為這部分內容我確實太不熟了。我們下次再見。