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

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 <[email protected]> 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
>
>

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