问在固件阶段，LinuxBoot与Coreboot有什么不同？

EN

UEFI由多个阶段组成: SEC、PEI和DXE。LinuxBoot取代DXE阶段，Coreboot取代SEC和PEI阶段。

Coreboot负责Linux无法完成的平台初始化，例如DRAM初始化(也称为“培训”)和ACPI表生成。然后，Linux作为Coreboot有效负载工作，它执行诸如PCI设备枚举等操作，并将引导加载程序或can kexec()加载到另一个Linux内核中。

LinuxBoot不能执行平台初始化，而coreboot则可以。正如LinuxBoot: Linux作为固件文章中所解释的那样(强调我的观点)：

就像LinuxBoot initramfs依赖于启动LinuxBoot内核一样，LinuxBoot内核也依赖于引导过程中的前一步。这可能涉及到核心引导。LinuxBoot和coreboot并不是竞争对手，而是解决了启动的不同阶段。请记住，UEFI引导过程由四个阶段组成，其中第三个阶段(驱动程序执行环境或DXE)是LinuxBoot的启动点。Coreboot是前两个阶段的实现，它可以替换主板供应商提供的UEFI固件。Coreboot只支持范围很窄的硬件，但是，当它可以与LinuxBoot协同使用时，它启用了一个几乎完全开放的引导过程。

正如LinuxBoot 主页上的这个图表所示，LinuxBoot是在硬件初始化之后出现的，它也可以是UEFI的一个有效负载：

LinuxBoot的常见问题还声明：

LinuxBoot与UEFI以及coreboot兼容。您可以使用LinuxBoot作为UEFI或核心重新引导有效负载。

至于您对Eloy的回答的评论，我想coreboot的文档没有提到SEC和PEI，因为这些都是UEFI的概念，coreboot从来都不是为了遵循UEFI规范而设计的。正如在嵌入式固件解决方案中所解释的

EFI (可扩展固件接口)和coreboot大约在20世纪90年代末开始。他们从两个不同的目的开始。EFI的目标之一是将遗留的BIOS转移到一个具有模块化驱动程序模型的现代接口上，该模型允许使用ease.coreboot添加和删除组件，另一方面，大部分是从零开始创建的，目的是为引导Linux保留一组最少的硬件初始化，从一开始它就被设计为一个开源项目。EFI后来被许多业界领袖所采用，并转化为UEFI (统一可扩展固件接口)。

而且，由于coreboot与UEFI无关，它的功能并不完全映射到UEFI阶段，因此，当coreboot实现SEC和PEI时，"Linux“这篇文章有点泛化。嵌入式固件解决方案在一个表格中很好地解释了它们的相似之处，转载如下：

╔════════════════════════════════════╤════════════╤═════════════════╗
║ 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    ║
╚════════════════════════════════════╧════════════╧═════════════════╝

此外，你说得对

Intel说，某些体系结构不会公开它们的初始化序列，它可能为SEC和PEI阶段提供FSP。

这就是为什么coreboot没有取代FSP，而是依靠Intel FSP来实现它的目标。正如在嵌入式固件解决方案中所解释的

核心重新启动的哲学与英特尔的FSP哲学相一致。coreboot硬件初始化框架处理FSP硅初始化API，配置系统外围设备，并加载有效负载。

如果您有兴趣了解有关Intel、coreboot、UEFI的更多信息，我鼓励您阅读嵌入式固件解决方案。它解释了他们的历史，并深入到技术细节，全文是免费的下载。

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