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