Libreboot 26.10 "Ominous Olive" 发布，新增 UEFI 与 Chromebook 支持

返回索引

文章作者：Leah Rowe

发布日期：2026年10月15日

• <<
• < 上一页
• 下一页 >
• >>

你可以在 https://rsync.libreboot.org/stable/26.10/ 找到今天的版本，或者使用其中一个 镜像。

Libreboot 是自由、开源的启动固件，用于在受支持的 Intel/AMD 和 ARM64 硬件上替代专有的 BIOS/UEFI 固件。它初始化计算机内部的硬件，例如 CPU 或内存控制器，以某种方式配置机器，从而在启动时能够使用 Linux 或 BSD 等操作系统——而现在 Microsoft Windows 也兼容了，因为 Libreboot 通过 MrChromebox EDK2 payload 添加了完整的 UEFI 支持。与专有固件相比，Libreboot 提供更高的安全性和可定制性；其目标简单来说就是让世界摆脱专有软件，为此，我们因此尝试提供极其易于非技术用户理解的固件。

今天的版本更新日志是相对于上一个 Libreboot 26.01 版本而言的。

这是一个非常特别的版本，无论硬件变化如何，都做出了若干重大设计变更，因此用户应非常仔细地阅读此更新日志——并读两遍。

先说最重要的。（是的，你上一段没看错）

一个新的文件被加入了一条强烈的反 AI 政策：lbmk 中的 AGENTS.md。这是本版本中最重要的变更。现在说其他内容：

警告：本版本做出了重大设计变更，可能会影响大量现有配置。我们现在使用 EDK2 作为默认 payload，并在闪存中提供 GRUB/SeaBIOS 的 EFI 构建版本以保持向后兼容。一切都能正常工作，但有一些注意事项，因此请非常仔细地阅读本版本更新日志。

第一个重大变更是：

主板完整列表相当长，因此展示在本文末尾。全部 233 个！

MrChromebox 支持几乎每一款 Chromebook，而本版本从该项目导入了所有主板。这包括直到最新 Intel 和 AMD 硬件的所有内容。

从 MrChromebox coreboot 发行版导入了当前支持的全部 233 款 Chromebook。Baytrail（Kip）已测试——其他需要测试。本版本仅提供源码（必须从源码构建，不提供二进制文件）。

这是用我在 util/mrimport/ 编写的一个实用工具完成的，它为 lbmk 生成配置，包括修订版本和子模块。我手动做了进一步调整；上游的后续更新可以通过再次对比不同修订版本之间 mrimport 的输出，在 Libreboot 中同步，并适配到 Libreboot，而不考虑后者众多的修改——这些修改将在接下来介绍。

Libreboot 在其版本中对 MrChromebox coreboot 做了以下修改：

• 为 coreboot 使用由 MrChromebox 提供的 EDK2 UEFI payload；我们将背景颜色设置为 Libreboot 紫色，并使用 Libreboot 彩虹标志而不是 coreboot 标志。除此之外，我们的 EDK2 构建目前完全相同，除了接下来的变更：
• 在构建时默认设置 HAP 位，以禁用 Intel ME。在 MrChromebox coreboot 中，它默认并未被可靠禁用，因为大多数使用它的人是通过基于软件的刷写脚本，并按照 MrChromebox 文档所示禁用 Google 的安全机制。我们在这里将其禁用。注意：我们还支持众多 AMD Chromebook，在此上下文中与此无关。
• 通过 ifdtool 解锁 IFD 区域（正确处理各种特殊情况），在构建时将其设置为读写。这样做是为了避免修改 MrChromebox 提供的每一个 Intel Flash Descriptor，因为这样的描述符有数百个。
• 在 EDK2 内部添加了 CSMWrap（将 SeaBIOS CSM 封装在 EFI 中），以向后兼容旧版 Libreboot 发行版中的裸机 SeaBIOS。
• 在 EDK2 内部提供了 GRUB EFI 构建，同样是为了向后兼容——从用户的角度来看，它的行为与 coreboot 载荷版本的 GRUB 完全一致，甚至以相同的方式从 CBFS 读取配置。
• 在 EDK2 内部添加了 MemTest86+。
• Haswell Chromebook：使用原生 raminit 而非上游的 MRC。
• 所有至 Kabylake 的 Intel Chromebook：使用 libgfxinit 而非 GOP；上游此后也在更新的世代上这样做了，这将在发布后集成。

如上所述，这些额外的载荷可在启动时按 ESC 键通过启动菜单使用。与上游一样，iPXE 在特定主板上也默认启用。EFI GRUB 和 CSM SeaBIOS 已取代这些的 coreboot 载荷版本；裸机 SeaBIOS/GRUB 现已弃用，并可能在未来的 Libreboot 发行版中移除，尽管愿意从源码构建 Libreboot 的人可以重新启用它们。

这并非 MrChromebox 的分支，MrChromebox 应被视为 Libreboot 在 Intel/AMD Chromebook 上的上游。与常规 coreboot 一样，将努力始终尽可能与其保持同步。我与 MrChromebox 进行了广泛合作，甚至向他的项目提交了一些小修复；他还应我的请求实现了基于 CBFS 的 VBT 和 GOP 处理，我将在发布后集成。

无论如何，MrChromebox 自己的安装脚本应该能与 Libreboot 镜像一起使用，因此请查看 MrChromebox 文档进行安装。尽管有变化，Libreboot 的设置在行为上仍与 MrChromebox 的兼容，因此 MrChromebox 工具应仍能与相应文档一起使用。

这得以实现 得益于 Libreboot 构建系统的一项新功能：支持每个项目任意数量的上游。我们仍在非 Chromebook 主板上提供常规 coreboot。

是的，233 个。我数过。全部自动化。我的脚本和我的严谨确保了我在 lbmk 中导入和配置的内容与上游紧密匹配，并且我非常小心地在 Libreboot 内部维护自己与它的差异。

是的，Libreboot 现在可以在 Chromebook 上运行了！

例如 KGPE-D16。我们现在在 AMD Fam15h 主板上使用来自 15h.org 的 coreboot 分支。它使用 AMD AGESA 源代码而非 Timothy 的自定义初始化代码。它具有更可靠的 raminit 和 CPU 初始化；还支持更多内存。许多错误已修复。IOMMU 正常工作，我还看到他们提到 TPM 在他们的版本中已修复，现在我们的版本也是。

提供了带有 SeaBIOS 和 GRUB 载荷的常规二进制文件——我们还有实验性的基于 EDK2 的镜像，目前仅提供源码（无可用二进制文件）。EDK2 需要设置帧缓冲，而集成的 AST2050 芯片在原生初始化时仅以文本模式启动；厂商 VGA ROM 可以设置 VESA，但我们不会使用 VGA ROM。在这些主板上，基于 EDK2 的镜像仅提供源码，旨在与显卡一起使用。

基本上，这些主板第一次真正能用了。

EDK2 是 Intel 对 UEFI 规范的参考实现，用于引导。它通常被厂商用于 Intel 的 BSD 许可代码的专有分支中，但 Intel 的参考代码是自由软件。我们使用他们的参考代码，完整源代码在本 Libreboot 版本中提供。EDK 是 EFI Development Kit 的缩写。

更具体地说：

我们使用 MrChromebox 提供的 EDK2 分支，该分支专门将 EDK2 用作通用的 coreboot 载荷。这是一个完整的、行业标准的 UEFI 实现，能够引导任何符合规范的操作系统。

全部。现在几乎所有主板都在 Libreboot 中使用它，甚至更老的型号，例如 ThinkPad X200。已在所有平台上测试。较旧的、仅支持 32 位的主板仍使用上一版本中的设置，而几乎所有兼容 64 位的硬件现在都使用 EDK2。GRUB 和 SeaBIOS 的 EFI 构建版本已提供在闪存中，可从 EDK2 设置菜单访问（引导时在提示处按 ESC），以便与 Libreboot 中现有的 Linux/BSD 安装向后兼容。

