万字深度解析 Coreboot 26.06：当开源固件遇见 AI 硬件时代——从 Nova Lake 提前适配到 A/B 分区恢复的完整技术指南（2026）
前言
2026 年 6 月 26 日，开源固件项目 Coreboot 正式发布了 26.06 版本。这是该项目的季度版本更新，代号延续了 Coreboot 社区一贯以日期命名的风格，但背后的技术含量却丝毫不减。
Coreboot，这个曾用名 LinuxBIOS 的开源固件项目，至今已走过了二十多个年头。它是现代计算机启动链路中最底层、最关键的一环——在电源按钮被按下那一刻，是 Coreboot 首先接管硬件，完成最原始的 CPU 初始化、内存探测、设备枚举，随后才将控制权移交给操作系统引导程序。没有 Coreboot，Linux、BSD、Windows 都没有机会运行。
本次 26.06 版本带来了几个值得关注的里程碑：
- Intel Nova Lake 平台初步支持：在这款处理器正式上市销售之前，Coreboot 就已经整合了对应的固件支持包
- AMD Strix Halo（Ryzen AI Max 300）平台初步支持：AMD 这款面向 AI 工作站的旗舰 APU 尚未量产，Coreboot 工程师已经在 Maple 参考开发板上完成了初步适配
- ROM Armor 2 安全机制正式引入：新一代只读固件防护体系
- A/B Recovery 分区恢复机制：彻底解决 BIOS 刷坏后需要拆机重写的历史难题
- 31 块新主板/开发板支持：包括多款 Framework Laptop 型号，涵盖了从 x86 到 ARM 的多样化硬件生态
- Qualcomm Calypso SoC 初步支持：面向骁龙 X 系列笔记本平台的固件适配
这些变化的背后，不只是简单的代码合并，而是整个开源固件生态在应对 AI 时代硬件复杂度的系统性升级。本文将从架构原理出发，深入解析每一个新特性的技术细节，并提供面向开发者和高级用户的实战指南。
第一部分：Coreboot 架构原理——为什么开源固件如此重要
1.1 固件在计算机系统中的位置
要理解 Coreboot 的价值，首先需要理解固件在整个计算机启动链路中的位置。当用户按下电源键，系统经历的启动顺序大致如下：
电源上电 → 硬件自检(POST) → 固件初始化 → 引导加载器(Bootloader) → 操作系统内核 → 用户空间
传统 BIOS（Basic Input/Output System）自 1981 年 IBM PC 诞生以来就存在，其代码量通常在 64KB 到 128KB 之间，全部运行在 16 位实模式之下。BIOS 的设计初衷是在有限的硬件资源下完成最基本的输入输出操作，但它的架构已经严重落后于现代计算机系统。
Coreboot 的核心理念是：固件只需要做它必须做的事情——初始化硬件，然后将控制权交给操作系统。 其他所有事情都应该交给操作系统来完成。这与 UEFI（Unified Extensible Firmware Interface）的做法形成了鲜明对比——UEFI 是一个完整的操作系统级固件环境，功能强大但极其复杂，代码量通常达到 4-8MB。
1.2 Coreboot 的四阶段架构
Coreboot 的启动流程被精心设计为四个主要阶段，每一阶段都有明确的职责边界：
阶段一：Bootblock（引导块）
这是整个固件中最小也是最关键的部分，通常只有 64KB 或更少。Bootblock 是芯片上电后 CPU 执行的第一条指令所在，它的职责极为有限：
// Coreboot bootblock 核心职责伪代码
void bootblock_main(void) {
// 1. 设置最基本的 CPU 状态（寄存器、栈指针）
cpu_early_init();
// 2. 初始化内存控制器，为后续阶段准备 RAM
if (MUST_MIGRATE) {
// 将固件主体从 ROM 复制到 RAM
memmove(_rom_copy_start, _rom_base, _rom_copy_size);
// 更新栈指针到 RAM 地址空间
set_stack_pointer(_ram_stack_top);
// 跳转到 RAM 中的代码继续执行
((void (*)(void))_ram_entry)();
} else {
// 某些平台支持直接从 ROM 执行，跳过复制步骤
((void (*)(void))_rom_entry)();
}
}
Bootblock 的代码量被严格控制在极小范围内，原因在于某些平台（如 SPI Flash）的读取速度有限，且在内存尚未初始化之前，任何复杂操作都可能引发不可预知的行为。
阶段二：ROM Stage（只读存储阶段）
在 Bootblock 准备好内存之后，执行权转移到 ROM Stage。这个阶段的核心任务是完成硬件的完整初始化，包括：
- CPU 的完整初始化（切换到保护模式/长模式，设置 CR4 寄存器，启用 SSE/NX 等特性）
- 内存控制器的详细配置（SPD 读取、时序参数配置、内存训练）
- 早期芯片组初始化
- 必要的 GPIO 和外设配置
ROM Stage 的"C"代码在编译时会被链接为位置无关代码（PIC），以便在 ROM 和 RAM 之间无缝迁移。
阶段三：RAM Stage（随机存取内存阶段）
这是 Coreboot 的主体运行阶段，此时系统已经拥有可用 RAM，可以加载完整的设备驱动和配置数据。RAM Stage 执行的工作包括：
- ACPI 表的生成和填写
- SMBIOS 表的构建
- 设备驱动加载（PCIe 枚举、USB 初始化、SATA 配置等）
- 选择并执行 Payload（有效载荷）
阶段四：Payload（有效载荷）
Payload 是 Coreboot 的最终产物——一段可执行代码，可以是传统的 BIOS 兼容层（如 SeaBIOS）、完整的引导加载器（如 GRUB 2）、Linux 内核（LinuxBoot），甚至是定制的应用程序。
Payload 选择的灵活性是 Coreboot 最重要的特性之一。开发者可以根据实际需求选择最合适的引导方案：
# 查看 Coreboot 当前支持的 Payload 类型
$ ls -la payloads/
SeaBIOS/ # 传统 BIOS 兼容模式，支持启动 Windows
GRUB2/ # 功能丰富的开源引导加载器
coreinfo/ # 硬件信息浏览工具（类似 BIOS 设置界面）
Memtest86+/ # 内存压力测试工具
LinuxBoot/ # 直接启动 Linux 内核
edk2/ # Tianocore UEFI 实现
TianoCore/ # 另一个 UEFI 实现选项
1.3 Intel FSP 集成机制
对于 Intel 平台，Coreboot 的一个关键设计决策是不重复造轮子。Intel 提供了一套名为 FSP（Feature Configuration Package，固件支持包）的二进制固件模块，封装了 CPU、内存控制器和 PCH（平台控制器 hub）的初始化代码。
FSP 以静态库的形式分发，包含高度优化的汇编代码，负责执行那些需要精确时序控制的硬件操作。Coreboot 的任务是在适当的时机调用 FSP 的各个 API：
// Coreboot 中调用 Intel FSP 的典型模式
#include <fsp/fspapi.h>
// FSP-M（Memory）初始化：配置内存控制器
FSP_M_CONFIG m_cfg = {
.PcdFspMUpdVer = FSP_M_2_0_0_UPDFV_TYPE,
// 用户可配置的内存参数
};
FSP_STATUS (*fsp_memory_init)(void *params, void *mmio, void **hob_list) = NULL;
FSP_STATUS status = fsp_memory_init(NULL, NULL, &hob_list);
if (status != FSP_SUCCESS) {
die("FSP-M initialization failed\n");
}
// FSP-S（Silicon）初始化：配置 CPU 和 PCH
FSP_S_CONFIG s_cfg = {
.PcdFspSUpdVer = FSP_S_2_0_0_UPDFV_TYPE,
// 详细的平台配置参数
};
FSP_STATUS (*fsp_silicon_init)(void *params, void *hob_list) = NULL;
status = fsp_silicon_init(&s_cfg, hob_list);
if (status != FSP_SUCCESS) {
die("FSP-S initialization failed\n");
}
这种设计模式让 Coreboot 能够专注于架构级别的创新（payload 加载、安全策略、启动优化），同时将芯片级初始化的工作交给 Intel 的专业团队。FSP 本身是经过严格测试的二进制模块，通常比社区自行编写的开源实现更加稳定和高效。
26.06 版本中，Nova Lake 平台的 FSP 集成工作由 Intel 工程师直接参与，在处理器正式发布前数月就完成了初步支持包的提交。这反映了 Coreboot 与 Intel 之间日益紧密的合作关系——Intel 工程师如今直接在 Coreboot 仓库中提交代码，而非只在内部维护一份分支版本。
第二部分：Coreboot 26.06 新特性深度解析
2.1 Intel Nova Lake 提前适配：超前的固件支持
Nova Lake 是 Intel 下一代桌面和移动处理器的代号（预计 2026-2027 年发布），采用全新架构设计。在 26.06 版本中，Coreboot 正式引入了 Nova Lake 的初步支持，这是 Coreboot 历史上对未发布硬件支持速度最快的版本之一。
为什么要在硬件正式发布前就适配固件？这背后有深层的工程逻辑：
缩短产品上市时间（Time-to-Market）
OEM 厂商通常需要在硬件正式量产前 6-12 个月开始 BIOS 开发。如果等到芯片正式发布后才开始固件适配，终端产品的上市时间将被推迟数月。Coreboot 的提前适配让主板厂商和 OEM 能够在芯片正式发布前就开始固件验证工作。
Nova Lake 的架构变化
根据 Phoronix 和各方泄露信息，Nova Lake 相比当前的 Panther Lake 在以下方面有显著变化：
- 制程工艺：预计使用 Intel 18A 或改进版 Intel 4 工艺
- 核心架构：全新设计的能效核心（E-core），IPC 提升预计 15-20%
- 内存控制器：支持 DDR5-6400+ 和 LPDDR6
- PCIe 通道：PCIe 5.0 通道数量增加，支持更多高速外设
- NPU：集成更强的神经处理单元，AI 算力预计达到 50-60 TOPS
这些硬件变化需要相应的固件支持。FSP 需要处理新的内存时序参数、CPU 初始化序列、电源管理状态转换等。Coreboot 则需要适配这些新的 FSP 调用约定和硬件枚举逻辑。
代码层面看 Nova Lake 适配
在 Coreboot 的 board 配置文件中，Nova Lake 的适配通常涉及以下文件的创建或修改：
# Coreboot 仓库中 Nova Lake 支持的典型文件结构
src/mainboard/intel/nova_lake/
├── Kconfig # 板级配置选项
├── board.h # 板级硬件定义
├── gpio.c # GPIO 引脚配置
├── variant/ # 变体配置（不同 SKU）
│ ├── Kconfig
│ ├── gpio.c
│ └── memory.c # 内存配置参数
├── fsp/
│ ├── fspm_upd.h # FSP-M UPD 参数头文件
│ └── fsps_upd.h # FSP-S UPD 参数头文件
└── espi.h # eSPI 外设接口配置
在 FSP-M UPD（User Provided Data）文件中，Nova Lake 引入了新的内存参数：
// src/mainboard/intel/nova_lake/fsp/fspm_upd.h
#pragma once
// Nova Lake 内存控制器配置
typedef struct {
// 标准 FSP-M UPD 头
FSP_M_CONFIG_HDR FSP_M_CONFIG_HDR_Tag;
// Nova Lake 新增：DDR5 高级时序参数
UINT8 Ddr5CaTraining; // CA 训练启用
UINT8 Ddr5CsTraining; // CS 训练启用
UINT8 Ddr5RetrainMarginCheck; // 边际检查重训练
UINT16 Ddr5McReadDqDqsCpuPdaTlc; // PDA 训练命令
UINT8 Ddr5EccEnabled; // ECC 支持
// Nova Lake 新增：LPDDR6 支持
UINT8 LpDdr6Enabled; // LPDDR6 模式切换
UINT32 LpDdr6MaxSpeed; // 最高 LPDDR6 速率（MT/s）
UINT8 LpDdr6RankInterleave; // _rank 交错
// Nova Lake 新增：PCIe 根端口配置
UINT8 PcieRootPortsEnableMask; // 启用的 PCIe 根端口掩码
UINT16 PcieGen5MaxRate; // PCIe Gen5 最大速率
// Nova Lake 新增：NPU 电源管理
UINT8 NpuEnabled; // NPU 启用状态
UINT8 NpuPowerLimit; // NPU 功耗限制（毫瓦）
UINT16 NpuMaxFrequency; // NPU 最大频率（MHz）
} FSP_M_CONFIG;
这个 UPD 结构体的变化直接反映了 Nova Lake 在内存控制器和 NPU 上的硬件规格变化。
2.2 AMD Strix Halo（Ryzen AI Max 300）初步支持
AMD Strix Halo 是 AMD 面向高端 AI 工作站和轻薄游戏本设计的 APU，代号中"Halo"意为"光环"，暗示这是 AMD 面向市场最高端的产品线。与传统 APU 不同，Strix Halo 的核显规模接近入门级独立显卡（据报道最高配置 40 个 RDNA 3.5 计算单元），同时集成了超大规模的统一内存架构。
Coreboot 适配的挑战
AMD 平台的 Coreboot 适配与 Intel 有显著不同。AMD 不提供类似 Intel FSP 的统一二进制固件包，因此 Coreboot 需要自行实现更多底层初始化代码。Strix Halo 的适配涉及：
- AGESA（AMD Generic Encapsulated Software Architecture）集成：AGESA 是 AMD 的固件核心，类似于 Intel 的 FSP
- cJSON 或 CPPC（Collaborative Processor Performance Control）表配置
- USB4/Thunderbolt 替代方案的固件配置
// Strix Halo (AGESA) 集成示例
#include <AGESA.h>
STATIC VOIDAGESA_CALLCONV PromontoryInitEntry(
IN AMD_APU_SERVICES *AmdApuServices,
IN AMD_CONFIG_PARAMS *ConfigParams
) {
// 初始化AGESA内存训练
LOCATE_HEAP Buffer;
Buffer.Handle = AMD_MEM_CONTEXT_HANDLE;
if (HeapLocateBuffer(&Buffer, &AmdApuServices->MemData) != AGESA_SUCCESS) {
DEBUG((DEBUG_WARN, "AGESA: Memory heap allocation failed\n"));
return AGESA_FATAL;
}
// 启动内存初始化和训练序列
AMD_MEMORY_TRAINING_PARAMS TrainParams = {
.TrainingMode = MEM_TRAINING_MODE_AUTO,
.Level = MEM_TRAINING_LEVEL_AUTO,
.SocketId = 0,
.ChannelId = ALL_CHANNELS,
};
AGESA_STATUS status = AmdMemoryTraining(&TrainParams, AmdApuServices);
if (status != AGESA_SUCCESS) {
DEBUG((DEBUG_ERROR, "AGESA: Memory training failed: 0x%x\n", status));
return AGESA_FATAL;
}
// Strix Halo 特有的统一内存初始化
if (IsStrixHaloApu(AmdApuServices->StdHeader)) {
// 配置 HSMP (Hypervisor System Management Port) 接口
InitHsmpInterface();
// 配置统一内存分配策略
ConfigureUnifiedMemoryPool();
}
}
目前 Coreboot 26.06 对 Strix Halo 的支持仅限 Maple 参考开发板，这意味着社区还需要相当的时间才能将支持扩展到零售主板。但初步支持的完成是一个重要信号——AMD 平台在 Coreboot 社区的重要性正在提升。
2.3 ROM Armor 2：下一代只读固件防护
ROM Armor 是 Coreboot 社区开发的一套固件完整性保护机制，目标是确保固件在启动过程中没有被篡改。26.06 版本引入的 ROM Armor 2 是该机制的全新升级版本。
ROM Armor 2 的核心设计
ROM Armor 2 采用多层防护策略，主要包括以下几个维度：
第一层：可信启动链（Verified Boot Chain）
# ROM Armor 2 验证流程伪代码
bool verify_boot_chain(void) {
// 1. 从硬件信任根（RoT）读取公钥
uint8_t root_public_key[HASH_SIZE];
read_from_platform_fuse(root_public_key, PLATFORM_KEY_HASH);
// 2. 验证 Bootblock 的签名
bootblock_signature sig;
flash_read(&sig, sizeof(sig));
if (!rsa_verify(sig.hash, sig.signature, root_public_key)) {
log_fatal("Bootblock signature verification FAILED\n");
return false;
}
// 3. 测量 ROM Stage 并与已知哈希比对
uint8_t romstage_hash[HASH_SIZE];
calculate_sha256(ROMSTAGE_START, ROMSTAGE_SIZE, romstage_hash);
if (memcmp(romstage_hash, known_romstage_hash, HASH_SIZE) != 0) {
log_fatal("ROM stage integrity violation detected\n");
return false;
}
// 4. 测量 RAM Stage
uint8_t ramstage_hash[HASH_SIZE];
calculate_sha256(RAMSTAGE_START, RAMSTAGE_SIZE, ramstage_hash);
if (memcmp(ramstage_hash, known_ramstage_hash, HASH_SIZE) != 0) {
log_fatal("RAM stage integrity violation detected\n");
return false;
}
return true;
}
第二层：ROM 区域只读锁定
ROM Armor 2 通过 SPI 控制器配置，将固件存储区域设置为只读模式：
// ROM Armor 2 SPI 保护配置
void rom_armor_lock_spi_flash(void) {
// 读取 SPI 控制器的保护寄存器
uint32_t prot_ranges[4];
spi_controller_read_protection(prot_ranges);
// 配置保护区域（通常是整个固件分区）
spi_controller_set_protection(0, FLASH_SIZE, READONLY);
// 启用写保护引脚（通常连接 CPU 的 PROTECT# 信号）
gpio_set_pull(GPIO_SPI_WP, PULL_UP);
gpio_set_direction(GPIO_SPI_WP, INPUT);
// 设置保护触发条件：WP 引脚低电平 + 写命令同时触发时，阻止写入
spi_controller_enable_write_protection(
WP_MODE_HARDWARE_AND_SOFTWARE, // 双重保护
LOCK_PERMANENT // 不可逆锁定
);
}
第三层：运行时完整性监控（新增于 ROM Armor 2）
ROM Armor 2 的重大升级在于引入了运行时完整性检查，而不仅仅是在启动时验证。在 Linux 或其他操作系统运行期间，可以定期对固件的关键区域进行哈希验证：
# ROM Armor 2 运行时验证工具（用户空间）
import hashlib
import mmap
import os
class ROMArmor2Verifier:
"""用户空间固件完整性验证工具"""
def __init__(self, device_path="/dev/mem"):
self.device = device_path
def verify_rom_region(self, offset, length, expected_hash):
"""验证指定固件区域的完整性"""
with open(self.device, 'rb') as f:
with mmap.mmap(f.fileno(), length, offset=offset) as m:
actual_hash = hashlib.sha256(m[:]).hexdigest()
if actual_hash != expected_hash:
raise IntegrityViolationError(
f"ROM region at 0x{offset:x} failed verification: "
f"expected {expected_hash}, got {actual_hash}"
)
return True
def get_measurement_log(self):
"""读取 TPM 2.0 中存储的固件测量日志"""
try:
result = subprocess.run(
["tpm2_getrandom", "4"],
capture_output=True, text=True
)
return result.stdout.strip()
except FileNotFoundError:
# 如果没有 TPM，使用内核 dm-verity
return self._get_dm_verity_status()
def _get_dm_verity_status(self):
"""dm-verity 状态检查"""
try:
with open("/sys/block/sda/sda1/dm/name", "r") as f:
return f.read().strip()
except:
return "unprotected"
2.4 A/B Recovery 分区恢复机制
这是 Coreboot 26.06 中对普通用户影响最大的功能改进。在传统 BIOS/UEFI 升级过程中，如果遇到断电、刷入损坏文件或硬件不兼容等问题，用户将面临"砖头"——系统无法启动，用户无法进入 BIOS 设置界面重新刷写固件。
A/B Recovery 机制借鉴了 Android 系统的 OTA 更新策略，将固件存储区域分为两个完全相同的分区：
# A/B 分区布局示意
+---------------------------------+ 0xFFFFFFFF
| Bootblock (Fixed) | <- 不可更新区（硬件烧录）
+---------------------------------+
| Bootblock Backup (Fixed) | <- 备用引导块
+---------------------------------+
| |
| Region A (Primary Firmware) | <- 当前运行固件
| ~8MB |
| |
+---------------------------------+
| |
| Region B (Recovery Firmware) | <- 备用安全固件
| ~8MB |
| |
+---------------------------------+
| RW Config (NVRAM) | <- 可读写配置区
+---------------------------------+
Recovery 机制的工作流程如下：
// Coreboot A/B Recovery 核心逻辑
typedef enum {
BOOT_NORMAL = 0,
BOOT_RECOVERY_A,
BOOT_RECOVERY_B,
BOOT_FACTORY_RESET
} boot_mode_t;
boot_mode_t determine_boot_mode(void) {
// 读取启动选择寄存器（Boot Select Register）
uint32_t boot_sel = read_cmos_or_gpio(CMOS_BOOT_SELECT);
uint32_t boot_count = read_cmos_or_gpio(CMOS_BOOT_COUNT);
uint32_t last_error = read_cmos_or_gpio(CMOS_LAST_BOOT_ERROR);
// 检查是否是强制恢复模式（通常是物理按键触发）
if (gpio_get_value(GPIO_FORCE_RECOVERY) == 0) {
return BOOT_RECOVERY_B; // 强制进入 B 分区恢复
}
// 检查上次启动是否失败
if (boot_count > 0 && last_error != 0) {
// 失败计数超过阈值，自动切换到备用分区
if (boot_count >= MAX_BOOT_ATTEMPTS_BEFORE_SWITCH) {
boot_mode_t preferred = (get_current_active_region() == 'A')
? BOOT_RECOVERY_B : BOOT_RECOVERY_A;
switch_firmware_region(preferred);
clear_boot_error();
return preferred;
}
return BOOT_RECOVERY_A;
}
return BOOT_NORMAL;
}
void switch_firmware_region(boot_mode_t new_region) {
// 更新启动选择寄存器
uint8_t selected_region = (new_region == BOOT_RECOVERY_B) ? 'B' : 'A';
write_cmos(CMOS_ACTIVE_REGION, selected_region);
// 记录切换事件
write_cmos(CMOS_REGION_SWITCH_COUNT,
read_cmos(CMOS_REGION_SWITCH_COUNT) + 1);
write_cmos(CMOS_LAST_SWITCH_REASON, last_error);
}
在实际部署中，用户几乎不会注意到 A/B Recovery 的存在——系统会默默在后台维护两个固件副本，并在必要时自动切换。对于服务器和高可靠性系统来说，这个功能意味着固件升级不再需要停机维护窗口，更不需要工程师到场手动修复。
2.5 Panther Lake UFS 在线加密增强
Panther Lake 是 Intel 当前一代移动处理器（代号 Nova Lake 的上一代）。26.06 版本为 Panther Lake 平台加入了 UFS（Universal Flash Storage）在线加密支持。
UFS 在线加密允许数据在写入存储芯片之前就完成加密，且整个加密过程对主机 CPU 完全透明：
// Panther Lake UFS 在线加密配置
typedef struct {
uint8_t encryption_enabled; // 是否启用硬件加密
uint8_t crypto_engine; // 选择加密引擎 (0=XTS-AES-128, 1=XTS-AES-256)
uint8_t key_index; // 使用的密钥槽索引
uint32_t dunit_addr; // DICE (Device Identifier Composition Engine) 地址
} UFS_CRYPTO_CONFIG;
void configure_ufs_inline_encryption(void) {
// 读取存储芯片的唯一 ID（用于派生加密密钥）
uint8_t chip_unique_id[32];
read_ufs_unique_id(chip_unique_id, sizeof(chip_unique_id));
// 从芯片 ID 和主密钥派生存储专用密钥
uint8_t derived_key[32];
derive_key(
master_key_from_tpm, // 从 TPM 获取的主密钥
chip_unique_id, // 设备唯一标识
derived_key, // 输出：派生的存储密钥
KDF_CONTEXT_UFS // 密钥派生上下文
);
// 配置 UFS 主控制器加密参数
uint32_t ufsc_cfg = 0;
ufsc_cfg |= (XTS_AES_256 << CRYPTO_ALGORITHM_POS);
ufsc_cfg |= (derived_key_slot_id << KEY_SLOT_POS);
ufsc_cfg |= (1 << ENCRYPTION_ENABLE_POS);
write_mmio(UFS_CONTROLLER_CONFIG_REG, ufsc_cfg);
// 验证加密通道已建立
uint32_t status = read_mmio(UFS_CONTROLLER_STATUS_REG);
if (!(status & CRYPTO_ENGINE_READY_MASK)) {
die("UFS crypto engine failed to initialize\n");
}
}
这意味着即使存储芯片被物理拆除并安装到其他设备上，数据依然无法被读取——这是企业级数据安全和防止硬件供应链攻击的关键措施。
第三部分：31 块新主板支持与 Framework Laptop
3.1 新增平台全景
Coreboot 26.06 一口气支持了 31 块新的主板和开发板，创下了近几个季度版本之最。这些新增平台覆盖了从 x86 服务器到 ARM 开发板的完整硬件谱系：
AMD 平台新增：
- AMD Crater (V2000A SoC) —— 面向嵌入式和工业应用的 AMD 平台
- AMD 主板型号待完整列表（以实际发布为准）
Intel 平台新增：
- Intel Nova Lake 参考设计（本次版本的核心）
- 多款 Intel NUC 后续型号
ARM 和 RISC-V 平台新增：
- Qualcomm Calypso SoC —— 面向骁龙 X 系列笔记本的 ARM 平台
- ARM 开发板型号覆盖 Cortex-A 系列主流平台
3.2 Framework Laptop 的 Coreboot 支持
Framework Laptop 是近年来开源硬件社区最受关注的项目之一。这家成立于 2021 年的公司，以"模块化、可修复、可升级"为核心理念，推出了目前市面上最接近开源理想的笔记本电脑。
Framework Laptop 对 Coreboot 的支持有特殊意义：
- 完全开放的基础固件：Framework 在其官方固件仓库中维护了 Coreboot 分支，用户可以自行编译和刷写固件
- AMD 平台支持：Framework Laptop 16 英寸版采用了 AMD Ryzen 处理器，其 Coreboot 支持需要完整的 AGESA 集成
- 安全与便利的平衡：Framework 提供了同时支持安全启动（Secure Boot）和 Coreboot 的刷写工具
Framework Laptop 16 的 Coreboot 刷写流程如下（适合有一定 Linux 操作经验的用户）：
#!/bin/bash
# Framework Laptop Coreboot 刷写脚本（参考流程）
set -euo pipefail
DEVICE="/dev/mtd0" # SPI Flash 设备
COREBOOT_BUILD="./build/coreboot.rom"
FLASHROM="/usr/sbin/flashrom"
BACKUP_FILE="./coreboot_backup_$(date +%Y%m%d_%H%M%S).rom"
echo "=== Framework Laptop Coreboot 刷写工具 ==="
# 步骤1：备份原始固件
echo "[1/5] 备份原始固件到 ${BACKUP_FILE} ..."
sudo ${FLASHROM} -r ${BACKUP_FILE} -p internal -c "W25Q128.V" || {
echo "备份失败！请检查是否在 BIOS 中开启了固件写保护"
exit 1
}
# 步骤2：验证备份文件
echo "[2/5] 验证备份文件完整性 ..."
if [ ! -f "${BACKUP_FILE}" ] || [ $(stat -f%z "${BACKUP_FILE}") -lt 8388608 ]; then
echo "备份文件大小异常，可能不完整！"
exit 1
fi
echo "备份完成，文件大小：$(du -h ${BACKUP_FILE} | cut -f1)"
# 步骤3：检查 Coreboot 镜像
echo "[3/5] 检查 Coreboot 镜像 ..."
if [ ! -f "${COREBOOT_BUILD}" ]; then
echo "Coreboot 镜像不存在，请先执行 make"
exit 1
fi
# 步骤4：确认刷写（防止误操作）
echo "[4/5] 确认即将刷写新固件 ..."
echo "原始固件备份位置：${BACKUP_FILE}"
echo "即将刷写的固件：${COREBOOT_BUILD}"
read -p "确认刷写？输入 'YES' 继续： " confirm
if [ "${confirm}" != "YES" ]; then
echo "取消刷写。"
exit 0
fi
# 步骤5：执行刷写
echo "[5/5] 正在刷写 Coreboot ..."
sudo ${FLASHROM} -w ${COREBOOT_BUILD} -p internal -c "W25Q128.V"
echo "刷写完成！系统将在 5 秒后自动重启 ..."
sleep 5
sudo reboot
第四部分：开发者实战指南
4.1 编译自己的 Coreboot 镜像
下面我们以一个具体的主板为例，完整演示 Coreboot 的编译过程。假设目标平台是 Intel QEMU 模拟器（这是一个无硬件依赖的入门级目标，适合学习）：
环境准备
# 安装编译依赖（Ubuntu/Debian）
sudo apt-get update && sudo apt-get install -y \
build-essential \
bison \
flex \
g++
git \
libncurses-dev \
python3 \
wget \
crossbuild-essential-arm64 \
crossbuild-essential-armel
# 获取 Coreboot 源码
git clone https://review.coreboot.org/coreboot.git
cd coreboot
git checkout 26.06 # 切换到 26.06 标签
# 初始化子模块（必须！）
git submodule update --init --recursive
编译配置
# 以 Intel QEMU 平台为例
cd coreboot
make crossgcc-i386 CPUS=$(nproc) # 编译交叉编译工具链
make menuconfig # 启动可视化配置
在 make menuconfig 的配置界面中，需要关注以下选项：
Mainboard
└── Mainboard vendor: Intel
└── Mainboard model: QEMU x86 (默认)
└── ROM chip size: 8388608 (8MB)
General
└── Use CMOS for configuration values: Yes
└── etc.
Payload
└── Add a payload: SeaBIOS (或其他选择)
└── SeaBIOS configuration ->
└── PS/2 keyboard support: Yes
└── VGA emulation: Yes
ROM chip size: 8388608 (8MB)
编译
# 完整编译
make -j$(nproc)
# 如果是真实硬件，需要为固件填充 SGAA 签名（模拟器不需要）
# ./cbfstool build/coreboot.rom add-intel-descriptor -f descriptor.bin -r GBB 2>/dev/null || true
# 编译产物
ls -lh build/coreboot.rom
# 输出类似：-rw-r--r-- 1 root root 8.0M build/coreboot.rom
测试
# 使用 QEMU 测试 Coreboot 镜像
qemu-system-x86_64 \
-bios ./build/coreboot.rom \
-m 2G \
-hda ./test_disk.img \
-display gtk
4.2 为自定义平台编写 board config
对于没有现成配置的新主板，开发者需要创建完整的 board 配置。以下是基本步骤：
# 创建新的 board 目录结构
mkdir -p src/mainboard/vendor/myboard
cd src/mainboard/vendor/myboard
# 创建 Kconfig（板级构建配置）
cat > Kconfig << 'EOF'
if BOARD_VENDOR_MYBOARD
config BOARDSPECIFIC_nvram
def_bool y
config MAINBOARD_PART_NUMBER
string
default "My Custom Board v1.0"
config MAINBOARD_VERSION
string
default "1.0"
config SLEEP_STATE_BIOS
int
default 3
# 选择使用的 FSP 版本
config PLATFORM_USES_FSP2
def_bool y
# SPI Flash 大小
config BOARD_SPECIFIC_OPTIONS
def_bool y
select SOC_INTEL_COMMON_BLOCK_SKL
select ROM_SIZE_MB_8
endif # BOARD_VENDOR_MYBOARD
EOF
4.3 使用 Depthcharge 进行自动化固件测试
Depthcharge 是 Coreboot 生态中面向自动化测试的 payload，内置了 CLI 接口和脚本能力：
# 在 Coreboot menuconfig 中启用 Depthcharge
# Payload -> Add a payload -> Depthcharge
# Depthcharge 常用命令（启动时在控制台输入 'dpch' 进入）
dpch> help
Available commands:
boot - 启动操作系统
nvram - NVRAM 读写
gpio - GPIO 状态查看
i2c - I2C 总线扫描
spi - SPI Flash 操作
tpm - TPM 状态查询
memtest - 内存压力测试
reboot - 系统重启
dpch> nvram list
boot_count = 0
debug_level = 8
boot_device = nvme
boot_index = 0
dpch> tpm status
TPM 2.0 detected: NTC NPCT75x
TPM enabled: yes
TPM activated: yes
PCR banks: SHA-1, SHA-256
第五部分：性能与安全最佳实践
5.1 启动时间优化
Coreboot 的一个核心优势是启动速度远快于传统 BIOS 或 UEFI。以下是经过验证的优化策略：
策略一：跳过不必要初始化
// 在 board config 中禁用不需要的硬件初始化
// src/mainboard/vendor/myboard/Kconfig
config DISABLE_USB_CONTROLLER_IN_BOOTBLOCK
bool "Disable USB in bootblock"
default y # 大多数系统不需要在 bootblock 阶段初始化 USB
help
启用此选项将在 bootblock 阶段跳过 USB 控制器初始化，
节省约 50-100ms 启动时间
策略二：内存训练优化
内存训练（Memory Training）是固件启动过程中最耗时的阶段之一，Coreboot 26.06 对此有专门的优化路径：
# 在 menuconfig 中启用快速内存初始化
# Chipset
# └── Memory training optimization
# └── Training mode: Quick (跳过详细边际测试)
策略三：并行化 Payload 加载
// 在 ramstage 中并行加载多个 payload（高级优化）
void parallel_payload_preload(void) {
// 同时探测多个存储设备
pthread_t nvme_thread, sata_thread, usb_thread;
pthread_create(&nvme_thread, NULL, probe_nvme_devices, NULL);
pthread_create(&sata_thread, NULL, probe_sata_devices, NULL);
pthread_create(&usb_thread, NULL, probe_usb_devices, NULL);
// 等待所有探测线程完成（设置超时）
pthread_join(nvme_thread, NULL);
pthread_join(sata_thread, NULL);
pthread_join(usb_thread, NULL);
}
5.2 安全加固清单
将 Coreboot 作为安全加固方案时，建议启用以下配置：
// 推荐的 Coreboot 安全配置宏
#define CONFIG_BOARD_HAS_CHROMEOS_NVRAM 1
#define CONFIG_HAVE_ME_RECOVERY_IMAGE 1
#define CONFIG_TPM1_MEASURED_BOOT 1
#define CONFIG_TPM_PPI 1
#define CONFIG_HAVE_CROS_VBOOT 1
#define CONFIG_VBOOT_BOOT_PAYLOAD "depthcharge"
#define CONFIG_ENABLE_MRC_CACHE 1
// 启用 ROM 保护（ROM Armor 2）
#define CONFIG_BOARD_HAS_ROM_ARMOR 1
#define CONFIG_SPI_FLASH_PROTECT 1
#define CONFIG_SPI_FLASH_WP_GPIO_ENABLE 1
5.3 NVRAM 配置最佳实践
NVRAM（非易失性 RAM）是 Coreboot 存储用户配置和运行时数据的关键区域：
# nvramtool 使用示例
./nvramtool -r boot_order # 读取启动顺序配置
./nvramtool -w boot_order="nvme,usb,hdd" # 设置启动顺序
./nvramtool -l # 列出所有 NVRAM 变量
# 常见的 NVRAM 变量
# boot_order: 启动设备优先级（逗号分隔）
# debug_level: 日志级别（0=quiet, 8=most verbose）
# boot_count: 启动计数器
# recovery: 恢复模式标记
# memtest: 内存测试级别（0=跳过，1=基础，2=完整）
第六部分：Coreboot 生态全景与未来展望
6.1 生态系统全景
Coreboot 的影响力远不止于开源社区本身，以下是它的主要应用场景：
Google ChromeOS / ChromiumOS
ChromeOS 是 Coreboot 最大的生产用户。Google 不仅大量使用 Coreboot，还持续向 Coreboot 社区贡献代码（尤其是 Intel 平台相关的 FSP 集成）。Chromebook 的快速启动特性（8 秒内从关机到登录界面）很大程度归功于 Coreboot 的高效设计。
Libreboot —— 全面自由的分支
Libreboot 是 Coreboot 的一个特殊分支，其目标是移除所有专有微码和二进制 blob，提供 100% 开源的固件解决方案。Libreboot 主要支持的老旧硬件（如 ThinkPad X200）以稳定性著称，至今仍被隐私倡导者和数字权利活动家广泛使用。
Heads —— 安全导向的定制发行
Heads 是专门面向安全敏感场景（如服务器运维、Tails 用户）的 Coreboot 定制发行版，强调以下安全属性：
- 所有固件完全可重现构建（Reproducible Build）
- 强制启用 TPM 测量启动链
- 移除网络功能（固件中完全无网络支持，消除远程攻击面）
- 支持 Nitrokey / Yubikey 的硬件认证
Dasharo —— 商业级开源固件
Dasharo 是 3mdeb 公司维护的 Coreboot 商业发行版，为 Dell、Lenovo、MSI 等品牌的商用设备提供企业级支持。相比社区版 Coreboot，Dasharo 提供了更完善的测试套件、安全审计和商业 SLA。
6.2 AI 时代的固件挑战
Coreboot 26.06 对 Nova Lake 和 Strix Halo 的提前支持，反映了固件开发在 AI 时代的范式转变：
AI 芯片带来固件复杂度爆炸
现代 AI PC 的固件需要管理的硬件组件数量远超传统 PC：
- 主 CPU + GPU + NPU（三个异构处理单元）
- 统一内存管理（Strix Halo 的内存架构将 CPU 和 GPU 的内存池合并）
- AI 加速器的固件接口（Neural Processing Unit 的固件加载、功率管理、故障恢复）
- 高带宽内存（HBM）的初始化序列（Strix Halo 的 GPU 部分可能使用 HBM 或 LPDDR6）
这意味着固件不再只是"初始化 CPU 和内存"，而是需要成为硬件系统的协调器：
// AI 时代固件的多加速器协调初始化
void init_ai_platform(void) {
// 1. 初始化主 CPU
cpu_init();
// 2. 初始化内存（CPU 和 GPU 共享内存池）
mem_controller_config mem_cfg = {
.total_capacity_gb = 128,
.cpu_partition_pct = 35, // 35% 给 CPU
.gpu_partition_pct = 65, // 65% 给 GPU/NPU
.npu_max_reservation_mb = 8192, // NPU 预留 8GB
};
init_shared_memory(&mem_cfg);
// 3. 初始化 NPU
npu_firmware npu_fw = load_firmware("/lib/firmware/intel/npu_fw.elf");
init_neural_processing_unit(&npu_fw);
// 4. 配置 AI 调度接口
AI_SCHEDULER_CONFIG sched_cfg = {
.cpu_caps = CPU_CAP_INFERENCE, // CPU 适合推理
.gpu_caps = GPU_CAP_TRAINING, // GPU 适合训练
.npu_caps = NPU_CAP_EFFICIENCY, // NPU 适合高效推理
};
register_ai_scheduler(&sched_cfg);
}
固件即平台（ firmware-as-a-platform）
传统的固件概念正在被颠覆。现代固件不仅是硬件初始化代码，还需要承担运行时管理、AI 任务调度、安全策略执行等多种角色。Coreboot 通过其模块化的 payload 机制，为这一趋势提供了良好的架构基础。
6.3 高通 Calypso SoC 支持的深远意义
26.06 版本引入的 Qualcomm Calypso SoC 支持，在高通骁龙 X 系列笔记本的背景下有着特殊意义。
长期以来，Windows on ARM 笔记本电脑的固件选择非常有限——大多数设备只能使用高通提供的闭源 UEFI 固件。Coreboot 对 Calypso 的支持意味着：
- 开源社区第一次获得了 ARM Windows 笔记本的固件话语权
- 开发者可以在骁龙 X 平台上运行 Linux 而无需依赖高通提供的闭源固件层
- 为未来 ARM 服务器和工作站的开源固件生态奠定了基础
// Qualcomm Calypso 的 ARM Trusted Firmware (ATF) 集成示意
void calypso_atf_init(void) {
// ATF (ARM Trusted Firmware) 是 ARM 架构的安全世界固件
// Coreboot 需要与 ATF 正确协作才能安全地启动非安全世界（Normal World）
// 加载 ATF 固件
void *atf_fw = load_soc_firmware("calypso_atf.bin");
// 配置 ARM Exception Level
// EL3: ATF (安全 monitor)
// EL2: Hypervisor (可选)
// EL1: Kernel/OS
// EL0: User applications
enable_secure_world(atf_fw);
set_exception_level(EL1); // 返回 Normal World
// 配置 SCU (Snoop Control Unit) - 多核一致性关键
arm_scu_enable();
// 初始化 ACP (Accelerator Coherency Port) - GPU 共享内存
init_acp_coherency_port();
}
第七部分：常见问题与故障排查
Q1: 刷写 Coreboot 后系统无法启动怎么办？
这是最常见的问题。如果系统完全不启动（黑屏、无风扇转动），说明 Bootblock 区域损坏。此时：
- 如果有 SPI 编程器（如 Ch341A）：拆下 SPI Flash 芯片，使用编程器重新刷写备份的原始固件
- 如果有双固件分区（A/B Recovery）：在关机状态下，长按电源键 15 秒放电，然后尝试重新开机触发 Recovery 模式
- 如果有 JTAG/SWD 调试接口：通过调试器直接重写固件
Q2: 编译时提示 "No rule to make target 'blobs'"？
这是因为缺少必需的二进制 blob（如 FSP、ME 等）。对于追求完全开源的用户，可以尝试：
# 使用 me_cleaner 移除 Intel ME
git clone https://github.com/corna/me_cleaner.git
cd me_cleaner
python3 me_cleaner.py -r ./coreboot/corrupted.rom
# 或者使用 coreboot-lb（Libreboot 分支）
git clone https://libreboot.org/coreboot.git
cd coreboot
# Libreboot 分支已移除所有专有 blob
Q3: Coreboot 如何与 Secure Boot 兼容？
Coreboot 本身不实现 UEFI Secure Boot，但如果 Payload 使用 GRUB2 或深度定制的 LinuxBoot，则可以与系统的 Secure Boot 机制配合工作：
# 将 GRUB2 的 shim 签名加入 UEFI DB
sudo mokutil --import /boot/efi/EFI/GRUB/grubx64.efi
# 重启后 MOK Manager 会要求你设置临时密码来授权 GRUB
Q4: 为什么 Nova Lake 的支持被标注为"初步支持"？
"初步支持"意味着以下功能可能尚未完全验证：
- 某些 PCIe 设备的稳定性
- USB4/雷电接口的全部功能
- 特定 SKU 的电源管理状态
- 休眠/唤醒（S3/S0ix）功能
建议在生产环境中等到 26.06.x 补丁版本发布后再升级。
总结
Coreboot 26.06 是近年来最具实质进步的开源固件版本之一。它不仅在支持的硬件数量上有显著增长，更在安全性（ROM Armor 2）、可靠性（A/B Recovery）和对 AI 时代新硬件（Nova Lake NPU 集成、Strix Halo 统一内存）的适配上迈出了重要一步。
对于开源社区而言，Coreboot 26.06 的发布也印证了一个趋势：固件开发正在从"闭源供应商主导"走向"社区协作创新"。 Intel 和 AMD 工程师直接向 Coreboot 仓库提交代码，标志着开源固件已经获得了与传统固件厂商同等的信任度和工程成熟度。
对于普通开发者而言，现在是从零开始学习 Coreboot 的最佳时机——丰富的文档、活跃的社区、以及 QEMU 模拟器的零硬件门槛，让任何人都可以在几小时内编译并运行自己的固件镜像。而对于企业用户，Dasharo 等商业发行版则提供了生产级所需的支持保障。
固件是计算系统最底层也最容易被忽视的组件。当我们惊叹于 AI 模型的强大能力、享受 8 秒开机的便捷体验时，背后是 Coreboot 这样的开源项目在日复一日地默默付出。26.06 版本，是这份努力的最新结晶。
参考资源
- Coreboot 官方文档：https://doc.coreboot.org/
- Coreboot 26.06 发布说明：https://www.coreboot.org/releases/26.06
- Intel FSP 文档：https://github.com/intel/FSP
- AMD AGESA 文档：https://www.amd.com/en/developer/agesa.html
- ROM Armor 2 设计文档：https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/main/src/security/rom_armor/
- Framework Laptop Coreboot 支持：https://frameworkdesktop.com/blog/2024/01/firmware-open-source
- Heads 安全固件：https://osresearch.net/
Tags: Coreboot|开源固件|Intel Nova Lake|AMD Strix Halo|ROM Armor|A/B Recovery|FSP|UEFI|启动优化|固件安全|KVM|硬件虚拟化|LinuxBoot|可信启动|Qualcomm Calypso|Phoenix Lake|Framework Laptop|深度定制
Keywords: Coreboot 26.06，开源固件，BIOS 替代，Intel FSP，AMD AGESA，可信启动，Verified Boot，TPM，固件安全，A/B Recovery，开机优化，NPU，AI PC，ChromeOS