Question

我对于使用LinuxBoot作为Coreboot的有效负载感到困惑。

我了解到LinuxBoot可以完全替代UEFI的DXE和BDS阶段，然后可以直接加载引导程序（例如GRUB），甚至直接加载Linux内核。

现在，我还读到LinuxBoot可用作Coreboot的有效负载。

如果LinuxBoot可以完成从平台初始化到加载内核的所有操作，那么为什么还要有人将Coreboot放在序列中呢？简而言之，为什么存在使用LinuxBoot作为Coreboot的有效负载的用例？ Coreboot将扮演什么角色？

Answer 1

UEFI包含多个阶段：SEC，PEI和DXE。 LinuxBoot替换了DXE阶段，Coreboot替换了SEC和PEI阶段。

Coreboot负责Linux无法完成的平台初始化，例如DRAM初始化（也称为“训练”）和ACPI表生成。然后，Linux充当Coreboot负载，完成诸如PCI设备枚举之类的工作，并加载引导程序或可以kexec()进入另一个Linux内核。

Answer 2

Linuxboot不能执行平台初始化，而coreboot可以。正如LinuxBoot: Linux as firmware文章（重点是我的）中所述：

就像LinuxBoot的initramfs依赖于LinuxBoot内核来启动一样，LinuxBoot内核也依赖于引导过程中的上一步。这可能涉及coreboot。 LinuxBoot和coreboot不是竞争者，而是它们解决引导的不同阶段。请记住， UEFI引导过程包括四个阶段，其中第三阶段（驱动程序执行环境或DXE）是LinuxBoot启动的起点。 Coreboot是前两个阶段的实现，其中可以替换主板供应商提供的UEFI固件。 Coreboot仅支持较小范围的硬件，但是，当与LinuxBoot配合使用时，它可以实现几乎完全开放的启动过程。

并且如LinuxBoot homepage上的该图所示，LinuxBoot在硬件初始化之后出现，它也可以是UEFI的有效负载： Boot flow LinuxBoot的FAQ也指出：

LinuxBoot与UEFI和coreboot兼容。您可以将LinuxBoot用作UEFI DXE或coreboot负载。

关于您对Eloy答案的评论，我想coreboot的文档中没有提及SEC和PEI，因为它们是UEFI概念，而coreboot从来没有遵循UEFI规范。如Embedded Firmware Solutions

中所述

EFI（可扩展固件接口）和coreboot大约在1990年代末期开始。他们从两个不同的目的开始。 EFI的目标之一是将传统BIOS迁移到具有模块化驱动程序模型的现代接口，该模型允许轻松添加和删除组件。另一方面，coreboot大多是从头开始创建的，以保持最少的硬件初始化集来启动Linux，从一开始它就被设计成一个开源项目。 EFI后来被许多行业领导者采用，并变成了UEFI（统一可扩展固件接口）。

并且由于coreboot与UEFI无关，因此它的功能不能准确地映射到UEFI阶段，因此“ Linux作为固件”一文对coreboot实现SEC和PEI进行了概括。 Embedded Firmware Solutions在一个表格中很好地解释了它们的相似性，如下所示：

╔════════════════════════════════════╤════════════╤═════════════════╗
║ Capability                         │ coreboot   │ UEFI PI         ║
╠════════════════════════════════════╪════════════╪═════════════════╣
║ The reset vector and               │ boot block │ SEC             ║
║ pre cache-as-RAM setup.            │            │                 ║
╟────────────────────────────────────┼────────────┼─────────────────╢
║ Cache-as-RAM setup, early silicon  │ rom stage  │ PEI             ║
║ initialization, memory setup.      │            │ Create HOBs     ║
║ Covered largely by Intel FSP.      │            │                 ║
╟────────────────────────────────────┼────────────┼─────────────────╢
║ Normal device setup and main       │ ram stage  │ Early DXE       ║
║ board configuration. Publishes     │            │                 ║
║ SMBIOS/ACPI tables.                │            │                 ║
╟────────────────────────────────────┼────────────┼─────────────────╢
║ Memory map hand-off.               │ CBMEM      │ UEFI Memory Map ║
╟────────────────────────────────────┼────────────┼─────────────────╢
║ The OS or application boot loader. │ payload    │ DXE BDS &       ║
║                                    │            │ UEFI Drivers    ║
╚════════════════════════════════════╧════════════╧═════════════════╝

此外，您说的没错

英特尔表示，某些架构不会公开其初始化序列，该架构可能为SEC和PEI阶段提供FSP

这就是为什么coreboot不能代替FSP，而是依靠Intel FSP来实现其目标的原因。如Embedded Firmware Solutions中所述：

coreboot理念与Intel FSP理念保持一致。 coreboot硬件初始化框架处理FSP芯片初始化API，配置系统外围设备并加载有效负载。

如果您想了解有关Intel FSP，coreboot和UEFI的更多信息，我建议您通读Embedded Firmware Solutions。它解释了他们的历史，并且非常深入地介绍了技术细节，并且整本书是免费的可供下载。

Answer 3

据我所知，我认为Coreboot不能完全处理SEC / PEI阶段，这取决于您所说的固件支持包，而Coreboot使用FSP来执行SEC / PEI。

LinuxBoot在固件阶段与Coreboot有何不同？

3 个答案: