在"對[我所認識的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: