【PCIe科普】PCIe与BIOS(三):介绍BIOS/UEFI常用的一些术语和历史来源
2026-08-26 14:53:44
接上一篇文章:【PCIe科普】PCIe与BIOS(二):开机自检流程与 Option ROM 加载机制,今天我们继续来探讨一下开机POST自检过程中一些基本的术语,例如:

PE 格式是什么意思?Option ROM 是什么意思,一般该 ROM 位于 RAID, GPU 等卡的什么地方,是一个 EEPROM 吗?为什么叫 Option ROM? 实模式是什么? Option ROM 是用 standard C 写的吗?PEI/DXE 是啥缩写,啥意思?

这些问题非常细致,涉及 BIOS/UEFI 启动架构、固件存储格式、编程模式等多个深层概念,我们今天将逐一详细讲解,并结合底层原理回答:

1. 什么是 PE 格式?

PE(Portable Executable)格式 是 Microsoft Windows 下的标准可执行文件格式,适用于 .exe.dll.efi 文件等。//* 感兴趣的可以参考本文底部的斜体关于为什么是微软的文件格式作为UEFI BOOT的文件格式的历史。

在 UEFI 中,设备的 Option ROM(如果是 UEFI 驱动)就必须使用 PE 格式,这样主板固件可以在 UEFI 环境中加载它。

  • PE 文件由多个段(如 .text.data.reloc)组成;
  • 适用于 32 位和 64 位;
  • 可被加载器识别、定位入口函数、分配内存执行;
  • EFI 驱动就是 PE 文件,扩展名一般是 .efi

2. 什么是 Option ROM?

Option ROM(可选只读存储器) 是嵌在一些扩展卡(如 RAID 卡、网卡、显卡)上的一小段固件代码,用来在 BIOS/UEFI 阶段完成设备初始化或引导。

比如:RAID 卡上的 Option ROM 会在 POST 时加载,让 BIOS 能看到 RAID 虚拟磁盘;显卡的 Option ROM 会初始化 GPU 并提供显示功能。

Option ROM 通常存在于:

  • RAID 卡、HBA、GPU、NIC 等扩展卡
  • 存储在该卡上的 SPI Flash / EEPROM / NOR Flash 芯片中;
  • 容量一般从几十 KB 到几百 KB 不等。

为什么叫 “Option ROM”?

  • “Option” 是因为:它是可选功能模块(不是必须的),取决于设备;
  • “ROM” 是因为:它原本是只读存储,烧录在 EEPROM 上;
  • 这个名字最早来源于 IBM PC/AT 的 BIOS 规范(1981~1984 年),IBM 的技术文档中就使用了这个术语。

3. 实模式(Real Mode) 是什么?

实模式(Real Mode) 是 x86 架构 CPU 开机时默认的运行模式。

  • 英文:Real Mode
  • 地址空间仅支持 1MB(20-bit 地址线),每个段最多 64KB;
  • 没有内存保护、没有虚拟地址、没有多任务支持;
  • BIOS 代码(含 Option ROM)必须在实模式下运行。

对应的高级模式:

模式名
英文名
特点
实模式
Real Mode
初始模式,BIOS 执行用
保护模式
Protected Mode
支持 32 位内存访问、段保护(OS 使用)
长模式(64 位)
Long Mode
支持 64 位寻址,现代系统常态

4. Option ROM 用什么语言写的?可以用 Standard C 吗?

Legacy Option ROM:

  • 通常使用 汇编语言(x86 ASM) 或 C 语言 + 编译器限制 编写;
  • 必须保证代码可在 实模式环境下运行
  • 要求代码尽量小(不能依赖标准库),入口必须在特定偏移;
  • 编译器通常使用 -ffreestanding-m16 或类似选项生成“裸代码”。

UEFI Option ROM:

  • 写法接近现代驱动开发;
  • 可用 标准 C / C++(如使用 EDK II 开发框架);
  • 编译结果为 PE 格式的 EFI 驱动
  • 与操作系统下写驱动类似,但运行在 UEFI 环境中(无 OS);
  • 有明确入口 efi_main()

5. 什么是 PEI / DXE 阶段结构?缩写和含义?

这是 UEFI 启动流程中的两个关键阶段:

阶段
缩写
英文全称
作用
PEI
Pre-EFI Initialization
预初始化阶段
初始化 CPU、内存、芯片组等核心硬件,准备执行更复杂任务
DXE
Driver Execution Environment
驱动执行环境
加载和运行各种 UEFI 驱动(如显卡、RAID 驱动、文件系统)

UEFI 启动流程大致如下:

Reset → SEC → PEI → DXE → BDS → Boot OS

Option ROM 中的 UEFI 驱动会在 DXE 阶段被加载和执行,这取代了 Legacy BIOS 中的“跳进去再跳回来”的方式。

 举例说明