EDK2 支持最初是作为 Chromebook 的先决条件而集成的，但后来被扩展用于 Libreboot 中所有先前已支持的主板。它甚至在非常老的机器上也能良好运行，例如 ThinkPad T500。

现在所有 Libreboot 主板在可行的情况下都默认使用开源 UEFI 实现。所有主板，而且是默认——裸机 GRUB 和 SeaBIOS coreboot 载荷已被移除，替换为向后兼容的 EFI 版本。

我们以前根本不提供 UEFI，除了在少数精选主板上提供 U-Boot。现在我们在几乎所有 Libreboot 支持的主板上提供完整的 UEFI，且四大自由完好无损。

以下所有操作系统均已在各种使用 EDK2 的 Libreboot 机器上测试并确认可正常工作：

• Windows 10 和 11
• 9front（Plan 9 的分支）
• 各种其他符合 UEFI 规范的操作系统
• Linux UKI 引导加载程序、systemd-boot 等。UKI 现在可以完美工作，从 EDK2 引导。现代 Linux 发行版设置现在可以工作（不需要 GRUB）。
• 带 EFI 引导加载程序和 GPT 分区的 OpenBSD（较旧的 SeaBIOS txtmode 在 Libreboot 中只能进行 MBR 分区）
• UEFI 模式下的 FreeBSD——不再需要 txtmode！
• 遗憾的是，ReactOS 无法工作（不支持 UEFI）
• RedoxOS 可能也能工作。

现代计算机和操作系统都是 UEFI，这个新设置基本上可以可靠地引导所有这些系统。还需要更多测试，但这是经过实战检验的代码，许多用户已在 coreboot 中广泛使用多年。Libreboot 终于也有了它。

仅这一变化就是使 Libreboot 现代化这一更广泛努力的一部分，而我才刚刚开始。接下来的 Libreboot 版本将大量依赖于此，因为如今 EDK2 几乎是许多现代 coreboot 设置中预期的载荷。EDK2 的集成消除了 Libreboot 中的所有限制，使我们能够支持更新的硬件，并且基本上让 Libreboot 更易于使用；因此，我预计 Libreboot 会随着时间推移变得更受欢迎、更有用。

本发布页面末尾提供了一些注意事项和额外说明，用于迁移目的。例如，尽管吹嘘所有，较旧的仅支持 32 位的硬件仍使用裸 GRUB/SeaBIOS。然而几乎所有主板都使用 EDK2！

最后，还有一些关于显卡的说明，可能对要求更高的用户有用。

EDK2 配合 PCI-E 可重定位 BAR（rebar），意味着你现在可以使用需要 4GB 以上分配空间的现代显卡。rebar 默认未启用，但你可以在 menuconfig（coreboot）中启用它。在测试中，启用它会导致 libgfxinit 上的 Intel GPU 视频输出损坏，且尚未找到修复方法，因此 rebar 默认禁用。

对于 EDK2 构建，PCI-E Option ROM 在必要时默认启用。这意味着你可以在配有显卡的台式机上使用它。已在多台台式机上测试（Dell OptiPlex 9020 SFF 和 5050 SFF）。

在仅有独立 GPU 的主板上，rebar 可以默认保持启用。在集成显卡正常工作的系统上，意外启用 rebar 可以通过插入显卡来补救；当 payload 中的视频输出确实损坏时，Linux i915 视频驱动仍能在 KMS/DRM 中正确初始化视频帧缓冲。

这将被加入通用文档，等待上游修复。请注意，即使存在此问题，Linux 视频输出仍能正常工作。在未来的 Libreboot 版本中，此问题将被修正，rebar 将默认启用。

几乎所有主要上游修订版均已更新：

• Flashprog：更新至 2026 年 9 月 24 日修订版
• EDK2：导入版本 26.09.2
• GRUB：更新至版本 2.16
• Coreboot（默认树）：更新至截至 2026 年 9 月 18 日的提交 ID 8ce4c91c41da3f042979f92095149a85bc93227d。
• Coreboot（mrchromebox）：导入 MrChromebox coreboot 的提交 ID e5997cf9384b29082a1bf3101813d8ac3dadda42，用于 Chromebook。
• Coreboot（fam15h）：已移除（4.11_branch 树），并替换为：
• Coreboot（fam15h_15h）：截至 2026 年 5 月 27 日的提交 ID 57e26bdcd959808c0171164f3c6197d4a347c3b2。这是来自版本 4.11_branch 的 coreboot 大幅改进分支，用于提高 AMD FAM15H 硬件（例如 ASUS KGPE-D16）上的初始化可靠性。
• SeaBIOS（非 CSM）：更新至截至 2026 年 7 月 28 日的提交 ID 81ec9ec0bcf45df11fb7f98339ec9036b546fca0。

coreboot 的 4.11_branch 树已被移除，因为我们现在在 AMD Fam15h 硬件上使用 15h.org 的 coreboot 分支。这有了很大改进，采用基于 AGESA 的正确初始化，能更可靠地初始化 CPU 和内存控制器。支持更多 RAM，并且修复了若干功能，例如 IOMMU 和 TPM。

lbmk 的一项设计改进使所有项目都支持多树，从而实现了多个 coreboot 上游的使用，只是有些项目仅使用一个树。我们现在可以为每个项目拥有 N 个上游，从而能够使用分支。

coreboot 更新在 crossgcc 中引入了 GCC 15.2、MPC 1.4.1、Nasm 3.02、acpica 20251212 和 binutils 2.46.1。

MrChromebox 当前支持的全部 233 款 Chromebook 均已导入并适配以供 Libreboot 使用。它们全部都能编译。全部。我重复一遍：

• 从 MrChromebox 导入了 233 款 Chromebook。MrChromebox 项目支持的每一款 Chromebook 现在都能在 lbmk 中构建，并带有 lbmk 的更改。感谢 Matt DeVillier 的出色项目！

除 Chromebook 外还添加了更多硬件：

• Dell OptiPlex 5050 SFF 支持，由 Ron Nazarov 提供。
• Supermicro X11SSH-F 主板支持 - Ron Nazarov 所做的改进，例如通过 deguard 使用经过处理的常规 Intel ME - 没有 bootguard，但 deguard 通常也可用于为每块主板提供预配置的 ME。该主板原本使用 SPS。使用常规 ME 时，我们确实需要比清理过的 SPS 更大的 ME 区域。使用常规 ME 意味着 MRC 缓存可以工作，因此重启时 raminit 训练要快得多（无需在每次启动时都重新训练）。
• ThinkPad X280 支持由 AlguienSasaki 提供
• ThinkPad X270 支持由 Kat Inskip 提供
• Dell OptiPlex 3040 Micro 支持由 Todd Baker 提供
• 移除了 ThinkPad X301 目标上的 release="n"。它实际上启动得很好，尽管相当慢。EDK2 甚至也能工作。

我们在 EDK2 内添加了 SeaBIOS CSM 和 GRUB EFI 构建，以与 Libreboot 较旧的 GRUB/SeaBIOS 载荷设置保持一致。EFI 载荷的工作方式基本相同。

使用 EDK2 使得支持较新的机器更加容易，这将是今后的重点。EDK2 首先推出，作为整体现代化努力的一部分；较新的 Intel 和 AMD 硬件将随时间推移陆续添加，默认仅使用 EDK2 载荷。

这非常像是一个功能版本。做了大量功能更改！

• 在所有具有至少 4MB 闪存的 Intel/AMD 主板上支持 EDK2 载荷。这使用了 MrChromebox 版本的 EDK2，Libreboot 进行了大量修改，例如向其添加 GRUB EFI 和 SeaBIOS CSM（CSMwrap）构建；这些是为了向后兼容较旧的单独 SeaBIOS/GRUB 载荷设置而提供的，并且仍应能启动现有的 Linux/BSD 安装。
• 通过 EDK2 载荷（ESC 菜单）添加了 iPXE 启动方法 - 仅限 EDK2（在较旧主板上单独的 SeaBIOS 载荷中不可用）。
• 添加了新命令 ./mk import_uboot，用于自动导入 U-Boot 配置，然后可在 lbmk 中构建。尚未使用，但这将用于在未来版本中添加经过测试的 U-Boot 主板（U-Boot 本身提供自己的初始化）。Libreboot 已经可以从任何配置构建 U-Boot 镜像，无需更改代码，只需更改配置，但需要在硬件上进行测试。
• util/mrimport 处的新工具，用于自动从 MrChromebox coreboot 导入/更新新配置。这也用于从 MrChromebox 初始导入 233 台 chromebook，将它们连同我们自己的修改导入到 Libreboot 构建系统中。
• 在 EFI 版本的 GRUB menuentry 中添加了 fwsetup 命令，可启动回 edk2 设置菜单。
• 修改了 Kabylake 主板上的 IFD，以支持引脚修改。这使得可以使用六核和八核 Intel CPU。
• 在构建时随机化 MAC 地址，仅在未设置 XBMK_RELEASE 时。你可以通过环境变量 XBMK_MAC 导出 MAC 地址以任意设置它。当直接处理 .rom 文件而不是发布 tarball 时，这避免了在构建后提取 NVM 并重新插入的需要，而发布 tarball 已经通过 ./mk inject 具备此能力。
• GRUB at_keyboard 驱动：始终强制使用带转换的扫描码集 2。这已经做到了，但仅在 coreboot 目标上；现在也在 EFI 目标上做到了，只需将其普遍应用于所有目标。这是因为在 EDK2 上可以将其与 PS/2 键盘一起使用。它缓解了可能有问题的 PS/2 控制器，这些控制器即使在设置后也可能无法正确报告模式，就像在 Dell Latitude E6400 上那样。
• 我把 Memtest86+ 做成了紫色（在 EDK2 构建上）。Libreboot 紫。红色值 0x28，绿色值 0x0b，蓝色值 0x22。这就是 Libreboot 紫。
• 我也把 EDK2 做成了紫色，并向其中添加了 Libreboot 的彩虹标志。
• 在 GRUB payload（EDK2 和 coreboot 目标）上，通过通配符扫描给定分区中的每个 ESP 目录。这意味着如果使用 GRUB 或 Syslinux 配置，它将启动更多非 UKI 的 Linux 发行版设置。
• 在所有使用 EDK2 的目标上，在可用时启用 TPM。
• 新增了 ./mk cbtest 命令，用于将板名与 lbmk 和 coreboot defconfig 进行比对，以防上游发生变化。否则，如果 Kconfig 规则随后选择了默认项，我们可能会在不知不觉中改变为给定目标构建的实际板卡。在构建时无法以干净的方式自动检测这一点，因此在更新 coreboot 修订版本时应使用此命令。
• 新增了 ./mk test 命令，它会激进地构建所有内容，甚至比 ./mk release 还要多——它有意禁用缓存的使用，以便下载也能被激进地测试。与配置相关的命令也会被测试。这是一个用于查找构建错误的残酷压力测试命令。
• Flashprog：在命令循环期间始终保持 flash IC 热插拔，而不是以切换方式进行。--workaround-mx 选项被保留，但不再起任何作用，因为其行为始终被应用。这提高了总体可靠性，因为很多用户根本不知道这个选项。现在更多人能够可靠地刷写他们的板卡。
• 新增了 mkhelper 类型：preconfig。这让你可以在使用配置文件的给定项目上进行配置之前运行自定义逻辑。它也适用于 noconfig 项目。例如在 coreboot 上使用它来构建工具。
• 在构建系统中全面移除了 ccache 的使用，因为它在若干压力测试场景中导致了微妙的构建错误（可能还有代码缺陷）。我们宁愿多等一会儿以获得可靠的构建。CCache 实际上只适用于开发，而非生产。
• 移除了 lbmk 中的 -c 和 x（clean 和 xgcc-clean）标志，因为它们基本上是多余的；lbmk 在构建前已经自动清理所有内容，以移除所有构建产物，并基于配置元数据在树外激进地缓存构建，根据需要从本地缓存中删除并重新获取源代码。这些选项毫无用处。
• 如果 makefile 检查失败，则正确跳过构建；这允许单树项目构建，通过防止在没有文件存在时容易出错的 copy_elf 使用。
• mk：移除了 GCC/GNAT 版本配对，因为上游（coreboot）现在在其 buildgcc 脚本中执行此操作。这在 lbmk 中是多余的。coreboot 的版本更好，因为它只是报错并退出，而不是尝试继续；后者是我们所做的，在某些情况下实际上可能导致更多缺陷。宁可硬失败，也不要破坏构建。
• 为 GRUB 添加了丹麦语键盘映射。

进行了大量重大设计变更！

