RFC: A new bootflow on ARM64 server using more of TF-A

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

_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]