在"對[我所認識的BIOS]系列 -- CPU的第一條指令 一文擴充(I)"一文中，我用EFITool工具加載了BIOS Rom，發現Reset Vector位於BIOS Rom Image的最底部。本文將探索形成這樣的Image結構相關的各種文件(.fdf/.fd/.fv等文件)。
先說說我手頭這個BIOS Rom，它由GenFv工具根據fdf文件生成:
;引自Build\Platform.fdf
[FD.ROM]
BaseAddress = 0xff300000
Size = 0xD00000
BlockSize = 0x1000
NumBlocks = 0xd00
0x0|0x30000
FV = NVRAM
0x30000|0x30000
#RAW - NVRAM_BACKUP
0x60000|0x20000
#NCB_LOGO
FILE = BootLogo/DummyNcbLogo.bin
0x80000|0x8d0000
FV = FV_MAIN_WRAPPER
0x950000|0xC0000
FV = FV_DATA
0xa10000|0x100000
FV = FV_BB_AFTER_MEMORY
0xb10000|0xe8000
FV = FV_FSP_S
0xbf8000|0x68000
#FV_FSP
FILE = Build/Fsp_Rebased_M_T.fd
0xc60000|0xa0000
FV = FV_BB
#FV Section
[FV.FV_MAIN]
BlockSize = 0x1000
NumBlocks = 0x0
...
APRIORI DXE {
INF AmiModulePkg/AmiStatusCode/StatusCodeDxe.inf
INF AmiModulePkg/AmiStatusCode/StatusCodeSmm.inf
...
}
INF AmiModulePkg/RomLayout/RomLayoutDxe.inf
INF MdeModulePkg/Core/Dxe/DxeMain.inf
INF AmiModulePkg/Bds/Bds.inf
...
[FV.FV_MEFW_CAPSULE]
BlockSize = 0x1000
NumBlocks = 0x600
...
!include AmiModulePkg/Ofbd/Meud/AutoMeud/MeRegionFdfFileStatement.txt
[FV.NVRAM]
BlockSize = 0x1000
NumBlocks = 0x30
...
!include AmiModulePkg/NVRAM/NvramFdfFileStatement.txt
0xc60000|0xa0000
[FV.FV_MAIN_WRAPPER]
BlockSize = 0x1000
NumBlocks = 0x8d0
...
!include AmiPkg/Configuration/NestedFvMainFdfFileStatement.txt
[FV.FV_FSP_S]
BlockSize = 0x1000
NumBlocks = 0xe8
...
!include Intel/CometLakeFspBinPkg/FvFspSFdfFileStatement.txt
[FV.FV_BB]
BlockSize = 0x1000
NumBlocks = 0xa0
APRIORI PEI {
INF AmiModulePkg/AmiStatusCode/StatusCodePei.inf
...
}
...
INF MdeModulePkg/Core/Pei/PeiMain.inf
...
INF Toshiba/FwUpdate/PeiRecKeyCheck/PeiRecKeyCheck.inf
INF UefiCpuPkg/SecCore/SecCore.inf
INF AmiModulePkg/AmiStatusCode/StatusCodePei.inf
...
fdf文件的開頭部份是關鍵字[fd]，它表示完整的BIOS Rom image。還指定了BIOS的加載地址BaseAddress = 0xff300000
大小Size = 0xD00000，這與UEFITool給出的數據不謀而合：
雖然UEFITool沒有給出Bios Rom image加載地址，但是根據BIOS Rom Image位於4G空間的頂部(0xFFFFFFFF)，減去Rom Image Size就可以推得Bios Rom加載地址(就是Fdf文件中的BaseAddress=0xff300000)。
接下來形如下列內容:
Offset|Size
[RegionType]
則是在FD中開闢了一段連續空間，用來存放FV/FILE等內容。其中Offset和Size是這段空間的相對於整個FD的偏移和大小；前面UEFITool圖中"BIOS Region"中列出的每一個FFS項都可以對應到Fdf文件[FD]節中RegionType爲FV的項(畢竟只有FV纔會用到文件系統FFS)。如果仔細比對，可能會發現UEFITool中倒數第二和倒數第三個FFS的Size相加正好對應[FD]節中的FV_FSP：
0xbf8000|0x68000
#FV_FSP
FILE = Build/Fsp_Rebased_M_T.fd
我認爲造成這種現象的原因有2個:
首先，FV_FSP項的RegionType是FILE，可以包含任意內容，自然也可以包含其他的fd文件，就如NCB_LOGO項中包含了開機Logo文件；其次，fd文件又由fv組成，UEFITool又能解析fd文件，因此造成了這種FDF和BIOS Rom image不一致。其實，我們可以用UEFITool加載Fsp_Rebuild_M_T.fd，發現其中包含兩個FFS：
如果FV_FSP包含的fd文件是經過壓縮操作的，那麼我敢大膽猜測，FDF文件中RegionType爲FV的項將和UEFITool實際得到的相一致。題外話，如果哪天BIOS Rom夠大，我是不是可以在Fdf中用RegionType FILE來插入一段電影？
迴歸正題，FDF文件[FD]節之後就是大量的[FV]節，FV的主要作用就是包含組件和模塊。他們來填充[FD]節中開闢的空間。先來看一個相對簡單的FV節：FV.NVRAM，它只包含一個include語句，指向NvramFdfFileStatement.txt文件:
!include AmiModulePkg/NVRAM/NvramFdfFileStatement.txt
NvramFdfFileStatement.txt文件通過FILE指令，包含binary file：
FILE RAW = CEF5B9A3-476D-497f-9FDC-E98143E0422C {
$(OUTPUT_DIRECTORY)/Nvram.bin
}
前面我說過FV的主要作用就是填充[FD]節中開闢的空間，用這個FV節驗證一下：
1.FDF中，FV.Nvram位於Bios Rom image的開頭，Fv guid：FA4974FC-AF1D-4E5D-BDC5-DACD6D27BAEC，NvramFdfFileStatement.txt中指定的File Guid：CEF5B9A3-476D-497f-9FDC-E98143E0422C；用UEFITool加載Bios Rom image，第一個FFS(就是FV.Nvram)的Volume GUID: FA4974FC-AF1D-4E5D-BDC5-DACD6D27BAEC；再展開FFS，其中包含的唯一的文件的File Guid: CEF5B9A3-476D-497F-9FDC-E98143E0422C，這些值和FDF中的Fv Guid以及File Guid是一致的。
除了File Guid是一致的，用UEFITool解壓後得到的Nvram.bin和原始的Nvram.bin的內容也是一致的：
以上是簡單的FV的情況，有些複雜的FV中可以嵌套其他的FV，如FDF中的FV.FV_MAIN_WRAPPER，我們再來分析一下它：
[FV.FV_MAIN_WRAPPER]
BlockSize = 0x1000
NumBlocks = 0x8d0
...
!include AmiPkg/Configuration/NestedFvMainFdfFileStatement.txt
FV.FV_MAIN_WRAPPER節中內容不多，僅僅含有若干條!include語句，但是FV.FV_MAIN_WRAPPER節佔據BIOS Rom Image很大一塊空間：BlockSize*NumBlocks=0x1000*0x8d0=0x8d0000。它佔用如此多空間的原因是NestedFvMainFdfFileStatement.txt通過FILE指令包含了一塊壓縮的FV文件，而該FV文件是Dxe階段的代碼：
;NestedFvMainFdfFileStatement.txt的內容:
#Includes FVMAIN FV image
FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 $(FFS_FILE_CHECKSUM_KEYWORD) {
SECTION $(PEI_COMPRESSION_SECTION) {
SECTION FV_IMAGE = FV_MAIN
;SECTION FV_IMAGE = FV_MAIN類似指針語句，使FV_IMAGE指向FV_MAIN節，FV_MAIN節定義在platform.fdf中
}
}
;FV_MAIN節內容：
[FV.FV_MAIN]
BlockSize = 0x1000
NumBlocks = 0x0
...
APRIORI DXE { ;APRIORI DXE,DXE階段的APRIORI FILE
...
INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
INF UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
...
}
...
INF MdeModulePkg/Core/Dxe/DxeMain.inf ;Dxe入口
INF AmiModulePkg/Bds/Bds.inf ;Bds入口
...
前面找到Dxe階段的代碼，那Sec和Pei階段的代碼在哪？platform.fdf文件[fd]節中設定FV_BB節位於Bios Rom image的尾部，因此，我們可以猜測並驗證Sec模塊和Pei模塊也位於FV_BB中：
;FV_BB內容
[FV.FV_BB]
BlockSize = 0x1000
NumBlocks = 0xa0
...
APRIORI PEI { ;PEI階段的APRIORI文件
INF AmiModulePkg/AmiStatusCode/StatusCodePei.inf
...
}
...
INF MdeModulePkg/Core/Pei/PeiMain.inf ;Pei階段入口
...
INF UefiCpuPkg/SecCore/SecCore.inf ;Sec階段入口
...
INF UefiCpuPkg/CpuIoPei/CpuIoPei.inf
INF MdeModulePkg/Universal/PcatSingleSegmentPciCfg2Pei/PcatSingleSegmentPciCfg2Pei.inf
INF AmiCompatibilityPkg/CmosManager/CmosManagerPei.inf
雖然，我們已經確定Sec模塊和Pei模塊位於FV_BB塊中，但是有個問題隨之出現：SecCore.inf並不是FV_BB中最後一個模塊(夾在其他模塊之間)，所以一眼看去感覺開機時執行的第一條指令並不在SecCore模塊中，這明顯與EFI Spec相悖。更何況SecCore.inf含有ResetVector：
;SecCore.inf部分內容
[Defines]
INF_VERSION = 0x00010005
BASE_NAME = SecCore
MODULE_UNI_FILE = SecCore.uni
FILE_GUID = 1BA0062E-C779-4582-8566-336AE8F78F09
MODULE_TYPE = SEC
VERSION_STRING = 1.0
[Sources]
SecMain.c
SecMain.h
FindPeiCore.c
SecBist.c
[Sources.IA32]
Ia32/ResetVec.nasmb ;ResetVector
另外，UEFITool也明顯顯示SecCore位於Bios Rom image尾部：
fdf的設定和實際現象有差異，那一定是GenFv在生成Bios Rom image時有特殊處理。和GenFv Build Bios相關的只能查看Build.log，它記錄了從源碼到製成Rom Image的全過程，在Build.log的結尾，記錄了各個模塊在Bios Rom Image的排列位置，我發現了特殊的一處Firmware Volumon:08 No.049 類型是SECC----SecCore，屬性被標記爲VTF，Bios Rom Image中其他FV中任何模塊都不具有該屬性！：
+-----------------------------------------------------------------------------+
| Firmware Volume : 08 Location : 00C60000 Length : 0A0000 |
+---+----------------------------------------------+--------+------+-----+----+
|No | FileName/GUID |Location| Size |Attr |Type|
+---+----------------------------------------------+--------+------+-----+----+
| |FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF |00C60048|00002C| |FREE|
|000|1B45CC0A-156A-428A-AF62-49864DA0E6E6 |00C60078|0000FC| |FRFM|
|001|5B85965C-455D-4CC6-9C4C-7F086967D2B0 |00C60178|00003C| |FRFM|
|002|RomLayoutPei |00C601B8|007C12| |PEIM|
|003|PeiCore |00C67DD0|00619E| |PEIC|
...
|048|8E295870-D377-4B75-BFDC-9AE2F6DBDE22 |00CB7780|00003C| |FRFM|
| |FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF |00CB77C0|044668| |FREE|
|049|1BA0062E-C779-4582-8566-336AE8F78F09 |00CFBE28|0041D8|VTF |SECC|
+---+----------------------------------------------+--------+------+-----+----+
在PI spec Vol3中提到：
VTF是Volume Top File的縮寫，PI spec規定VTF的File Guid爲EFI_FFS_VOLUME_TOP_FILE_GUID（1BA0062E-C779-4582-8566-336AE8F78F09），必須位於firmware volume的最後一個字節。而SecCore.inf的FILE_GUID = 1BA0062E-C779-4582-8566-336AE8F78F09。看來只要某個inf指定自己FILE_GUID爲EFI_FFS_VOLUME_TOP_FILE_GUID就有機會被安排在最開始執行。
回顧對[我所認識的BIOS]系列 -- CPU的第一條指令 一文擴充(I) 和 [我所認識的BIOS]系列 -- CPU的第一條指令 一文擴充(II)兩篇文章，我們從開機第一條指令講到了整個Bios Rom Image，後面我將再寫一篇文章，簡單說說如何從源碼生成Bios Rom Image。
Reference：