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
Hey Arthur - thanks for all of the background information here.
Overall, I think this sounds like a good plan, though obviously implementation details need to be worked out. I'm happy when we can work with and support other other open source firmware projects.
One reason I like this is even if it doesn't convince people to switch to coreboot as a whole, it could still increase participation in the project and get additional contributions to our SMBIOS and ACPI table support.
Also if this gets us better support for an alternative UEFI payload, I count that as a huge win as well. Everyone should watch the OSFC presentation "Enabling coreboot for Open System Firmware on ARM Servers" [1]. I'm pretty excited about this.
Maybe we should have a different name for this so this doesn't blend in with and confuse what it means to be running coreboot. "coreboot-late-init", "coreboot-mid-layer" or something that says that it's not the entirety of coreboot. "ATF, now with coreboot technology".
Martin [1] https://www.osfc.io/2023/talks/enabling-coreboot-for-open-system-firmware-on... Nov 8, 2023, 10:17 by arthur@aheymans.xyz:
Trusted Firmware A (> https://github.com/ARM-software/arm-trusted-firmware/tree/master%3E ) 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%3E ). 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
Hi Arthur,
On 08.11.23 18:17, Arthur Heymans wrote:
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".
just a side note: For somebody working for a company that has used old kernels on new hardware, this seems like a weak argument. I actually remember more causes of trouble due to ACPI (and missing related changes in the kernel). Chances that things really work multiplied by the chances that somebody really needs such a setup seem pretty low. So until I hear about some success stories, I'll consider it an empty argument.
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.
When I read below that TF-A hands off FDT, I thought this is fascinating. Do you need any other input to generate ACPI and SMBIOS? I have some idea in mind since FDT in coreboot was first discussed during OSFC 2022: Clear coreboot from ACPI and produce FDT instead. And for OSs that prefer ACPI, have a separate stage that translates things. Didn't think about it, but with SMBIOS it's quite the same. So eventually that would be something that translates FDT --> ACPI, SMBIOS. Basically what you described for ARM64.
Do you have any platform code / coreboot "port" published yet? Could help to get an overview of what is needed :)
Cheers, Nico
Hi
Thanks for the quick responses.
Maybe we should have a different name for this so this doesn't blend in
with and confuse what it means to be running coreboot. "coreboot-late-init", "coreboot-mid-layer" or something that says that it's not the entirety of coreboot. "ATF, now with coreboot technology".
You mean a different name for the ramstage we want to use? "libcoreboot" ? Actually
just a side note: For somebody working for a company that has used old
kernels on new hardware, this seems like a weak argument. I actually remember more causes of trouble due to ACPI (and missing related changes in the kernel). Chances that things really work multiplied by the chances that somebody really needs such a setup seem pretty low. So until I hear about some success stories, I'll consider it an empty argument.
I don't disagree. ACPI provides the additional 'code' 'feature' rather than being data driven like devicetree however that does not make the argument that much stronger. In practice you need to maintain binding just as much as you do with devicetree. People at Red Hat think otherwise and Windows also only supports ACPI/UEFI... It's also a question if Linux would accept devicetree bindings for ARM server hardware? I don't think anyone has tried but booting kernel with 0 code and just a text file would be a great POC.
When I read below that TF-A hands off FDT, I thought this is
fascinating. Do you need any other input to generate ACPI and SMBIOS? I have some idea in mind since FDT in coreboot was first discussed during OSFC 2022: Clear coreboot from ACPI and produce FDT instead. And for OSs that prefer ACPI, have a separate stage that translates things. Didn't think about it, but with SMBIOS it's quite the same. So eventually that would be something that translates FDT --> ACPI, SMBIOS. Basically what you described for ARM64.
Oh cool idea! It would also work well with the idea in the " RFC: generating more ACPI tables at buildtime" thread I posted some time ago. About TF-A handing off devicetree. That's actually an option in TF-A on the platform we worked on. I'm not sure it exists ubiquitously.
Do you have any platform code / coreboot "port" published yet?
Could help to get an overview of what is needed :)
I hope very soon. Last I heard we had a green light to publish it.
Kind regards
Arthur Heymans
On Wed, Nov 8, 2023 at 7:45 PM Nico Huber nico.h@gmx.de wrote:
Hi Arthur,
On 08.11.23 18:17, Arthur Heymans wrote:
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".
just a side note: For somebody working for a company that has used old kernels on new hardware, this seems like a weak argument. I actually remember more causes of trouble due to ACPI (and missing related changes in the kernel). Chances that things really work multiplied by the chances that somebody really needs such a setup seem pretty low. So until I hear about some success stories, I'll consider it an empty argument.
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.
When I read below that TF-A hands off FDT, I thought this is fascinating. Do you need any other input to generate ACPI and SMBIOS? I have some idea in mind since FDT in coreboot was first discussed during OSFC 2022: Clear coreboot from ACPI and produce FDT instead. And for OSs that prefer ACPI, have a separate stage that translates things. Didn't think about it, but with SMBIOS it's quite the same. So eventually that would be something that translates FDT --> ACPI, SMBIOS. Basically what you described for ARM64.
Do you have any platform code / coreboot "port" published yet? Could help to get an overview of what is needed :)
Cheers, Nico
-
Arthur Heymans -
Martin Roth -
Nico Huber