• GRUB 启动配置简化；现在启动只有一个 menuentry，它会启动所有内容，首先尝试 USB。它选择它找到的第一个配置，但你可以按 ESC 循环到循环中的下一个。对于多重引导多个 Linux 发行版很有用。
• coreboot 上现在使用简短 defconfig，而不是完整配置。这便于维护，并且 lbmk 已被修改以适应它们。注入脚本在运行时仍会自动解析完整配置，这是构建时扫描路径所需的。使用 defconfig 减少了更新期间配置中出现错误更改的可能性，并使使用 olddefconfig 成为可能，而不是使用可靠性较低的 oldconfig 命令。
• 新的安全检查：在逻辑中使用路径前缀时，验证是否已设置该前缀。否则，lbmk 中可能存在目录逃逸漏洞。在整个构建系统中，这一点会被严格检查。
• 不再导出 XBMK_CACHE，因为它现在已在配置中硬编码。新的处理方式更加严格，未来修订中发生回归的可能性更小。这样做是为了降低 lbmk 中出现目录逃逸漏洞的可能性。
• 修复了 GRUB 模块列表不再按 GRUB 树使用的问题。现在，所有模块都按目标添加，但会应用一个按树配置的黑名单。
• GRUB Syslinux 和 GRUB 扫描现在在 GRUB 配置上合并为一个函数。对 GRUB 配置进行了总体简化。
• GRUB 现在是一个源码树，多个目标都复用同一个树，只是使用不同的配置。
• 修改了 MrChromebox coreboot，仅当 coreboot defconfig 中未选择视频模式时才添加 EDK2 GOP 二进制文件。这避免了不必要的添加，从而在使用 FSP 初始化或 libgfxinit 时节省闪存空间。
• 始终在 include/env/get.sh 上使用 --mirror git 克隆。这使得在所有项目上克隆修订版本更加可靠，尤其是在我们使用 main 以外分支中的修订版本的项目上。
• 在所有基于 Intel IFD 的系统上，构建时自动解锁 IFD 区域；通过设置 HAP 位自动禁用 ME。我们在 Chromebook 上就是这样做的，但现在所有主板都这样做；这降低了未来在特定目标上意外忘记阉割 ME 的可能性。
• 在构建 EDK2 时，我们使用 coreboot 的构建系统，但这样做时，映像文件名中不使用 custom_ 前缀。而是使用正确的 edk2 前缀。这使得它适用于 Chromebook，因为在此版本中 Chromebook 按主板构建 edk2；Chromebook 上不处理通用 EDK2 构建。在非 Chromebook 上，我们使用 EDK2 和 SMMSTORE 构建一个虚拟的 ThinkPad T440p 构建，然后通过 include/fw/rom.sh 中的 shim 逻辑以更通用的方式提取它，以便插入其他主板。
• 移除了 coreboot 中的 fspcc36ae2b5775fa7400cb3282680afc0f6cb37a3c 子模块，该子模块用于 Topton X2E N150。我们现在使用最新的 FSP，但这意味着在进行供应商注入时会破坏较旧的构建。这是不可避免的。
• 添加了一个 noconfig 变量，可由构建树/目标设置，适用于多树但不使用配置的情况。这使其在编译时以 noconfig 的假名出现，例如 elf/grub/default/efi/noconfig/grub.elf。
• get.sh：在 find 命令中使用 -L，因为一些项目现在使用指向其他项目元数据的符号链接来确保重新构建。例如，edk2 coreboot 目标（虚拟目标）依赖于 grub 和 seabios efi 构建。当这些构建必须更改时，我们需要确保重新执行 edk2 coreboot 构建。这里，我们指的是在构建系统设置中检查给定项目是否已更改时，用于查找要哈希的文件的 find 命令。
• 按目录名称正确排序子模块，以便在项目中处理递归子模块。这是在 get.sh 上的子模块处理中。
• get.sh：支持任意子模块配置路径，适用于使用同一子模块多个版本的项目。例如，EDK2 使用多个版本的 brotli。
• 移除 SeaGRUB；对于仍使用 coreboot-payload 版 SeaBIOS 和 GRUB 的主板，我们现在只制作以 GRUB 或 SeaBIOS 作为主 payload 的镜像。SeaBIOS 的 payload 加载并不总是可靠，而 GRUB 的分配器自几年前以来已有显著改进。我们现在还在大多数主板上使用 EDK2，因此测试 GRUB 仅适用于仍独占使用它的少数主板，这变得可行得多。这种简化是永久性的，因为独立的 SeaBIOS/GRUB 现已过时；EDK2 现在是首选 payload，SeaBIOS 和 GRUB 的 EFI 版本被拼接到 EDK 菜单中，以向后兼容旧的 Libreboot 设置。
• 在构建项目之前更强地使用 make distclean，这得益于 Libreboot 基于 lbmk 中元数据检查对项目构建进行积极的树外缓存。
• 允许在项目上使用 noconfig=n，这使其可以多树，并在不同目标上使用同一棵树，即使不需要构建配置；在某些情况下，配置完全在 mkhelper 设置中完成。这是 Libreboot 决定让所有项目多树的一部分，同时允许每个项目使用 N 个上游，而不是仅一个上游。
• 简化 lbmk 中的 release=n 处理；不执行 mkhelpers。如果 release=n，则跳过源码获取，这样相应的源码就不会被下载。这对于在发布中排除 MrChromebox 源码以及构建是必要的，因为它们尚未准备好用于 Libreboot 的稳定发布。
• init.sh：可移植的 date 用法；现在使用 git 自身的日期处理。我们不再依赖 date 命令的 GNU 特定扩展，用于发布构建中的 git 仓库初始化。
• 允许从主工作目录之外运行 mk。构建系统现在会相应地更改工作目录。
• 在 get.sh 中运行 git am 时启用三方合并——这使得项目修订的更新更容易。

• 大多数主板仍使用 CBFS 或 NVRAM 选项表（静态选项表，或修改 CBFS）。少数主板，如 HP EliteBook 820 G2 和 Topton X2E N150，使用基于 SMMSTORE 的选项配置，但尚未在 lbmk 中设置。
• 在 coreboot（默认树）中全树将 me_state 默认设置为 Disabled。我们已经在 IFD 中设置了 HAP 位，但这是额外的禁用层，以确保 Intel ME 死得不能再死。
• 优化了 GRUB 模块；现在包含所有 FS 模块，启动时 GRUB shell 中显示的错误更少。模块经过总体优化，以确保与默认上游设置相比仍不会占用大量闪存空间。
• 在依赖项中添加了 xxd，这是 CSMWrap 在制作 SeaBIOS EFI 构建时所需的，因为它在 SeaBIOS CSM 构建上运行 xxd -i 以创建头文件，然后这些头文件被包装在 CSMWrapper 的 shim 代码中。
• 更正了 Dell OptiPlex 5050 的 DMI 字符串代码，使其显示为 5050 SFF，而不是 3050 Micro。
• 在 vendor inject 脚本中不要使用 dell.com 作为主要下载镜像。这减少了人们注入使用 deguard 的镜像时的下载错误数量。
• 扫描所有设备上的所有 GRUB 配置，而不在 GRUB 中使用固定设备列表。相反，使用星号。还检查更多 BTRFS 子卷，同样通过使用星号。
• 对 GRUB 配置进行一般清理。移除了冗余功能，例如 对 gfxterm 的操作。默认设置工作正常。GRUB 在串行输出方面从来都不太可靠，而且大多数现代计算机不支持 GRUB 在此上下文中支持的任何接口。
• 在依赖项中添加了 ImageMagick（EDK2 启动徽标所需）。
• SMMSTORE 默认启用，在所有使用 EDK2 作为 payload 的目标上。这意味着 Libreboot 用户现在可以在启动时进入标准设置菜单，以持久且无需重新构建固件的方式配置他们的机器（例如启动顺序）。
• 为 KCMA-D8 和 KGPE-D16 主板添加了 4MB 和 8MB 目标。同时在这些主板上使用 15h.org 的 coreboot 分支，以改进 raminit 并修复各种错误。它使用 AMD AGESA 源代码，而不是 Raptor Engineering 编写的自定义源代码。修改后的 AGESA 代码具有更好的 CPU 和内存初始化，支持更多硬件组合，并支持更高的内存容量。

• 合并来自 Alguien 的补丁，修复 IFD 区域（设置为读写）并清空 ThinkPad X280 上的 OEM 部分。超线程也被禁用。
• 预防性构建修复：在可行的情况下，在所有项目中移除了对 -Werror 的使用。
• 修复了 ThinkPad X230 目标上的挂起错误，该错误由一项优化引起——现已为此修复回退——该优化优化了 coreboot 中的 CAR 设置。此修复回退了 coreboot 修订版 97dbfd3098ae12ef3f51e5f95cd6d66c25214205。此回退由 HustlerOne 在其新的 Snowboot 项目中完成，并从 Snowboot 复制到 Libreboot 项目。
• 为多个项目添加了假的 menuconfig Make 选项，以便相关的 mk 选项不会导致构建错误（取而代之的是无害的空操作）。
• mk：在运行 config 命令时，仅在 defconfigs 实际存在时才将其复制回来。这修复了 ./mk -s seabios，它从不保存 defconfig 文件。
• 将若干构建修复回溯移植到我们 2025 年初的 U-Boot 修订版，以便它能在现代发行版上构建，例如最新的 Arch Linux 更新。（需要这样做，以便 GRU Kevin/Bob Chromebook 能够继续构建）。
• 移除了 src/gpio-scripts，因为所用版本的许可不明确。（对其更改未给出许可，从 coreboot 分叉为独立项目，在 coreboot 中它回退到 coreboot 的 COPYING 文件，但分叉仓库中完全没有许可——因此所做的更改也不明确）。
• 修复了从 MrChromebox 导入的 Intel/AMD Chromebook 主板上若干损坏的供应商文件路径。这些修复也已提交并合并到上游的 MrChromebox 项目中。
• vendor.sh：捕获 coreboot defconfigs 中的所有 make 变量，运行 make-olddefconfig 并将它们全部解析为正确的值，其中涉及路径。它们以对 sh 友好的方式转换，处理方式避免意外运行错误的子 shell。
• 更安全地处理 defconfigs；更严格的错误检查，包括对 noconfig 项目。
• 修复了 mk 中在解析项目中的树/修订版时缺失的无限循环检测。现在可以检测到无限引用其他树的树。
• 修复了 pico-serprog 在 GCC 16 上的构建错误（在最新的 Arch Linux 上测试）
• 在 coreboot/default 上使用 std=gnu2x 而不是 std=gnu23；gnu2x 在较新的 GCC 版本上与 gnu23 代码兼容，但在例如 2024 Linux Mint 发行版中使用的较旧版本否则将无法构建。这修复了较旧的发行版，而在较新的发行版上行为不变。
• 不要在 src/biosutilities 中构建 bios_extract——没有构建问题，但我们在 Libreboot 中实际上根本不使用 bios_extract。我们使用该仓库中的一些脚本，不需要编译。
• 更新了 Dell OptiPlex 3040 Micro ME_bin_hash，使自动下载正常工作，因为它在初始导入时是损坏的。
• vendor.sh：在 me_cleaner 命令中使用 -w 而不是 --whitelist，因为后者在某些情况下因某种原因失败。使用 -w 是可靠的。
• 只有在主 mk 脚本中设置了 if_skip_build 时才跳过 make，以便对所有项目更彻底地执行 mkhelper。
• 在使用 dry build 模式时，更严格地防止 GRUB 中的构建例程；在某些情况下，它可能试图将不存在的 GRUB 载荷添加到从未编译过的、不存在的 ROM 中。此类检查已在 lbmk 中全面收紧并推广。
• 在设置 lbmk 时，为几处 command -v 的使用添加了缺失的错误处理。
• 预防性修复：在 mk 中调用 x_，包裹 xbmk_init。后者从不返回非零状态，因此此修复纯粹是预防性的，以防该函数在某个时候被重新设计为那样做。
• mk：修复多树命令参数中的通配符问题。我们之前用参数填充了一个字符串，但现在我们使用 dollar-ampersand 并通过 shift 循环遍历参数，从而可以正确处理双引号。
• 在发布构建中重新初始化 lbmk 时，完全导出 git 作者/提交日期。这在每个相关的 git 命令上都会执行，以实现确定性操作。
• Fam15h coreboot：修补掉 __unused 变量，并在未使用它们的地方将其强制转换为 (void)，以防止 GCC 16 中的构建错误。
• 在 lbmk 中添加了 Gentoo Linux 依赖项设置。
• 修复离线 GRUB 构建。构建系统会缓存源代码和仓库，但 GRUB 中有自定义逻辑，用于从 translationproject.org 下载无版本号的 PO 文件——所以当我在 FOSDEM 演讲时，我的演示失败了，因为网络断了，而我错误地以为我已经缓存了一切。GRUB 被修改为不下载这些文件，改由 lbmk 缓存它们。它们现在也通过校验和进行版本检查；上游实际上没有提供版本控制，但其内容已被检查，后续更新将检查它们之间的差异。基本上，translationproject.org 上的内容与 GRUB 中的当前 HEAD 相关。这没问题，因为 gettext 的工作方式是，如果某个字面字符串未定义，它会回退到原始语言。因此在这种情况下，使用错误的 PO 文件只会导致某些句子未被翻译。不过，文件处理方式中的一个 bug 可能会导致……缓冲区溢出，发生在 GRUB 正在下载且未检查哈希的无版本号文件上。是的。Libreboot 通过 fork 包含这些文件的仓库并保持其静态，修复了这个可复现性问题。下次我演讲时，我的演示不会失败。我在演讲后几个小时就修复了这个问题。

对 util/nvmutil/ 进行了大量更改，以至于它值得拥有自己的发布日志：

• 更安全地使用宏（使用括号）。
• 移除了基于 errno 的错误处理。仅根据逻辑错误返回零或一，但不要依赖 errno 的状态来进行错误退出。仅在 libc 函数中适当的情况下使用符合 POSIX 的返回值。然而，相应地，在从 libc 函数返回后，errno 重置的处理更加可靠；这不是必需的，但也不被 POSIX 所反对。—— dell-flash-unlock 的 errno 处理也以相同方式修复。我们之前严重依赖 errno 来退出，方式不可移植。并非所有 libc 都会正确重置它，并且即使某个函数逻辑上成功返回，也可能随机设置它。任何数量的事情都可能设置它，因此它不是通用错误处理的可靠机制。
• 不要使用 -pedantic 标志——同时在 spkmodem-recv 上移除它。减少基于警告的迂腐构建错误的机会。
• 常规正确性修复；边界检查、正确处理字对齐、转换指针时使用 uintptr 等。经过大量审计，代码在内存管理方面总体上安全得多。
• 为各种函数提供 EINTR 安全包装器；循环直到 EINTR 清除，若发生错误则退出，否则在非 EINTR 错误时返回 err-exist。在 close() 上正确忽略 EINTR，如果函数返回错误（在 POSIX 中，close 上的 EINTR 不是错误条件，在这种情况下应忽略描述符）。
• 针对 OpenBSD 的更多测试和修复，尤其是在内存管理方面（OpenBSD 中的 libc 严格得多）。
• 为 libc 函数如 read、write,preadandpwrite` 提供通用 I/O 函数——EINTR 安全，并且（比 libc）更严格地检查不完整写入等情况。

注意：这适用于 nvmutil 的独立版本。曾尝试将其重写为一个更大的实用工具，在下面关于本版本已取消更改的章节中有所提及（参见下文关于 libreboot-utils 的说明）。

大约一千行死代码已从构建系统中清除，但由于新功能更改，又增加了数百行。总体而言，尽管本版本有所进展，lbmk 中的代码量已减少。

具体清理包括：

• config/ 下的项目更好地集中化，例如 config/module/coreboot/ 而不是 config/coreboot。目录 config/ifd/ 被移动到 config/data/coreboot/ifd/，因为它仅从 coreboot 使用。
• config/ 目录现在总体上组织得更好，每个项目的文件放置更加统一。
• 将所有供应商文件移入 vendorfiles/，例如 vendorfiles/mrc/，以整理主工作目录。
• 移除了 cbfstoolref 配置；现在它被硬编码，因为我们始终使用相同的 coreboot 4.11 树来构建该版本的 cbfstool（在 broadwell 主板上进行 refcode 提取）。
• 系统地移除了构建系统中未使用的变量。
• mk：新的 forx 函数允许类似宏的循环简写，大大简化了大部分代码。
• 移除了构建系统中的若干冗余检查，并总体上加强了所有错误处理。
• 各种随机和小型代码清理；构建系统中移除了少量死代码。
• 在 lbmk 中泛化了若干宏化的 mkhelper 检查，重构并降低了整体代码复杂度。
• lib.sh：将 build_sbase 函数改为宏，以便可以在一处更改。它实际上只是一条命令（make -C util/sbase）。
• 简化了 add_uboot 逻辑，因为现在仅 ARM64 需要它。x86 的条件逻辑已被移除，因为我们不再在 x86 上使用 U-Boot；EDK2 现在是 x86 上用于 UEFI 的首选 payload。
• 从依赖项中移除了 ccache，因为出于可靠性原因我们不再使用 ccache。
• inject.sh：移除了确认成功插入的结束消息，并总体上简化了所有变量初始化。
• release.sh：移除了 -m 选项，因为它无用。没有任何场景下我们想要在不构建二进制文件的情况下生成源代码归档。做半个发布有什么意义？这是死代码。旋钮是给傻瓜用的。
• vendorsh` 中的清理。
• 在 lbmk 中展开了若干循环，将它们泛化为类似宏的函数。这使得代码大小显著减少，同时提高了代码可读性。在 sh 中，如果做得对，类似宏的编程是相当可行的。
• 在构建系统的某些部分大量使用了 awk，以进一步展开几个循环，尤其是在 err 函数中。
• 移除了 mk 中 u-boot 专用的 make-clean 处理；反正 mk 现在更通用了。U-Boot 之前只对 lbmk Git 使用 git-clean，而不对发布版使用；那有什么意义？我们希望两者行为尽可能一致，而做不必要的工作，嗯，就是不必要。
• 大幅简化了 mk 中的 findpath 函数。现在只有一行代码，使用 forx。（readlink -f 和 realpath 的包装函数。
• 在 mk 中为 xbmkpwd 初始化添加了错误检查（更严格的检查）。
• 移除了 mk 中的 xprintf；我们现在只需将 & 符 printf 进 awk。简单。
• 简化了 mk 中的 xbmkpwd 初始化；我们现在找到 mk 的路径并 cd 到其基础目录，该目录因此成为 xbmkpwd。
• mk：从主脚本运行 xbmk_init，而不是 init.sh。这使得首次阅读时更清楚 xbmk 初始化是从哪里调用的。我们在包含 init.sh 的正下方执行。
• 将 tree.sh 移入 mk（合并器）。所有内容都集中在那里，自定义函数现在被垫片化。
• 所有包含现在批量完成，所有内容都从主脚本调用。我们之前有条件地包含 tree.sh（后来合并到 mk 中）。现在所有状态绝对是全局的，这使得进一步的代码简化和变量清理成为可能。
• 大幅简化了 get.sh。许多逻辑，尤其是子模块处理，被激进地通用化。

有几个改动被处理过，但没有进入此版本。它们涉及两个主要项目：

这是 nvmutil 的扩展，后来成为一套通用工具集，以及一个用于处理原子写入、针对各种 TOCTOU 攻击的用户空间缓解等事务的库。对 nvmutil 本身来说并非关键，但……

曾尝试实现一个名为 mkhtemp 的强化版 mktemp。它在用户空间实现了若干针对 TOCTOU 攻击的缓解措施，例如目录替换和符号链接攻击。

查看 lbmk git log 中的 util/libreboot-utils 以了解更多（可能是 util/libreboot_utils。

Mkhtemp 是在为 nvmutil 实现原子写入时开始的，但后来我自然地为此使用了 tmpfiles，这促使我审计了每一个 mktemp 实现。我得出结论：我可以做得更好——而且我做到了。

mkhtemp 创新之处的示例：

• 在被请求时仍提供类似 libc 的行为，但是：
• 对使用全局可写非粘滞目录进行更严格的检查。
• 总体上更严格的错误退出处理。
• 对操作/检查期间文件更改、inode 更改等进行不懈检查。检查文件未被另一个程序操作——基本上，尝试在用户空间实现类似 openat2 的安全性，不过 openat2 也在 Linux 上作为快速方法启用。
• 自己的 rand 实现，包装 Linux getrandom 和 BSD arc4random。它提供了多种 rand 函数，包括一个匹配 arc4random_buf 语义的函数（libreboot-utils 中的 rset 函数）。
• 总体上对文件和目录进行无描述符操作。
• 在可能的情况下进行无路径操作——包括用户空间目录遍历和沙箱化。
• 用户空间中类似 Unveil 的限制（以及在 OpenBSD 中使用 pledge/unveil）。
• 默认禁用符号链接的使用。

……它是一坨过度设计的垃圾，并且存在若干与栈内存使用相关的内存问题，在 BSD 上频繁出错。代码可以整理并完成，但我得出了一个结论：

发行版永远不会接受它。Mkhtemp 在 Linux 上运行良好，但它的操作要严格得多，会让大多数使用它的构建系统出错。我在 lbmk 中尝试用它替换 mkhtemp，在 PATH 中创建符号链接，但例如 GRUB 对 mktemp 几乎没有错误检查。大多数错误使用 mktemp 的程序都假设它永远不会失败，所以它确实不会失败；各种实现试图以极其复杂的方式缓解错误并继续运行。Mkhtemp 是对更严格的 TMPDIR 用法的一次干净尝试。

因为我觉得这是浪费时间，所以我认为我不在乎在这个更新日志中写更多关于它的内容。如果你感兴趣，请查看 lbmk 的 git 日志。

util/spkmodem-recv 的一个大幅扩展版本，实现了更强的噪声保护，尝试了自动音调检测和频率选择，以及更多功能。我有点做过头了，并认定这是一项过度工程化的努力。它不会在任何时候恢复。你可以在 lbmk 的 git 日志中找到它。（可能是 util/spkmodem_decode）。

无意义的努力。无论如何，spkmodem 协议在大多数设置中都无法使用。

有史以来最无意义的努力，例如：

• 边缘检测以及振幅检测，以便在噪声信号上更可靠地运行
• 定期根据信号重新校准时序，并针对音调进行调整。其想法是允许音调分隔符随时间漂移，并让我们的代码适应细微变化以减少噪声量。目前，spkmodem 在较差的信号上会显示大量噪声。
• 一堆其他同样无用的更改。

完全没有意义。更简单的代码运行得很好，因此该努力被放弃，所以 spkmodem-recv 仍然存在；这是几年前从 GNU GRUB 继承来的版本的清理版。

只有两个被取消的工作：

• 在 ARM64 Chromebook 上将 U-Boot 更新到 2026 年末的修订版，但启动流程菜单现在看起来很丑，而且几乎无法工作。上游完全破坏了它。因此，我们仍然使用 Libreboot 26.01（2026 年 1 月）版本中的 2025 年初 U-Boot 修订版。
• 通过在使用 EDK2 启动时解析 CBFS 中的 keymap.gkb 来支持 GRUB 键盘映射。这被取消是因为发布后将实现更好的方法；在 EDK2 中使用 HiiDatabase 和图形配置菜单来更改键盘布局和区域设置。这将被写入 SMMSTORE，并也被 payload 使用。例如，GRUB EFI payload 可以从 SMMSTORE 读取以了解区域设置，然后使用其现有的 gettext 集成相应地更改其语言（GRUB 已经支持国际化）。

隐藏的第三个取消，因为总有一个：

Linuxboot。现在有了 EFI 支持，如果需要，我们可以轻松地将任意数量的 UKI 添加到闪存中——而且我们会在未来的版本中这样做。术语 Linuxboot 指的是任何基于闪存的 Linux 发行版，它可以通过 Kexec 启动其他 Linux 内核——我更喜欢 ZFSBootMenu，或者至少是受它启发的某种东西，因为 ZFSBootMenu 的构建系统与 Libreboot 严格的设计原则完全不相容。

（这是一种礼貌的说法，表示我极度讨厌 podman/docker）

Linux UKI 现在很常见，用于启动，而 Libreboot EDK2 可以轻松集成它。

ARM64 payload 仍然存在，但 EDK2 已在 x86 上取代了 U-Boot。

这在本版本中值得单独一节，因为这是一个重大的设计变更。EDK2 不仅仅作为选项被添加；它已在 x86 上取代了 U-Boot。我可以为此单独写一篇文章。它值得一篇。它值得我的评判，公开地，正如我现在将毫不含糊地阐述的那样：

U-Boot 曾被用于在 Intel/AMD 主板上实现轻量级 UEFI，但主要负责 U-Boot 的 x86 coreboot payload 的人已基本将 U-Boot 分叉为一个新近 vibe-coded 的项目；根据新政策，Libreboot 强烈反对使用 AI。AI 不行，上游 x86 U-Boot 支持已基本荒废，尽管有几个有趣的补丁被合并。

因此 U-Boot 在 x86 上是个负担。EDK2 已经功能更完整，所以改用这个。以为 AI 能让你成为超级黑客？再想想：

• https://arxiv.org/abs/2507.09089

U-Boot 在 x86 上本来就一直有 bug。它真的完全没准备好。它更适合用在 RISCV 和 ARM64 上（我们继续在那里使用它）。

U-Boot 上游本身坚决反 AI，至少在本发布时如此，上述内容在他们的邮件列表上有很多讨论。在本发布页面上重新争论这一点不会有成效，但可以说 Libreboot 项目认为 U-Boot 在 x86 上实际上已死。基于 ARM 的开发在上游仍在强劲进行，我们将继续在 ARM64 上使用 U-Boot 实现 UEFI（例如 Chromebook）。

