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