跳到正文
原文
Hacker News· iamnothere·· 3 小时前精选AI 评分31

Libreboot 26.10 "Ominous Olive" 发布，将 EDK2 设为默认 UEFI payload 并支持 233 款 Chromebook

Libreboot 26.10 "Ominous Olive" released with UEFI, Chromebook support

AI 导读

Libreboot 26.10 "Ominous Olive" 发布，将 EDK2 设为默认 payload 以提供完整 UEFI 兼容，可启动 Windows 10/11、Linux、BSD 等系统；导入 MrChromebox 全部 233 款 Chromebook 支持，并新增 Dell OptiPlex 5050 SFF、ThinkPad X280/X270 等机型。

推荐理由

文章以官方视角记录了 Libreboot 抛弃 x86 U-Boot、改用 EDK2 的完整理由与技术改造细节，可为同类开源固件项目的现代化路径提供对照参考。

正文 · AI 翻译

译文尚不完整，完整内容请切换到原文。

返回索引

文章发布者：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 有效载荷增加了对完整 UEFI 的支持。与专有固件相比，Libreboot 提供了更高的安全性和可定制性；其目标很明确，就是要消除世界上的专有软件，为此我们努力提供对非技术用户而言也极其易于理解的固件。

今日发布版本的变更日志是相对于上一个 Libreboot 26.01 版本而言的。

这是一次非常特别的发布版本，在不考虑硬件变更的情况下进行了若干重大设计变更，因此用户应当非常仔细地阅读此变更日志——并阅读两遍。

首先，第一件事。（是的，您没有读错上一段）

一个强烈反 AI 的策略已添加到一个新文件：lbmk 中的 AGENTS.md。这是本版本中最重要的更改。接下来是所有其他内容：

警告：本次发布版本中进行了重大设计变更，可能会影响许多现有配置。我们现在使用 EDK2 作为默认有效载荷，同时将 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 有效载荷；我们将背景色设置为 Libreboot 紫色，并使用 Libreboot 彩虹标志替代 coreboot 标志。除下文所述的更改外，我们的 EDK2 构建目前在其他方面完全相同：
  • 在构建时默认设置 HAP 位以禁用 Intel ME。在 MrChromebox coreboot 中默认情况下并不能可靠地将其禁用，因为大多数人通过软件刷写脚本配合 MrChromebox 文档中所示的方式禁用 Google 的安全机制来使用它。我们在此将其禁用。注意：我们还支持众多 AMD Chromebook，在此上下文中与此无关。
  • 通过 ifdtool 解锁 IFD 区域（妥善处理特殊情况），在构建时将其设置为可读写。这样做是为了避免修改 MrChromebox 提供的每一个 Intel Flash Descriptor，其中共有数百个。
  • 在 EDK2 中加入了 CSMWrap（将 SeaBIOS CSM 包装在 EFI 中），以保持与裸机 SeaBIOS 的向后兼容，就像早期 Libreboot 版本中的那样。
  • 同样为了向后兼容，在 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 需要设置 framebuffer，而集成的 AST2050 芯片在原生初始化时仅以文本模式启动；厂商 VGA ROM 可以设置 VESA，但我们不会使用 VGA ROM。这些主板上的基于 EDK2 的镜像仅提供源码，供搭配显卡使用。

基本上，这些主板首次真正可用了。

EDK2 是 Intel 对 UEFI 规范的开机参考实现。它通常被供应商在 Intel BSD 许可代码的专有分支中使用，但 Intel 的参考代码是自由软件。我们使用他们的参考代码，完整源代码已包含在本次 Libreboot 发布中。EDK 的全称是：EFI 开发套件。

更具体地说：

我们使用 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（在 Libreboot 中，较老的 SeaBIOS txtmode 只能使用 MBR 分区）
  • UEFI 模式下的 FreeBSD - 不再需要 txtmode！
  • 遗憾的是 ReactOS 无法工作（不支持 UEFI）
  • RedoxOS 可能也能工作。