我不会说出他的名字，也不会说出他分叉项目的名字，因为我不想宣传他或他的 U-Boot 分叉。如果你知道他的名字或他的项目，你也不应该说或宣传它。AI 很坏，非常坏，原因见这里：

• https://blog.codeberg.org/protecting-our-floss-commons-from-llms.html

所讨论的 U-Boot 分叉大量由 AI vibe-coded，因此对 Libreboot 无用。这并非纯属猜测；在上述 U-Boot 邮件列表帖子中，作者如此表示。我们绝不会以任何方式鼓励或促进 AI 的使用。已经明确的是，Libreboot 使用的几个项目也有一些 AI 辅助的提交；GCC、GRUB 等。这不是我们的错，但我的意图是，我和其他人将来会审计这些项目，去除其中的 slop，甚至可能正因如此而完全分叉它们。该分叉的作者基本上为此发疯了，向上游 U-Boot 提议让他的工作成为“托管”，并慢慢合并到上游 U-Boot 树中。他基本上是在违背他们的意愿施压他们接受 AI 代码。我以 Libreboot 项目领导人的身份说，U-Boot 绝不应允许 AI 污染其项目。当你接受 AI 时，你会变得技能退化，并侵蚀你与用户之间存在的信任。你移除了维护者与用户之间的人际联系，你的项目将开始依赖于——是的——专有技术，以血为代价。AI 是地球上电力和水的最大消耗者之一，导致世界各地资源短缺，其对人们在新闻中看到的信息日益增强的控制甚至是对全球民主的威胁。这还没争论到许可不明确、版权侵犯等等。已决定 Libreboot 将加入反对一切人工智能的运动。主要负责 AI 训练和基础设施的国家是美国（由几家目前正在攻击全球民主的公司领导）和中华人民共和国；即使 AI 的所有其他问题都不存在，让这些国家对我们的计算拥有更多权力也是非常糟糕的主意。

不，Libreboot 对 AI 说不。因此，我们将继续使用上游 U-Boot，因为他们也说不，我们不会使用任何由 vibecoded 衍生的分支。即使这导致我不得不花费数周时间集成一个全新的系统来取代它。这正是、确切且毫无疑问地，我将为证明我的观点而走到多远。

这就是为什么我付出了如此巨大的努力来集成 EDK2。与其用另一个不完整的 UEFI 实现来取代 U-Boot，我只是添加了 EDK2，因为它已经功能完备，是 UEFI 规范的参考、行业标准实现。

CrabEFI 是我最初考虑用来取代 U-Boot 的。这是由 Arthur Heymans 编写的新 payload，项目本身非常出色，但 rustc/cargo 由于几个原因本质上不可靠：

• 工具链设置不可预测。大多数人使用例如 rustup，并设置各种自定义环境。比发行版提供的例如 LLVM/GCC 可预测性差得多。库等由 Cargo 提供，而不是发行版，用户常常让一切过时，导致损坏。
• Rust 没有标准化；规范是实现定义的，今天编写的代码在规范变化时可能仍能编译，但代码行为会因此自然改变。
• 鉴于上述情况，我们将不得不自己引导 rustc/cargo，而且必须从源代码进行（从像 GCC 这样已经通过 Guix 项目等提供源代码引导的编译器）。

Rust 很棒，但在我看来尚未达到生产就绪。再给它十年。EDK2 复杂得多，但代码大小不是问题，因为它通常稳定，并且用 C 编写（其中一小部分用 C++）。它拥有最多的关注，并定期接受安全审计。它是互联网上经过最多实战检验的代码库之一，并且运行良好。

CrabEFI 可能会在未来某个时候合并到 Libreboot 中，当 Rust 工具链在发行版（包括 BSD）中稳定下来时。它设计更好，即使尚未功能完备，使用 Rust 意味着它将有更少的内存错误。目前，Libreboot 使用 EDK2 取代 U-Boot，并且已在所有主板上默认启用。

关于内存安全，我们可以反过来说 EDK2 至少是稳定的；bug 也是稳定的。这就是重点。我们有稳定的 C/C++ 编译器，根据形式化标准进行了适当测试（并非真的，因为 GCC 和 LLVM 也会做各种古怪的事情，但它们也试图在行为上相互兼容）。你希望你的代码在编译后行为完全相同，包括 bug。这在用 C 和 C++ 编写的项目中得到更强的保证（尤其是纯 C 项目，而 EDK2 大部分实际上是纯 C）。

最初打算让 U-Boot 成为 Libreboot 在 x86 上的主要 payload，但唉。我咬紧牙关，选择了 EDK2。

对 AI 说不。AI 让你变蠢。AI 是我们不能拥有好东西的原因。

尚无法更改键盘布局——稍后可以在 EDK2 中添加图形菜单选项，保存到 SMMSTORE。GRUB 的 EFI 构建仅使用 terminal_input console，因此输入由 EDK2 输入驱动程序处理（USB 大容量存储和其他存储设备也是如此）；例如，GRUB 的 nativedisk 驱动程序已被移除，其原生 NVMe/xHCI 驱动程序不再像之前的 Libreboot 版本那样需要。

EDK2 输入驱动在 Libreboot 中可同时支持 USB 和 PS/2 键盘。GRUB 被改为使用 console 输入而非 at_keyboard，因为在 EFI 构建中它原本缺乏 USB 键盘支持。因此，键盘布局必须由 EDK2 处理。EDK2 中有相关代码，但目前 Libreboot 和 MrChromebox 都未处理，所以在此版本中全部默认为英国 QWERTY 布局。上游（MrChromebox）默认使用美国 QWERTY，但 Libreboot 是一个英国项目，因此 EDK2 被相应打了补丁。相关工作将在发布后进行。

不再提供按键映射图像。现在每个主板上的每个配置只有一个 ROM 镜像。这简化了构建，用户如果愿意，可以从 config/data/grub/keymap/ 向 CBFS 中插入一个 keymap.gkb 文件；如果你添加一个 grub.cfg 并设置 terminal_input 为 at_keyboard 来刷写，那么在具有 PS/2 键盘的设备上，如果想使用 GRUB EFI 载荷，这将有效（还需要在 grub.cfg 中添加一条加载键盘映射的命令，具体为 keymap (cbfsdisk)/keymap.gkb。

EDK2 已在所有 Intel 硬件上进行了广泛测试，从 GM45 例如 ThinkPad X200/T400，一直到 Libreboot 支持的 Intel Kabylake 硬件，例如 ThinkPad T480、X280、Dell Optiplex 3050/5050。

EDK2 中新的兼容性模块对大多数用户来说应该绰绰有余，他们可能仍希望使用 GRUB/SeaBIOS 来启动现有的 Linux 和 BSD 设置。建议将这些转换为 EFI 或直接重新安装——从现在起强烈鼓励默认使用 UEFI，但 Libreboot 必须（并将）继续支持较旧的设置。

使用 SeaBIOS 文本模式启动的 FreeBSD 用户可能会对此感兴趣，因为 BIOS 模式的 FreeBSD 引导加载程序无法与其他任何东西一起启动。不过，基于 UEFI 的 FreeBSD 安装在 EDK2 中可以正常工作，因此新的 FreeBSD 安装最好通过 EDK2 进行（不要使用 GRUB/SeaBIOS 的兼容性模块）。

一些用户可能想要它。这里有一些简要说明。它们不会被添加到主要文档中，因为它们涉及 Libreboot 现在视为过时的配置，但一些用户可能在短期内仍会发现它有用：

仅支持 32 位或闪存空间有限的较旧主板仍使用独立的 GRUB/SeaBIOS 载荷，而没有 EDK2；一些具有奇怪图形设置的新主板也仍使用单独的 SeaBIOS/GRUB，例如 HP EliteBook 8560w。

