Trusted Firmware A ( https://github.com/ARM-software/arm-trusted-firmware/tree/master) is ARMs reference firmware implementation. It currently consists of multiple programs of which at least the following: - BL1: roughly equivalent to coreboot's bootblock - BL2: roughly equivalent to coreboot's rom and ramstage - BL31: Implements a secure runtime, required by for instance Linux, also used by coreboot - BL32: roughly equivalent to a payload
On ARM64 coreboot currently takes BL31 from TF-A. On some platforms BL31 is even the only component that is implemented in TF-A as a different program like coreboot or u-boot takes care of platform initialization. However on some platforms a 'full' working TF-A implementation exists.
On ARM server platforms the 'preferred' way of informing the OS is via UEFI, ACPI and SMBIOS. There is some rationale on why: https://www.kernel.org/doc/Documentation/arm64/arm-acpi.txt TL;DR: "if you want to run an old kernel with new hardware ACPI could be a better solution than devicetree". Both the UEFI and ACPI spec are wild beasts to tame (with many pages) so ARM came up with essentially a TL;DR of that spec which is called Server Base Boot Requirements ( https://documentation-service.arm.com/static/63cfe3aee4378a55c5e03d96?token= ).
Now on a lot of existing ARM server platforms TF-A exists as 'full' solution. Currently the SBBR is satisfied by adding a EDK2 or other proprietary UEFI solution that gets loaded by TF-A. Not everyone likes these UEFI implementations as they are big and well... not so nice. So the idea came up to lighten that part of the burden (implementing tables and loading the OS): use coreboot to generate ACPI and SMBIOS (well supported on x86 and small changes needed for ARM), implement a small UEFI (e.g. with libpayload, just enough to load Linux from flash) to get a lightweight LinuxBoot firmware.
This is a pretty different bootflow than what most are used to in coreboot. Normally coreboot is the first code that gets executed (on the main CPU) and it's in charge of hardware init (or offloads that to blob). Here TF-A would be the first code that gets executed. This for instance means that a different exception level would be used: ( https://review.coreboot.org/c/coreboot/+/74798). Also in this use case only ramstage (with a potentially a decompressor stage to make things smaller) would be used as we start in RAM with most of the hardware init done.
So here are my thoughts on the idea: - reuse working solutions (TF-A) can be a good idea: easier porting. - The scope of the coreboot side of things is small and very reusable: generating SMBIOS and ACPI is quite portable between platforms. - Using only ramstage can be minimally invasive. A similar thing was done to optionally build romstage sources inside the bootblock: https://review.coreboot.org/c/coreboot/+/55068 - Coreboot's security model often relies on it being the first code that executes. This might need some changes. - Handoff data from TF-A is often in FDT format for which ramstage has support. - TF-A is BSD3 licensed. You may not always have access to the source code for your platform. - Maybe the ease of use and quality of coreboot convinces a more full adoption on server (use only BL31 like other platforms)? Maybe I'm naive on this?
The platforms we implemented A POC doing this, have an open source TF-A btw.
As this is a pretty new way of using coreboot (ramstage only), I wanted to have your ideas on this.
Arthur Heymans