对[我所认识的BIOS]系列 -- CPU的第一条指令 一文扩充(II)：从FDF到Bios Rom image

原创 于 2020-05-03 15:52:57 发布 · 3k 阅读 · 20 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文深入探讨BIOSRomImage的结构，解析由GenFv工具根据FDF文件生成的BIOSRom，包括各部分如FV、FILE的布局及功能，揭示了BIOS启动过程中的关键模块SecCore的位置与作用。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

在"对[我所认识的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：

BIOS/UEFI基础——FDF文件

深入UEFI内核

Eugene800
关注
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值