现代计算机和操作系统都采用 UEFI，而这一新配置基本可以可靠地启动所有这些设备和系统。虽然还需要更多测试，但这是经过实战检验的代码，多年来已被许多用户广泛用于 coreboot。Libreboot 终于也拥有了它。

仅这一项变化就是使 Libreboot 现代化这一更大努力的一部分，而我的工作才刚刚开始。后续的 Libreboot 版本将大量依赖于此，因为在如今许多现代 coreboot 配置中，EDK2 基本上是预期的有效负载。集成 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（默认树）：更新到提交 ID 8ce4c91c41da3f042979f92095149a85bc93227d，截至 2026 年 9 月 18 日。
  • Coreboot（mrchromebox）：导入了 MrChromebox coreboot 的提交 ID e5997cf9384b29082a1bf3101813d8ac3dadda42，用于 Chromebook。
  • Coreboot（fam15h）：已移除（4.11_branch 树）并替换为：
  • Coreboot（fam15h_15h）：提交 ID 57e26bdcd959808c0171164f3c6197d4a347c3b2，截至 2026 年 5 月 27 日。这是 coreboot 版本 4.11_branch 的一个重大改进分支，用于提高 AMD FAM15H 硬件（例如 ASUS KGPE-D16）上的初始化可靠性。
  • SeaBIOS（非 CSM）：更新到提交 ID 81ec9ec0bcf45df11fb7f98339ec9036b546fca0，截至 2026 年 7 月 28 日。

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 payload 设置保持一致。EFI payload 的工作方式基本相同。

使用 EDK2 使得支持更新的机器更加容易，这将是今后的重点。EDK2 首先出现，作为整体现代化工作的一部分；更新的 Intel 和 AMD 硬件将逐步添加，默认独占使用 EDK2 payload。

