固件基础：掌握固件、BIOS、UEFI、Bootloader、Payload等核心概念，理解计算机启动流程
在深入Coreboot开发之前，必须首先厘清一组经常被混用但内涵迥异的概念：固件（Firmware）、BIOS、UEFI、Bootloader与Payload。这些术语在x86与ARM生态中各有侧重，而Coreboot恰恰处于这些概念的交叉点上。理解它们之间的层级关系与职责边界，是后续进行固件移植、定制与调试的认知前提。本章将从定义出发，逐步拆解计算机从按下电源键到操作系统内核运行之间的完整启动链路，并明确Coreboot在其中扮演的角色。
2.1 固件与BIOS：从ROM到Flash的演进
固件（Firmware）是固化在非易失性存储介质（ROM、NOR Flash、SPI Flash）中的软件程序，它介于硬件与操作系统之间，负责在系统上电后完成最基本的硬件初始化和运行时服务提供。固件的本质是"软件形态的硬件逻辑"——它不像普通应用程序那样由操作系统加载，而是直接运行在裸金属硬件上，拥有对CPU、内存、I/O端口的最高控制权限。
BIOS（Basic Input/Output System）是固件的一种具体实现形态，诞生于1981年IBM PC时代。传统BIOS运行在16位实模式下，通过中断向量（如INT 13h磁盘服务、INT 10h显示服务）向上层提供硬件抽象。BIOS的代码量通常在64KB到2MB之间，存储在主板上的SPI Flash芯片中。它的核心职责包括：POST（Power-On Self-Test，上电自检）、初始化芯片组与内存、加载中断向量表、以及从引导设备读取引导扇区。
传统BIOS存在几个结构性限制：首先，16位实模式只能访问1MB地址空间，虽然通过保护模式扩展可以突破，但BIOS本身的设计范式仍然停留在上世纪80年代；其次，BIOS的驱动模型缺乏统一标准，每个厂商（AMI、Award、Phoenix）的实现细节差异巨大；第三，BIOS的启动流程是线性的、不可扩展的，无法支持现代硬件所需的并行初始化和模块化加载。
| 特性 | 传统BIOS | UEFI | Coreboot |
|---|---|---|---|
| 运行模式 | 16位实模式 | 32/64位保护模式 | 32/64位保护模式 |
| 存储介质 | SPI Flash（通常≤16MB） | SPI Flash（通常≥32MB） | SPI Flash（通常≤16MB） |
| 驱动模型 | 无统一标准，厂商私有 | UEFI Driver Model，标准协议接口 | 设备驱动编译进固件，无运行时抽象 |
| 启动速度 | 慢（线性初始化） | 中等（可并行但开销大） | 快（最小化初始化路径） |
| 扩展性 | 差（Option ROM限制） | 好（模块化、可加载驱动） | 好（Payload机制） |
| 安全启动 | 不支持 | Secure Boot（签名验证） | 通过Payload实现（如vboot） |
核心理解：Coreboot不是BIOS的替代品，而是BIOS/UEFI的前置替代层。Coreboot完成硬件初始化后，可以加载SeaBIOS（提供传统BIOS兼容）、Tianocore（提供UEFI环境）或GRUB2（直接引导内核）作为Payload。这种"初始化与运行时分离"的设计，是Coreboot区别于传统固件的根本特征。
2.2 UEFI与Bootloader：现代固件的两种范式
UEFI（Unified Extensible Firmware Interface）由Intel在2005年主导制定，旨在取代传统BIOS。UEFI运行在32/64位保护模式下，拥有完整的协议栈（如EFI_SIMPLE_FILE_SYSTEM_PROTOCOL、EFI_GRAPHICS_OUTPUT_PROTOCOL），支持网络启动、分区表、安全启动（Secure Boot）等现代特性。UEFI固件本身就是一个微型操作系统：它有事件驱动模型、内存管理、定时器服务，甚至支持在固件中运行小型应用程序（如UEFI Shell）。
UEFI的启动流程分为七个阶段：SEC（安全验证）→ PEI（EFI前初始化）→ DXE（驱动执行环境）→ BDS（启动设备选择）→ TSL（临时系统加载）→ RT（运行时）→ AL（灾难恢复）。其中PEI阶段负责CPU和内存的最小初始化，DXE阶段加载大部分设备驱动，BDS阶段根据启动顺序选择操作系统引导器。
Bootloader（引导加载程序）是一个更宽泛的概念，指任何在操作系统内核运行之前加载并传递控制权的程序。在x86平台上，传统BIOS或UEFI本身就是Bootloader的一部分；在嵌入式Linux领域，U-Boot、GRUB、LILO都是典型的Bootloader。Bootloader的职责通常包括：初始化必要的硬件（内存、串口、存储控制器）、加载内核镜像到内存、设置内核启动参数（如root=、console=）、跳转到内核入口点。
在Coreboot的语境中，Payload特指Coreboot在完成硬件初始化后加载的"第二阶段引导程序"。Coreboot本身不直接引导操作系统，而是将控制权交给Payload。常见的Payload包括：
- SeaBIOS：提供传统BIOS中断服务，兼容旧操作系统和Option ROM
- Tianocore：完整的UEFI实现，支持Secure Boot和UEFI Shell
- GRUB2：功能强大的多引导管理器，支持文件系统解析和内核参数编辑
- LinuxBoot（原名coreboot+Linux）：将Linux内核作为Payload，利用Linux驱动生态完成硬件初始化和引导
- Depthcharge：ChromeOS使用的Payload，深度集成验证启动（Verified Boot）
经验提醒：在Coreboot开发中，选择Payload不是随意的。如果目标系统需要运行Windows，必须选择Tianocore（UEFI）或SeaBIOS（传统BIOS模式）；如果只运行Linux且追求最快启动速度，可以直接使用GRUB2或LinuxBoot。Payload的选择直接影响固件的功能边界和兼容性。
2.3 计算机启动流程：从复位向量到操作系统
理解启动流程是固件开发的基本功。以x86平台为例，完整的启动链路可以拆解为以下步骤：
- 上电复位（Power-On Reset）：CPU的复位引脚被拉高，所有寄存器回到默认状态。x86 CPU的CS（代码段）寄存器被设置为0xF000，IP（指令指针）设置为0xFFF0，因此第一条指令从物理地址0xFFFFFFF0（复位向量）开始执行。
- Bootblock执行：复位向量指向SPI Flash映射的地址空间。Coreboot的Bootblock代码从这里开始运行。Bootblock首先设置CPU进入32位保护模式，然后初始化Cache-as-RAM（CAR），将Flash中的后续代码（Romstage）拷贝到CAR中执行。
- Romstage初始化：Romstage在CAR中运行，完成内存控制器（Memory Controller Hub）的初始化，包括DDR训练、时序参数配置、内存映射建立。一旦内存可用，Romstage将Ramstage代码从Flash加载到内存中。
- Ramstage设备枚举：Ramstage运行在真实内存中，遍历PCI总线、枚举设备、加载设备驱动（如显卡、存储控制器、USB控制器）。Ramstage还负责生成ACPI表（高级配置与电源管理接口），供操作系统使用。
- Payload加载：Ramstage根据配置选择Payload，将其从Flash或存储设备加载到内存，并跳转到Payload的入口点。
- Payload引导：Payload（如GRUB2）解析配置文件，加载Linux内核镜像（vmlinuz）和initramfs到内存，设置启动参数，最终跳转到内核入口。
- 内核启动：Linux内核解压自身，初始化调度器、内存管理、驱动子系统，挂载根文件系统，启动init进程（PID 1）。
风险提示：在Coreboot开发中，Bootblock和Romstage的代码必须极其精简且正确。因为此时内存尚未初始化，任何栈溢出或数组越界都会导致不可恢复的崩溃（三声短蜂鸣或黑屏）。调试手段仅限于串口输出（通过Super I/O或BMC）和逻辑分析仪抓取总线信号。
2.4 案例拆解：从Coreboot到Linux内核的完整启动日志
为了将上述概念串联起来，我们以一个典型的x86 Chromebook（如Google Pixelbook）为例，展示Coreboot启动过程中的关键日志输出。该设备使用Intel Kaby Lake平台，Coreboot版本为4.11，Payload为Depthcharge。
// 串口输出（波特率115200，8N1）
coreboot-4.11-1234-gabcdef-dirty Mon Jan 15 10:00:00 UTC 2024 booting...
// Bootblock阶段
Bootblock: starting...
CPU: Intel Kaby Lake (i7-7Y75)
Enabling cache-as-RAM... OK
Loading romstage from flash... OK
// Romstage阶段
Romstage: starting...
Memory controller init: DDR3L 8GB
Memory training: Channel 0 (2 DIMMs) ... OK
Memory training: Channel 1 (2 DIMMs) ... OK
RAM: 8192 MB, speed 1866 MT/s
Loading ramstage from flash... OK
// Ramstage阶段
Ramstage: starting...
PCI: 00:00.0 Host bridge init... OK
PCI: 00:02.0 VGA controller init... OK
PCI: 00:14.0 USB xHCI controller init... OK
PCI: 00:1f.2 SATA controller init... OK
ACPI: generating DSDT... OK
SMBIOS: generating tables... OK
// Payload加载
Loading payload (Depthcharge) from flash... OK
Payload entry: 0x00100000
// Depthcharge输出
Depthcharge: starting...
Verified Boot: checking firmware signature... OK
Verified Boot: checking kernel partition A... OK
Loading kernel from partition 2 (ext4)... OK
Kernel command line: console=ttyS0,115200 root=/dev/mmcblk0p3
// Linux内核启动
[ 0.000000] Linux version 5.15.0-arch1-1 (linux@archlinux)
[ 0.000000] Command line: console=ttyS0,115200 root=/dev/mmcblk0p3
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point'
[ 0.000000] Memory: 7864320K/8388608K available
[ 0.000000] Calibrating delay loop... 3997.69 BogoMIPS
[ 0.000000] PCI: Probing PCI hardware
[ 0.000000] pci 0000:00:02.0: [8086:5917] type 00 class 0x030000
[ 0.000000] Freeing unused kernel image (initmem) memory: 2048K
[ 0.000000] Run /init as init process从日志中可以清晰看到各阶段的边界：Bootblock在约10ms内完成，Romstage耗时约200ms（主要是DDR训练），Ramstage约300ms（设备枚举和ACPI生成），Payload加载和验证约100ms，Linux内核从解压到init进程约500ms。整个启动过程约1.1秒，其中固件部分（Coreboot+Payload）占约600ms，内核占约500ms。
这个案例揭示了几个关键点：第一，Coreboot的启动速度远快于传统BIOS（通常需要3-5秒），因为其初始化路径是定制的、无冗余的；第二，DDR训练是Romstage中最耗时的部分，优化内存训练参数可以显著缩短启动时间；第三，Depthcharge的验证启动（Verified Boot）增加了约100ms的开销，但这是安全启动的必要代价。
复盘经验：在实际开发中，如果遇到启动失败，应首先通过串口日志定位失败阶段。Bootblock失败通常是CPU或Flash配置错误；Romstage失败多为内存训练问题（检查SPD数据、时序参数）；Ramstage失败可能是设备驱动冲突或ACPI表生成错误；Payload失败则需检查Payload配置和签名验证逻辑。分阶段排查是固件调试的核心方法论。
2.5 常见误区与总结
在固件开发的学习和实践中，以下误区需要特别警惕：
- 误区一：将BIOS和固件混为一谈。固件是泛称，BIOS只是x86平台上的一种固件实现。ARM平台的固件（如U-Boot、Trusted Firmware-A）与BIOS完全不同。
- 误区二：认为Coreboot是UEFI的替代品。Coreboot是初始化层，UEFI是运行时环境。Coreboot可以加载Tianocore（UEFI实现）作为Payload，两者是协作关系而非竞争关系。
- 误区三：忽视Bootblock的重要性。Bootblock是固件中最难调试的部分，因为它运行在内存未初始化的环境中。很多初学者试图在Bootblock中添加复杂逻辑，这是极其危险的。
- 误区四：混淆Payload和Bootloader。Payload是Coreboot加载的"第二阶段引导程序"，而Bootloader是更宽泛的概念。GRUB2既是Bootloader，也可以作为Coreboot的Payload。
- 误区五：忽略ACPI表的作用。ACPI表是固件与操作系统之间的重要接口，负责电源管理、设备枚举等。如果ACPI表生成错误，操作系统可能无法正确识别硬件或进入低功耗状态。