coreboot 逐级跨过无 RAM 空档

coreboot 2008 年丹佛峰会上的开发工作桌，打开的笔记本电脑、裸露的主板、线缆和编程硬件挤在一起。照片捕捉到的固件工作与本文所述如出一辙：贴近具体机器，逐块主板处理。照片由 wardv 拍摄，未经修改，采用 CC BY-SA 2.0 许可，经 Wikimedia Commons 获取。[8]

在采用 cache-as-RAM 的 coreboot 平台上，处理器进入 coreboot 时，普通 DRAM 尚不可用，操作系统也未启动，临时状态甚至没有一块宽裕的存放空间。因此，最先浮现的架构事实是一项约束：固件必须先运行初始化内存的代码，之后才有能力初始化内存。

coreboot 将这个循环难题拆成一串能力逐级提升、且经过有意划分的阶段。每个阶段只依赖前一阶段已经确认可靠的软硬件条件，完成范围有限的一部分硬件初始化，再把能力更强的执行环境交给下一阶段。整条路径可以包含 bootblock、可选的 verified-boot verstage、romstage、postcar、ramstage，最后抵达 payload。这些名称描述资源条件如何变化，不能把它们看作一个大程序中的任意章节。[1]

封面照片拍下了 2008 年 coreboot 丹佛峰会上的贡献者，当时人们仍常用项目早先的 LinuxBIOS 名称来称呼它。打开的笔记本电脑、散放的主板与编程线缆占满桌面。这幅实体景象与架构息息相关：阶段模型可以复用，每次成功启动依然取决于对一块真实主板的精确认识。[8]

最初的工作区借自 CPU cache

CPU 复位后，bootblock 会建立足以让后续代码顺利工作的 C 运行环境。在沿用这条路径的 x86 平台上，其中可以包括应用 microcode、初始化 timer、从 16-bit real mode 转入 32-bit protected mode、设置 stack pointer、清空 BSS，以及加载下一阶段。棘手之处落在 heap 与 stack：DRAM 此时尚未就绪，因为教会 memory controller 使用已安装内存模块的工作属于后续步骤。[1]

在采用 CAR 的平台上，cache-as-RAM（CAR）给出了临时解法。平台专属指令会把一部分 CPU cache 设为不可逐出的模式，让早期 C 代码可以像使用 SRAM 一样使用它。bootblock、romstage、verstage 和 postcar 都能在这块临时地址空间内工作。顺着这一点理解其架构，coreboot 从可用的最小替代物起步，借此消除下一项不确定性，最终资源留待后续阶段建立。[1]

启用 verified boot 时，bootblock 可以先进入 verstage，再转向 romstage。Verstage 以其代码和公钥在部署现场无法重写为前提，随后检查从 coreboot filesystem 加载的文件，并在访问分区前完成验证。验证因此被放在启动链前端，此时系统里可变的部分还很少。它确认后续哪些字节获准运行；至于每个后续组件是否开放、是否正确，仍属于另一项问题。[1]

在这条基于 CAR 的路径上，romstage 处理早期设备工作并启动 DRAM。采用独立 postcar 阶段时，常规内存一旦可用，它只负责一项范围明确的任务：拆除 cache-as-RAM 环境，再把 ramstage 加载到 DRAM。这个切换很容易被忽略，却能避免混淆两类内存。临时内存的身份不会悄然变成永久内存；一个具名阶段在此改写执行契约。[1]

CBFS 搬运代码，CBMEM 延续状态

两套名称相近的安排维系着各次交接。CBFS 是固件镜像内的 coreboot filesystem，存放启动时需要查找与加载的内容，包括各阶段、payload、raw files 和其他平台数据。构建系统会记录每一项的类型，例如 stage、payload、raw 或 flat-binary，同时写明位置、对齐方式和压缩选项。coreboot 架构文档列出的阶段压缩选项包括 none、LZ4 与 LZMA；bootblock 通常保持未压缩，体积更大的后期阶段则可以压缩，等内存可用后再解压到其中。[1][2]

因此，CBFS 就像启动过程的物料柜。早期代码可以从中定位指定的下一组件，各种可选行为也可以分置于不同文件，不再挤进一个持续驻留的二进制文件。最终 ROM 的组成由此变得可以检查：构建配置决定哪些主板代码、阶段二进制文件、payload 与辅助文件进入 flash image。[2]

CBMEM 处理的是相反方向的问题。DRAM 建立后，coreboot 会预留一块稳定的内存区域，保存生命周期长于产生它们之阶段的信息。各个 entry 可以容纳 console 输出、timestamp、内存信息、ACPI 与 SMBIOS tables、coreboot table、stage cache 及其他平台数据。在 CBMEM 完全可用之前，早期 console 与计时状态可以暂存在临时存储区；切换期间，这些状态会被复制到持久的 CBMEM entries 中。[3]

这一区别贯穿整个启动过程：一边是等待在 flash 中的文件，另一边是留存在内存中的状态。CBFS 回答“接下来要运行哪段代码或使用哪份数据？”，CBMEM 回答“机器已经得知了什么？”。它还为部分故障留下历史记录。Linux 启动后，cbmem 工具可以用 cbmem -c 显示收集到的 console，用 cbmem -t 显示各阶段 timestamp；遇到缓慢或时有时无的交接，只要最终仍能进入 Linux，或相关数据能熬过一次 warm reboot，调查便可依据这些记录推进，而不至于把整个启动过程缩减成一个总耗时或最后一行报错。[3]

