How does LinuxBoot differs from Coreboot in the firmware phase?

Question

I am literally confused about the use case of using LinuxBoot as the payload for Coreboot.

I learned that LinuxBoot can completely replace the UEFI's DXE and BDS phases, and then can load the bootloader (say GRUB) or even the Linux kernel directly.

Now, I also read that LinuxBoot can be used as the payload for Coreboot.

If LinuxBoot can do everything from platform initialization to loading kernel, then why would someone even put Coreboot in the sequence? Simply, why the use case of using LinuxBoot as Coreboot's payload exists? What role will Coreboot play?

Answer 1

UEFI consists of multiple phases: SEC, PEI and DXE. LinuxBoot replaces the DXE phase, Coreboot replaces the SEC and PEI phases.

Coreboot is responsible for the platform initialization that cannot be done by Linux, such as DRAM initialization (it is also called "training") and ACPI table generation. Linux then works as a Coreboot payload, which does things such as PCI device enumeration, and loads the bootloader or can kexec() into another Linux kernel.

Answer 2

LinuxBoot cannot do platform initialization while coreboot can. As explained in the LinuxBoot: Linux as firmware article (emphasis mine):

Much like the LinuxBoot initramfs depends on the LinuxBoot kernel to start, so too does the LinuxBoot kernel depend on a previous step in the boot process. This is where coreboot may be involved. LinuxBoot and coreboot are not competitors, rather they address different stages of booting. Remember that the UEFI boot process consists of four stages, of which the third (the driver execution environment or DXE) is the point at which LinuxBoot starts. Coreboot is an implementation of the first two stages, where it can replace the UEFI firmware provided by the motherboard vendor. Coreboot only supports a narrow range of hardware but, when it can be used in concert with LinuxBoot, it enables an almost completely open boot process.

And as shown by this diagram on the LinuxBoot homepage, LinuxBoot comes after hardware initialization, and it can also be a payload of UEFI: LinuxBoot's FAQ also states:

LinuxBoot is compatible with UEFI as well as coreboot. You can use LinuxBoot as a UEFI DXE or as a coreboot payload.

As for your comments on Eloy's answer, I suppose coreboot's docs makes no mention of SEC and PEI because these are UEFI concepts, and coreboot was never designed to follow UEFI specs. As explained in Embedded Firmware Solutions

EFI (Extensible Firmware Interface) and coreboot began around the same time in the late 1990s. They started with two different purposes. One of the objectives of EFI was moving legacy BIOS to a modern interface with a modular driver model that allowed components to be added and removed with ease.coreboot, on the other hand, was mostly created from scratch to keep a minimum set of hardware initialization to boot Linux, and it was designed to be an open source project from the beginning. EFI was later adopted by many industry leaders, and turned into UEFI (Unified Extensible Firmware Interface).

And since coreboot is unrelated to UEFI, its function doesn't map exactly to the UEFI phases, so the "Linux as firmware" article is generalizing a bit when it said that coreboot implements SEC and PEI. Embedded Firmware Solutions explains their similarities nicely in a table, reproduced below:

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

In addition you are correct to say that

certain architectures won't expose their initialization sequence, say Intel, which provides FSP probably for SEC and PEI phases

This is why coreboot does not replace FSP, rather it relies on Intel FSP to achieve its goals. As explained in Embedded Firmware Solutions:

The coreboot philosophy aligns with the Intel FSP philosophy. The coreboot hardware initialization framework handles the FSP silicon initialization API, configures system peripherals, and loads the payload.

I would encourage you read through Embedded Firmware Solutions if you're interested to learn more about Intel FSP, coreboot, UEFI. It explains their history and goes really deep into the technical details, and the full book is free to download.