BIOS知识枝桠——FV

基本概念

FD：固件设备，指任何可以存储固件的设备或设备的集合，它存储代码和数据。
FV：固件卷，指在FD上一个连续的部分，我们可以把它看成一个逻辑设备，因为我们代码真正操作的是FV，而非FD。我们经常提到的FFS的概念也是以FV的形式存在，它描述了FV中的文件组织方式。FV之于FD，类似于thread之于package。
FF：固件文件，指在FV中组织代码和数据的一个集合。我们在PEI和DXE阶段都要Dispatch Modules，这个Modules指的就是FF。

相较于文件系统要考虑目录、文件等更多内容，FV并不是特别复杂，主要是把一些code 、drive 、date等整合在一起更好的进行存储，发现，修改。最终生成的BIOS image 就是FD(实际上就是FV拼接而成的)、 Fv(PEI Spec定义的标准的固件存储格式）。

架构组成

每个FV的各种文件组织在一起可以看做一个简化版的文件系统，虽然不是按照目录结构存放的但也有自己的层级结构，FV再往下面是FS，FV是由FS组成的，每个FS都有自己的一个GUID、Type描述着自己包含的是什么类型，有什么数据，；FS再往下便是Firmware File又称为section；这个section才是清晰地展现了里面到底存放的是数据或是其他information。下图详细讲述了该结构：

UEFI Firmware文件结构定义可参考:PiFirmwareVolume.h (\mdepkg\include\pi) PiFirmwareFile.h (\mdepkg\include\pi)

Flash通常都Memory map到最顶端，4GB-32MB(/16MB),FLASH Device简称就是FD,上图明显的看出来FD是由一组FV组成，每个FV都有自己的File System Guid 和FV name GUID，File system Guid指的是表示自己是什么样的格式存储在header里，有些FV是属于标准格式下的FV,包含File以及后续的Section，在同一个FV里面的File都有各自的GUID且不能相同，还有Variable FV里面存的都是Variable数据，是两种不同的格式，Section存储不同的数据，不需要GUID且Section是可以进行内部嵌套的。

上图为SPEC中的一张，从另一个角度展示了Firmware File Section之间的联系，外面的蓝色框框代表着FS，里面包含了E0,L3，E1这三个Section，E0包含了L0，L1，L2三个Section。同理E2处于E3中的同时又包含了L4,L5这两个Section，可以证明，Section之间是可以嵌套的但同时也带来了一定的复杂性，而File和FV是并行的没有嵌套的，但同时，FV也是有可能嵌套在Section中的。

File Type&Section Type

在file中，Guid只是起一个标识作用，没有其他含义，但是自己的属性都是由File Type标识出来的，比如说ACPI Table会存在Freeform这种的File Type中。Raw类型的数据存储是不需要section的。

• FFS File Type
  • EFI_FV_FILETYPE_RAW
  • EFI_FV_FILETYPE_FREEFORM
  • EFI_FV_FILETYPE_PEIM
  • EFI_FV_FILETYPE_DRIVER
  • EFI_FV_FILETYPE_APPLICATION
  • EFI_FV_FILETYPE_SMM
  • EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE
• Section Type
  • EFI_SECTION_PE32
  • EFI_SECTION_DXE_DEPEX/EFI_SECTION_PEI_DEPEX/EFI_SECTION_SMM_DEPEX
  • EFI_SECTION_USER_INTERFACE
  • EFI_SECTION_RAW
  • EFI_SECTION_FIRMWARE_VOLUME_IMAGE
    Dispatch就是通过File Type 和Section Type遍历FV后进行加载。
    上图为网络图片，展示了FV的树状结构，由FV到Section层级结构的示例显示。每个driver对应过来就是一个FS。

FV的访问

在PEI阶段，FV的访问是通过FvInfoPpi这个PPI，这个PPI是由platform上报给Peicore,PEIcore里会有一个FvPpi作用于标准的FV进行检测发现FV的内容。另一种方式是通过Hob，在PEI阶段发现的尚未使用的FV会生成HOB表存储信息，等到DXE阶段的时候再进行使用。

DXE在拿到这个hob之后，会先生成FVB protocol 然后再生成FV protocol 这个FV protocol就很像PEI阶段的FV ppi，这个FV Protocol就对这个FV进行管理，对FV数据进行操作，中间的FVB可读可写，如果说这一块block空间存储的是FV格式的数据，是PEI flow，spec 规定的格式的，则会继续创建FV protocol 如果不是的话则不会创建。基于FVB才能对variable进行操作，FVB 相当于直接对FLASH按照block方式进行读写擦除，所以FV protocol支持的肯定是PEIspec支持的标准的数据格式，而FVB只是基于此段空间提出了一个比较low level的操作，只能进行简单的原始操作，至于本段数据类型的数据结构是不知道的。

FV除了在FLASH上也可以存在于其他存储空间，Dispatcher和BDS可以使用FV、File或network来查找所需组件 ，也可以根据平台需求更改包装。

FV拓展 EFI IMAGE (PE/COFF)

• DOS Header
  • DOS signature
• COFF Header
  • 类型: IA32 or X64 or ARM
• Optional Header
  • Section alignment and file alignment：对齐要求
  • Entry point ：存放在text里面，记录了相对于header的offset
  • Subsystem: EFI driver/EFI runtime driver/EFI application
  • Data Directory（通常16条）
    • Debug directory to find the debug PDB file path in .rdata section
    • Relocation directory to find the relocation data in .reloc section
• Section data（段数据）
  • .text: 代码
  • .rdata: 只读数据，比如Debug file path
  • .data: 全局变量
  • .rsrc: 资源部分包含额外的数据
  • .reloc: info来重新加载PE图像到不同的地址

FV拓展 EFI OPTIONROM

• Option Rom内置在设备中
• Option Rom在UEFI引导下自动加载
• EFI Option Rom包括作为设备驱动程序的EFI图像
• ROM报头有0x0EF1作为签名
• PCI数据结构包括DeviceId和VendorId
• 选项rom图像可以包含多个图像，以支持不同的ARCHs。