Ramstage 把已发现的硬件整理成交接信息

DRAM 建立后，ramstage 才能处理先前成本过高或根本无法完成的大范围设备工作。它会初始化 PCI 与片上设备，可以初始化 graphics，处理 CPU 功能，例如 x86 上的 System Management Mode；如果 verstage 尚未初始化 TPM，也会在这里完成。它还会设置后期 security locks，包括 boot media 与相关 registers 的写保护。[1]

其产物还包括后继程序理解机器所需的描述：x86 平台上的 ACPI 与 SMBIOS tables、coreboot tables，或 Arm 平台上的 devicetree updates。主板专属知识由此被写成交接格式。GPIO 选择、保留区间与设备关系等信息会随交接一同传下去，后继程序可以直接读取，省去从头探测这些内容的过程。[1]

到了这里，主板代码已经与整体架构密不可分。一个 mainboard port 要指明 processor 与 chipset 路径、memory topology、embedded controller、不可探测设备，以及 generic code 无法安全推断的平台策略。coreboot 自身的支持指南要求用户查看 src/mainboard tree 或 Mainboard menu；仅凭熟悉的 CPU，无法推定任意一台笔记本都能兼容。Intel Boot Guard 会让替换固件变得困难，甚至彻底行不通，而 flash 失败时还必须有一条经过测试的恢复路径。[6]

从当前版本可以看到 port 如何逐步成熟。coreboot 26.06 发布于 June 25, 2026，记录了 101 位作者贡献的 1,163 次 commits，其中有 22 位新贡献者。Nova Lake 相关工作分别进入 bootblock、romstage 与 ramstage，随后加入 Intel FSP-M 与 FSP-S 集成及主板支持。同一份发布说明也明确指出，DDR5 支持尚未完成。因此，“支持 Nova Lake”作为工程结论仍过于粗略；抵达的阶段、主板变体、内存路径、payload 与经过测试的行为都需要纳入判断。[5]

Payload 决定后续“启动”的含义

coreboot 的最后一步，是执行存放在 CBFS 中的 payload。payload 在构建镜像时确定，coreboot 内部没有运行时选择器。这种分工把硬件初始化与后续启动策略分开。SeaBIOS 可以给出传统 PC BIOS interface，edk2 可以建立 UEFI environment，GRUB2 可以直接充当 bootloader，一套小型 Linux payload 则能先使用人们熟悉的 drivers 与 userspace tools，再通过 kexec 完成交接。[1][4]

这里列出的远不止几个品牌名称。每种 payload 都把复杂度移到不同位置。需要 option ROMs 与传统 PC BIOS contract 时，SeaBIOS 很合适。Linux payload 可以把 storage、networking 与 recovery 行为移入 operations team 已经熟悉的 kernel 和 userland。Heads 将 coreboot、Linux 与面向安全的工具组合在一起，支持的 mainboards 数量则很有限。因此，payload 的选择受设备 recovery、compatibility 与 trust requirements 约束，各种 payload 不能被当作可随意互换的装饰层。[4]

LWN 在 2013 年对 Chrome OS firmware 的一篇独立报道中，记录了这条接缝的两面。coreboot 的 payload model 让 Chrome OS 能够用 U-Boot 执行自己的 verified-boot policy，Intel reference code 与其他闭源组件则仍留在 firmware stack 的其他位置。这种架构会缩小职责范围，并让分工更清晰；供应商若只以二进制形式给出 silicon initialization code，架构本身也无法凭空得到源码。[7]

这条界线今天仍直接关系到实际部署。一套 coreboot build 的大部分内容可以接受检查，同时仍会调用 Intel Firmware Support Package、携带 microcode、与 management-engine firmware 共存，或依赖运行自身代码的 embedded controller。另一面，替换 boot firmware 本身不会改变共享 flash chip 或主板的每一个相邻组件。coreboot 的 FAQ 对此写得格外直接：仅凭 coreboot 是否存在，无法判断 Intel Management Engine 当前的运行状态。[1][6]

故障发生时，沿着阶段链阅读

当机器未能抵达 payload 时，这套架构的用途最为清楚。串口没有输出时，可以先怀疑 console 建立之前的环节。日志止于 romstage，线索会指向 memory training 或早期平台设置。进入 ramstage 后设备仍未出现，关注点就会转到 enumeration、resources、ACPI construction 或主板配置。coreboot 已经顺利交接，随后 disk boot 或 network boot 失败，首先应检查 payload 及其策略。平台开放相关数据时，CBMEM console 与 timestamp 能让这些假设接受检验。[1][3]

同样的阶段划分也有利于审查变更。修改 cache-as-RAM setup 的 patch 与新增 ramstage device callback 的 patch 影响范围不同；CBFS layout 变更与 CBMEM handoff 变更性质各异；引入新 payload 也不会自动要求新的 DRAM path。安全仍需另行验证，而这些接缝给了审查者一套词汇，用于追问哪些资源已经存在、哪些状态会延续，以及由哪个组件作出下一项决定。

在本文考察的 CAR 路径上，coreboot 最深的一项架构动作，是把资源匮乏明白地写进启动过程。起初，系统几乎没有可写内存，经过验证的知识也很少；它先借来工作区，再初始化 DRAM，保存已经获知的信息，描述硬件，锁定应当停止变化的部分，随后退出。整个启动得以完成，因为每个阶段都只使用属于自身的能力，把更高一级的能力留给下一阶段。

cronfeed.work