要重新启用独立 GRUB/SeaBIOS（不带 edk2）的使用，请针对你的主板修改 target.cfg 如下：移除 build_depend、payload_edk2 和 grubtree 变量。然后添加以下行：

payload_grub="y"
payload_seabios="y"
payload_memtest="y"

这在 Libreboot 中现已过时，甚至可能在未来的版本中被移除。EDK2 要好得多，因为它几乎能启动所有东西，并支持更多的硬件设置。它比上一个版本中 Libreboot 的旧设置要通用得多。

然后你就可以重新构建了。注意：在上述指导中，默认假设 build_depend 为 grub/default seabios/build memtest86plus/default。你可能想要显式设置它们：

build_depend="seabios/build grub/default memtest86plus/default"

你可能还希望显式设置 GRUB 树：

grubtree="default"

示例配置：config/module/coreboot/t480_vfsp_16mb/target.cfg

如果你想要这些旧设置回来，只需这样做并重新构建。这将在可行的情况下尽可能长时间地得到支持，但可能会在某个时候被移除，也许是几年后，也许是一周后。趁它还在的时候使用它。xHCI 补丁仍然在那里，一切都按应有的方式配置。

在使用 EDK2 的设置中，请注意：不提供 txtmode。如果想要例如 SeaBIOS txtmode，请查看例如：

• config/module/coreboot/t480_vfsp_16mb/config/libgfxinit_corebootfb

在此示例中将其重命名为 libgfxinit_txtmode 并执行：

./mk -m coreboot t480_vfsp_16mb
./mk -s coreboot t480_vfsp_16mb

在出现的菜单中，进入 Devices -> Display -> Framebuffer mode 并选择 Legacy VGA text mode - 不建议在任何新设置中使用此选项，但 FreeBSD 引导加载程序以文本模式启动，而 coreboot 中的帧缓冲模式无法切换回文本模式。当引导 FreeBSD BIOS 模式引导加载程序时，建议以文本模式启动，然后可以在 Xorg/Wayland 中为 FreeBSD 设置 KMS。否则，新安装应直接通过 EDK2 以 EFI 模式进行（无兼容性模块）。有关此内容的更多信息，请参阅 Libreboot 的 BSD 文档。

• Google Anahera
• Google Aurash
• Google Banshee
• Google Bujia
• Google Caboc
• Google Constitution
• Google Crota
• Google Dochi
• Google Felwinter
• Google Gaelin
• Google Gimble
• Google Gladios
• Google Jubilant
• Google Kano
• Google Kinox
• Google Kuldax
• Google Lisbon
• Google Lotso
• Google Marasov
• Google Mithrax
• Google Moli
• Google Moxie
• Google Anraggar
• Google Craaskov
• Google Craask
• Google Dirks
• Google Domika
• Google Epic
• Google Glassway
• Google Gothrax
• Google Guren
• Google Joxer
• Google Kaladin
• Google Meliks
• Google Nereid
• Google Nivviks
• Google Nova
• Google Pujjocento
• Google Pujjogatwin
• Google Pujjoga
• Google Pujjolo
• Google Pujjoniru
• Google Pujjo
• Google Quandiso2
• Google Quandiso
• Google Riven
• Google Rull
• Google Sundance
• Google Teliks
• Google Telith
• Google Tereid
• Google Tivviks
• Google Uldrenite
• Google Uldren
• Google Xivu
• Google Yaviks
• Google Yavilla
• Google Omnigul
• Google Osiris
• Google Primus
• Google Redrix4ES
• Google Redrix
• Google Taeko
• Google Taniks
• Google Vell
• Google Volmar
• Google Xol
• Google Coral
• Google Pyro
• Google Reef
• Google Sand
• Google Snappy
• Google Auron_Paine
• Google Auron_Yuna
• Google Buddy
• Google Gandof
• Google Guado
• Purism Librem 13 v1
• Purism Librem 15 v2
• Google Lulu
• Google Rikku
• Google Samus
• Google Tidus
• Google Banon
• Google Celes
• Google Cyan
• Google Edgar
• Google Kefka
• Google Reks
• Google Relm
• Google Setzer
• Google Terra
• Google Ultima
• Google Wizpig
• Google Banjo
• Google Candy
• Google Clapper
• Google Enguarde
• Google Expresso
• Google Glimmer
• Google Gnawty
• Google Heli
• Google Kip
• Google Ninja
• Google Orco
• Google Quawks
• Google Squawks
• Google Sumo
• Google Swanky
• Google Winky
• Google Akemi
• Google Ambassador
• Google Dooly
• Google Drallion
• Google Dratini
• Google Duffy
• Google Faffy
• Google Genesis
• Google Helios
• Google Jinlon
• Google Kaisa
• Google Kindred
• Google Kohaku
• Purism Librem 14
• Purism Librem Mini v2
• Google Moonbuggy
• Google Nightfury
• Google Noibat
• Google Scout
• Google Wyvern
• Google Dewatt
• Google Nipperkin
• Google Ampton
• Google Bloog
• Google Bobba
• Google Casta
• Google Dood
• Google Fleex
• Google Foob
• Google Garg
• Google Lick
• Google Meep
• Google Phaser
• Google Falco
• Google Leon
• Google Mccloud
• Google Monroe
• Google Panther
• Google Peppy
• Google Tricky
• Google Wolf
• Google Zako
• Google Awasuki
• Google Beadrix
• Google Blipper
• Google Boten
• Google Boxy
• Google Bugzzy
• Google Cret
• Google Dexi
• Google Dibbi
• Google Dita
• Google Drawcia
• Google Galtic
• Google Kracko
• Google Lantis
• Google Madoo
• Google Magolor
• Google Metaknight
• Google Pirika
• Google Sasukette
• Google Sasuke
• Google Storo
• Google Taranza
• Google Atlas
• Google Endeavour
• Google Eve
• Google Fizz
• Google Karma
• Purism Librem 13 v4
• Purism Librem 15 v4
• Google Nami
• Google Nautilus
• Google Nocturne
• Google Rammus
• Google Soraka
• Google Crystaldrift
• Google Frostflow
• Google Markarth
• Google Skyrim
• Google Winterhold
• Google Kanix
• Google Karis
• Google Screebo
• Google Berknip
• Google Dirinboz
• Google Ezkinil
• Google Gumboz
• Google Morphius
• Google Shuboz
• Google Vilboz
• Google Woomax
• Google Asuka
• Google Caroline
• Google Cave
• Google Chell
• Google Lars
• Purism Librem 13 v2
• Purism Librem 15 v3
• Google Sentry
• Google Butterfly
• Google Link
• SAMSUNG Lumpy
• Google Parrot
• Google Stout
• SAMSUNG Stumpy
• Google Aleena
• Google Careena
• Google Liara
• Google Treeya
• Google Chronicler
• Google Collis
• Google Copano
• Google Delbin
• Google Drobit
• Google Eldrid
• Google Elemi
• Google Lindar
• Google Voema
• Google Volet
• Google Voxel
• Purism Librem Mini
• Google Sarien

CSMWrap is the SeaBIOS CSM build provided inside EDK2. It hogs an entire CPU core at boot, so e.g. quad-core will show up as three-core inside Linux. It’s a known limitation that will be corrected in a future release, due to the design of CSMWrap. If you need backward compatibility, it’s better to use the GRUB EFI build instead which does not have this problem. Both GRUB EFI and SeaBIOS CSM are available in the EDK2 menu via ESC keypress at boot time.

Users are best served just switching to native UEFI boot with ESP, using Libreboot’s EDK2 payload.

Markdown file for this page: https://libreboot.org/news/libreboot2610.md

Site map

This HTML page was generated by the Libreboot Static Site Generator.