一个 RAID 控制卡上:

  • EEPROM 中烧录了一个 UEFI Option ROM
  • 启动时 UEFI 固件发现它,加载 PE 格式驱动;
  • 驱动运行,在 UEFI shell 或 BIOS 图形界面中暴露配置界面;
  • 如果是 Legacy BIOS 则跳到 C000:0003 执行 Option ROM 的入口;

PE格式文件采用微软文件格式的历史由来

UEFI 规范中采用的 PE(Portable Executable)文件格式,正是最初由微软为 Windows NT 操作系统设计并标准化的可执行文件格式(准确地说,是 PE32 / PE32+ 格式,衍生自 Unix 的 COFF 格式)。

但这并不意味着 UEFI 固件依赖 Windows 系统,而是 UEFI 标准在制定时直接“借用”了微软这套成熟的文件结构规范。

一、 为什么跨平台的 UEFI 会采用微软的 PE 格式?

  1. 历史渊源(Intel 与 Microsoft 的合作):
    • UEFI 的前身是 Intel 在 1990 年代末为安腾(Itanium, IA-64)架构开发的 EFI(Extensible Firmware Interface)
    • 当时 Intel 与微软紧密合作,需要一种现代、支持 32/64 位平坦内存模型(Flat Memory Model)、可重定位且具备结构化元数据的二进制格式,用来取代老旧 BIOS 的 16 位实模式纯裸二进制扇区代码。
    • 微软的 PE/COFF 格式当时已经非常成熟稳定,具备完整的段结构(如 .text.data.reloc),因此 Intel 直接将其选定为 EFI 的官方二进制封装标准。
  2. UEFI 规范的硬性要求:
    • UEFI 规范(UEFI Specification)中明确规定:所有的 UEFI 驱动程序(.efiOption ROMUEFI 应用程序 以及 OS 引导加载程序(OS Boot Loader) 必须封装为标准 PE32(32 位)或 PE32+(64 位) 格式。

二、 UEFI 中的 PE 格式与 Windows 下的 .exe / .dll 有何异同?

相同之处(底层容器结构一致)

  • 头部结构相同
    都包含经典的 MZ 头部(MS-DOS Stub Header,用于兼容性识别)、PE 签名魔数(0x00004550)、COFF 文件头(File Header)和可选头(Optional Header)。
  • 段表结构相同
    都划分为 .text(代码段)、.data(已初始化数据)、.reloc(重定位表)等。
  • 数字签名机制相同
    UEFI Secure Boot(安全启动)验证的 Authenticode 签名结构,与 Windows 驱动和程序签名的格式完全相同(存放在 PE 的 Security Directory 中)。

关键不同之处(运行时环境与子系统差异)

  • 子系统标识(Subsystem ID)不同
    • IMAGE_SUBSYSTEM_EFI_APPLICATION
      (如 bootx64.efigrubx64.efi
    • IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER
      (引导服务驱动)
    • IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER
      (运行时驱动)
    • Windows 应用程序的 Subsystem 字段通常标记为 IMAGE_SUBSYSTEM_WINDOWS_GUI(窗口程序)或 IMAGE_SUBSYSTEM_WINDOWS_CUI(控制台程序)。
    • UEFI 文件的 Subsystem 字段必须显式标记为 UEFI 专属类型:
  • 依赖的运行环境不同
    • Windows 下的 PE 文件依赖 Windows 内核(ntoskrnl.exe)或用户态 API(kernel32.dll 等)。
    • UEFI 下的 PE 文件运行在没有操作系统的裸机固件环境,它不调用任何 Windows DLL,而是通过入口点传入的指针直接调用 UEFI 固件提供的 Boot Services 和 Runtime Services 系统表(System Table)。

三、 Linux 的引导加载程序也是 PE 格式吗?

是的。

即使是 Linux 系统,在 UEFI 模式下引导时:

  • Linux 的引导程序 GRUB 2(例如 grubx64.efi)和红帽/Fedora 使用的一级安全引导载荷 Shimshimx64.efi),其底层文件结构全都是标准的 PE/COFF 格式
  • 现代 Linux 内核本身还集成了 EFI Boot Stub 功能,编译出来的 Linux 内核映像(vmlinuz)本身就被封装成了伪装的 PE/COFF 格式,使得 UEFI 固件能够跳过 GRUB 直接将 Linux 内核当成一个 UEFI PE 应用程序执行加载。

免费下载Saniffer公司白皮书

希望获得更多关于PCIe5.0&6.0, CXL, NVMe SSD, SAS/SATA, NVMe over Fabric (NVMoF), NAND,新型存储技术NVM(RRAM/ReRAM, FRAM/FeRAM, MRAM, PCM, 3D-NOR, SRAM/DRAM等) DDR5/LPDDR5以及UFS测试技术和产品,可以查看Saniffer公司2026.2.24最新更新的测试工具白皮书15.1版本,我们已经整理收录在Saniffer公众号的【白皮书】菜单中。

欢迎关注Saniffer公众号,点击底部菜单栏即可免费获取。如有任何技术问题,也可直接在公众号内留言交流。