这是一个特性版本。特性变更非常多！

  • 所有至少有 4MB flash 的 Intel/AMD 主板均支持 EDK2 payload。这使用 MrChromebox 版本的 EDK2，Libreboot 进行了大量修改，例如：向其中添加 GRUB EFI 和 SeaBIOS CSM (CSMwrap) 构建；这些作为向后兼容旧版独立 SeaBIOS/GRUB payload 设置而提供，应该仍能启动现有的 Linux/BSD 安装。
  • 通过 EDK2 payload（ESC 菜单）添加了 iPXE 启动方式 - 仅限 EDK2（旧主板上的独立 SeaBIOS payload 中不可用）。
  • 添加了新命令 ./mk import_uboot 用于自动导入 U-Boot 配置，然后可在 lbmk 中构建。尚未使用，但这将用于在未来的版本中添加经过测试的 U-Boot 主板（U-Boot 本身提供自己的初始化）。Libreboot 已经可以从任何配置构建 U-Boot 镜像，无需代码更改，只需配置更改，但需要在硬件上进行测试。
  • 在 util/mrimport 的新工具用于自动从 MrChromebox coreboot 导入/更新新配置。这还用于从 MrChromebox 初步导入 233 台 chromebook，将它们导入 Libreboot 构建系统，并应用我们自己的修改。
  • 在 EFI 版本的 GRUB 菜单项中添加了 fwsetup 命令，可重新启动进入 edk2 设置菜单。
  • 修改了 Kabylake 主板上的 IFD，以支持 pin mod。这使得可以使用六核和八核 Intel CPU。
  • 在构建时随机化 MAC 地址，仅当 XBMK_RELEASE 未设置时。您可以通过环境变量 XBMK_MAC 导出 MAC 地址以任意设置。这样就避免了在直接处理 .rom 文件而非 release tarball 时需要在构建后提取 NVM 并重新插入，release tarball 已经通过 ./mk inject 具备此能力。
  • GRUB at_keyboard 驱动：始终通过转换强制使用 scancode set 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 上用于构建 utils。
  • 在整个构建系统中移除了 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 已作出相应修改以适配它们。inject 脚本仍会在运行时自动解析完整配置，这是构建时扫描路径所需要的。使用 defconfig 可降低更新过程中配置发生错误更改的几率，并可采用更可靠的 olddefconfig，取代可靠性较低的 oldconfig 命令。
  • 新的安全检查：在逻辑中使用路径前缀时，验证路径前缀是否已设置。否则，我们可能会在 lbmk 中出现目录转义漏洞。检查在整个构建系统中反复进行。
  • 不再导出 XBMK_CACHE，因为它现在已在配置中硬编码。新的处理方式更加严格，未来版本中不太可能发生回归。这样做是为了降低 lbmk 中出现目录转义漏洞的可能性。
  • 修复了不再按 GRUB 树使用的 GRUB 模块列表。现在，所有模块按目标添加，但应用了按树配置的黑名单。
  • GRUB Syslinux 和 GRUB 扫描现在在 GRUB 配置中合并为一个函数。对 GRUB 配置进行了总体简化。
  • GRUB 现在是一个源树，多个目标全部重用同一棵树，在其中使用不同的配置。
  • 修改了 MrChromebox coreboot，使其仅在 coreboot 默认配置中未选择视频模式时才添加 EDK2 GOP 二进制文件。这避免了不必要的添加，从而在使用 FSP init 或 libgfxinit 时节省闪存空间。
  • 在 include/env/get.sh 上始终使用 --mirror git 克隆。这使得在所有项目上克隆修订版本更加可靠，尤其是在 main 之外的分支中使用修订版本的项目。
  • 在所有基于 Intel IFD 的系统上，在构建时自动解锁 IFD 区域；通过设置 HAP 位自动禁用 ME。这是我们在 chromebook 上所做的方式，但在所有主板上都会执行；这降低了未来可能意外忘记在特定目标上中和 ME 的风险。
  • 在构建 EDK2 时，我们使用 coreboot 的构建系统，但采用这种方式时，图像文件名中不使用 custom_ 前缀。使用的是正确的 edk2 前缀。这使其可以在 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 负载版 SeaBIOS 和 GRUB 的主板上，我们现在只生成以 GRUB 或 SeaBIOS 作为主负载的镜像。SeaBIOS 的负载加载并不总是可靠的，而 GRUB 在几年前已大幅改进了其分配器。我们现在在大多数主板上使用 EDK2，因此对仅使用 GRUB 的少数主板进行测试要可行得多。鉴于独立的 SeaBIOS/GRUB 现已过时，这一简化是永久性的；EDK2 是当前的首选负载，并提供了 EFI 版本的 SeaBIOS 和 GRUB，插入到 EDK 菜单中，以向后兼容旧版 Libreboot 设置。
  • 在构建前对项目更强烈地使用 make distclean，这得益于 Libreboot 基于 lbmk 中元数据检查对项目构建进行的积极的树外缓存。
  • 允许在项目上使用 noconfig=n，这使得项目可以多树构建，并在不同目标上使用相同的树，即使不需要构建配置；在某些情况下，配置完全在 mkhelper 设置中完成。这是 Libreboot 决定将所有项目都设为多树的一部分，同时还允许每个项目使用 N 个上游，而不仅仅是一个上游。
  • 简化 lbmk 中 release=n 的处理；不执行 mkhelpers。如果 release=n，则跳过源码获取，因此不会下载相应的源码。这是排除 MrChromebox 源码以及发布版中构建所必需的，因为它们尚未准备好在 Libreboot 中作为稳定版发布。
  • init.sh：使用可移植的 date；现在使用 git 自身的日期处理。在发布版构建的 git 仓库初始化中，我们不再依赖 date 命令的 GNU 特定扩展。
  • 允许从主工作目录外部运行 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。
  • 在厂商注入脚本中不使用 dell.com 作为主下载镜像。这减少了在使用 deguard 注入镜像时出现的下载错误数量。
  • 扫描所有设备上的所有 GRUB 配置，而不在 GRUB 中使用固定的设备列表。而是使用通配符。更多的 BTRFS 子卷也会被检查，同样通过使用通配符。
  • 对 GRUB 配置进行了一般性清理。移除了冗余功能，例如 对 gfxterm 的操作。默认设置即可正常工作。无论如何，GRUB 在串行输出上从未可靠地工作过，而且大多数现代计算机不支持 GRUB 在此上下文中支持的任何接口。
  • 已将 ImageMagick 添加到依赖项中（EDK2 启动徽标所需）。
  • SMMSTORE 默认启用，在所有将 EDK2 作为 payload 的目标上。这意味着 Libreboot 用户现在可以在启动时进入标准的设置菜单，以持久的方式配置他们的机器（例如 启动顺序），且无需重新构建固件。
  • 为 KCMA-D8 和 KGPE-D16 主板添加了 4MB 和 8MB 目标。结合在这些主板上使用 coreboot 的 15h.org 分支，可改进 raminit 并修复各种 bug。它使用 AMD AGESA 源代码，而不是 Raptor Engineering 编写的自定义源代码。修改后的 AGESA 代码具有更好的 CPU 和内存初始化功能，支持更多的硬件组合，并支持更大容量的 RAM。
  • 合并了 Alguien 的补丁，修复了 IFD 区域（设置为可读写）并在 ThinkPad X280 上清空了 OEM 部分。同时禁用了超线程。
  • 预防性构建修复：在所有可行项目中移除了 -Werror 的使用。
  • 修复了 ThinkPad X230 目标上的挂起 bug，该 bug 是由一项优化引起的——此修复现已将其回退——该优化优化了 coreboot 中的 CAR 设置。此修复反转了 coreboot 版本 97dbfd3098ae12ef3f51e5f95cd6d66c25214205。此回退由 HustlerOne 在其新的 Snowboot 项目中完成，并从 Snowboot 复制到了 Libreboot 项目中。
  • 在多个项目中添加了伪 menuconfig Make 选项，以便相关的 mk 选项不会导致构建错误（现在会发生无害的空操作）。
  • mk：仅在 defconfig 实际存在时，才在运行 config 命令时将其复制回来。这修复了 ./mk -s seabios 从不保存 defconfig 文件的问题。
  • 向我们 2025 年初版本的 U-Boot 回移了多个构建修复，以便它能在现代发行版上构建，例如 最新的 Arch Linux 更新。（这是必需的，以便 GRU Kevin/Bob chromebook 能够继续构建）。
  • 移除了 src/gpio-scripts，原因是其使用版本的许可证不明确。（对其更改未给出许可证，从 coreboot 分叉为独立版本时回退到 coreboot 的 COPYING 文件，但分叉仓库中完全没有许可证——因此所做的更改也不清楚）。
  • 修复了从 MrChromebox 导入的 Intel/AMD chromebook 主板上的多个损坏的 vendor 文件路径。这些修复也已提交并合并到上游的 MrChromebox 项目中。
  • vendor.sh：捕获 coreboot defconfig 中的所有 make 变量，运行 make-olddefconfig 并将它们全部解析为正确的值（在涉及路径时）。它们以对 sh 友好的方式进行转换，处理过程中避免意外运行错误的子 shell。
  • 更安全地处理 defconfig；更严格的错误检查，包括 noconfig 项目。
  • 修复了 mk 中缺少的无限循环检测，当在项目中解析 trees/revisions 时。现在可以检测到无限引用其他 trees 的 trees。
  • 修复了 GCC 16 上的 pico-serprog 构建错误（在最新的 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 通过分叉包含这些文件的仓库并保持其静态，修复了这一可复现性问题。下次我做演讲时，我的演示不会再失败了。我在演讲结束几小时后立即修复了这个问题。

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

  • 更安全地使用宏（使用括号）。
  • 移除了基于 errno 的错误处理。只需根据逻辑错误返回零或一，但不要依赖 errno 的状态进行错误退出。仅在 libc 函数中按 POSIX 要求适当使用返回值。不过，在从 libc 函数返回后，相应地以更可靠的方式处理 errno 重置；这并非 POSIX 所要求，但也不被反对。dell-flash-unlock 的 errno 处理也以同样方式修复。我们以前严重依赖 errno 进行退出，这种方式不可移植。并非所有 libc 都会正确重置它，甚至可能在某个函数逻辑上成功返回时随机设置它。任何东西都可能设置它，因此它不是一种用于通用错误处理的可靠机制。
  • 不要使用 -pedantic 标志 —— 同时在 spkmodem-recv 上移除该标志。这可以减少因警告而产生的过分严格构建错误的几率。
  • 常规正确性修复；边界检查、对齐字的正确处理、转换指针时使用 uintptr 等。由于大量审查，代码在内存管理方面总体上更加安全。
  • 各种函数的 EINTR 安全包装；在出现错误的位置循环直到 EINTR 清除，否则对非 EINTR 错误直接退出。如果函数返回错误，则在 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；在 x86 上 EDK2 现在是用于 UEFI 的首选有效载荷。
  • 由于可靠性原因，已从依赖项中移除 ccache，因为我们不再使用 ccache。
  • inject.sh：移除了确认插入成功的结束消息，并总体简化了所有变量初始化。
  • release.sh：移除了 -m 选项，因为它毫无用处。在任何场景下我们都不希望在不构建二进制文件的情况下生成源归档。做半个版本有什么意义？这是死代码。花里胡哨的开关只是给傻瓜用的。
  • vendorsh` 中的清理。
  • 在 lbmk 中展开了若干循环，将其泛化为类似宏的函数。这使得代码量得到适度缩减，同时提高了代码可读性。如果操作得当，类似宏的编程在 sh 中是相当可行的。
  • 在构建系统的某些部分大量使用了 awk，以进一步展开几个循环，尤其是在 err 函数中。
  • 移除了 mk 中 u-boot 特定的 make-clean 处理；mk 现在也已经更加通用。U-Boot 一直在使用 git-clean，但仅对 lbmk Git 使用，不对发布版使用；那么这有什么意义呢？我们希望两者上的行为尽可能保持一致，做不必要的工作，嗯，是不必要的。
  • 大幅简化了 mk 中的 findpath 函数。现在只需一行代码，使用 forx。（readlink -f 和 realpath 的包装函数。
  • 在 mk 的 xbmkpwd 初始化中添加了错误检查（更严格的检查）。
  • 移除了 mk 中的 xprintf；我们现在只需将 & printf 到 awk 中。很简单。
  • 简化了 mk 中 xbmkpwd 的初始化；我们现在找到 mk 的路径并 cd 到其基础目录，该目录随即成为 xbmkpwd。
  • mk：从主脚本而非 init.sh 运行 xbmk_init。这样在初次阅读时更清晰，可以知道 xbmk 初始化是从哪里调用的。我们在 include init.sh 的紧下方执行它。
  • 将 tree.sh 移入 mk（merger）。一切都在那里集中处理，自定义函数现在通过垫片（shim）方式实现。
  • 现在所有 include 都是批量完成的，所有调用都来自主脚本。之前我们是有条件地 include 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 的行为，但是：
  • 对使用全局可写但非 sticky 位目录的情况进行更严格的检查。
  • 通常更严格的错误退出处理。
  • 在操作/检查过程中对文件变更、inode 变更等无情地进行检查。检查文件未被其他程序操作——基本上是尝试在用户态实现类似 openat2 的安全性，尽管 openat2 在 Linux 上也已作为一种快速方法被启用。
  • 自有 rand 实现，封装了 Linux getrandom 与 BSD arc4random。它为 rand 提供了多种函数，包括一个语义与 arc4random_buf 相匹配的函数（libreboot-utils 中的 rset 函数）。
  • 通常情况下，对文件和目录采用无描述符（descriptorless）操作。
  • 在可能的情况下采用无路径（pathless）操作——包括用户态目录遍历与沙箱化。
  • 在用户态采用类似 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 键映射。这被取消了，因为发布后将实现更好的方法；即使用 HiiDatabase 和 EDK2 中的图形配置菜单来更改键盘布局和区域设置。这将被写入 SMMSTORE 并被各有效载荷使用。例如，GRUB EFI 有效载荷可以从 SMMSTORE 读取以获知区域设置，然后使用其现有的 gettext 集成相应地切换语言（GRUB 已经支持国际化）。

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

Linuxboot。现在有了 EFI 支持，如果需要，我们可以轻松使用任意数量的添加到闪存中的 UKI —— 我们也将在未来的发布中这么做。Linuxboot 这个术语指的是任何基于闪存的 Linux 发行版，它可以通过 Kexec 引导其他 Linux 内核 —— 我个人偏好 ZFSBootMenu，或者至少是受它启发的东西，因为 ZFSBootMenu 的构建系统与 Libreboot 严格的设计原则完全不相容。

（这是一种礼貌的说法，意思是：我对 podman/docker 深恶痛绝）

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

ARM64 有效载荷仍然存在，但在 x86 上 EDK2 已取代 U-Boot。

这值得在本次发布中拥有自己的章节，因为这是一项重大设计变更。EDK2 不仅仅是作为一个选项添加的；它已在 x86 上 取代了 U-Boot。我可以把它写成单独的文章。它值得拥有一篇。它值得我公开表达我的判断，我现在将毫不含糊地阐明：

U-Boot 曾用于 Intel/AMD 主板上的轻量级 UEFI 实现，但主要负责 x86 coreboot payload 的那位人士已将 U-Boot 大部分分叉为一个全新的 vibe-coded 项目；按照新政策，Libreboot 强烈反对使用 AI。AI 没有好处，尽管合并了一些有趣的补丁，上游 x86 U-Boot 的支持已经大体上无人维护（bitrot）。

因此 U-Boot 在 x86 上是一个累赘。EDK2 已经更为完整，所以改用它。觉得 AI 能让你成为超级黑客？再想想：

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

U-Boot 上游本身——至少在本次发布时——是坚决反 AI 的，并且上述内容的大量讨论发生在他们的邮件列表上。在本发布页面上重新争论这一点并无裨益，但只需说明，Libreboot 项目认为 U-Boot 在 x86 上实际上已经死亡。基于 ARM 的开发在上游仍然强劲进行，我们将继续在 ARM64（例如 chromebook）上使用 U-Boot 提供 UEFI。

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

这里所说的 U-Boot 分叉，大量使用了 AI vibe-coding，因此对 Libreboot 毫无用处。这不是凭空猜测；在前面提到的 U-Boot 邮件列表讨论串中，作者本人亲自如此表态。我们绝不会以任何方式鼓励或便利 AI 的使用。已经明确的是，Libreboot 使用的若干项目也有一些 AI 协助的提交；如 GCC、GRUB 等。这不是我们的错，但我的意图是我和其他人将来会审计这些项目，给它们清除 AI 痕迹（de-slopping），甚至可能完全为此而分叉这些项目。该分叉的作者基本上已经为此走火入魔，他向 U-Boot 上游提议他的工作应当担任“custodian（管理者/监护人）”，并缓慢地合入上游 U-Boot 代码树。他基本上是在违背他们意愿地强迫他们接受 AI 代码。我以 Libreboot 项目负责人的身份说，U-Boot 永远不应该允许 AI 污染其项目。当你接受 AI 时，你会变得去技能化，并侵蚀你与用户之间存在的信任。你消除了维护者与用户之间的人际联系，而你的项目将开始依赖于——没错——专有技术，且是用鲜血换来的。AI 是全球电力和水的最大单一消费者之一，导致世界各地的资源短缺，并且它对人们从新闻中看到的信息日益增强的控制甚至是对全球民主的威胁。这甚至还没有讨论许可不明确、版权侵权等问题。经决定，Libreboot 将加入反对一切人工智能的圣战。AI 训练和基础设施的主要负责国家是美国（由数家目前正在攻击全球民主的公司领导）和中华人民共和国；即使 AI 的所有其他问题都不存在，让这些国家对我们的计算拥有更大的权力也是一个非常糟糕的主意。

不。Libreboot 对人工智能说不。因此，我们将继续使用上游的 U-Boot，因为它们也说不，并且我们不会使用任何由 AI 编写的分支版本。即使这意味着我必须花费数周时间来集成一个全新的系统来替换它。这正是、完完全全、毫无疑问地证明我会走多远来证明我的观点。

这就是为什么我不遗余力地集成 EDK2。我没有用另一个不完整的 UEFI 实现来替换 U-Boot，而是直接添加了 EDK2，因为它本身已经功能齐全，因为它本身就是 UEFI 规范的参考性、行业标准实现。

CrabEFI 起初是我考虑用来替代 U-Boot 的方案。它是由 Arthur Heymans 编写的新的有效载荷，项目本身非常出色，但由于以下几个原因，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 至少是稳定的；错误也是稳定的。这正是重点。我们拥有稳定的 C/C++ 编译器，根据形式化标准进行了正确的测试（实际上并非完全如此，因为 GCC 和 LLVM 也会做出各种古怪的事情，但它们也试图在行为上彼此兼容）。您希望您的代码在编译时，包括错误在内，表现得完全一样。这在使用 C 和 C++ 编写的项目中得到了更有力的保证（尤其是纯 C 项目，而 EDK2 的大部分实际上都是纯 C 编写的）。

最初的计划是让 U-Boot 成为 Libreboot 在 x86 上的主要有效载荷，但唉。我不得不忍受 Intel 的风格，最终选择了 EDK2。

对人工智能说不。人工智能会让人变蠢。人工智能就是我们无法拥有美好事物的原因。

目前还无法更改键盘布局 - 稍后可以在 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 都未处理，因此本版本默认全部使用 UK QWERTY。上游（MrChromebox）默认使用 US QWERTY，但 Libreboot 是英国项目，因此对 EDK2 做了相应补丁。相关工作将在发布后进行。

已不再提供键映射镜像。现在每块主板的每个配置只有一个 ROM 镜像。这简化了构建过程，如有需要，用户可以从 config/data/grub/keymap/ 向 CBFS 内插入 keymap.gkb 文件；如果将 grub.cfg 添加到刷写中并将 terminal_input 设置为 at_keyboard，则在使用 GRUB EFI payload 且设备配备 PS/2 键盘的情况下即可生效（grub.cfg 中还需要加载键映射的命令，具体为 keymap (cbfsdisk)/keymap.gkb）。

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

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

使用 SeaBIOS 文本模式启动的 FreeBSD 用户可能会对此感兴趣，因为 BIOS 模式的 FreeBSD 引导程序无法通过其他方式启动。不过，基于 UEFI 的 FreeBSD 安装在 EDK2 下可以正常工作，因此新的 FreeBSD 安装建议通过 EDK2 完成（不要使用 GRUB/SeaBIOS 的兼容性模块）。

部分用户可能仍希望使用它。以下是一些简要说明。由于涉及 Libreboot 现已视为过时的配置，因此不会添加到主文档中，但部分用户在短期内可能仍会发现它有用：

仅支持 32 位或闪存空间有限的老主板仍使用不带 EDK2 的独立 GRUB/SeaBIOS payloads；一些显卡配置较特殊的新主板也仍单独使用 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.

来源：Hacker News · libreboot.org

#大佬观点#开源生态