ACPI

[Anup Patel]

Hi Heinrich,

On Sat, Dec 16, 2023 at 3:15 PM Heinrich Schuchardt
<heinrich.schuchardt at canonical.com> wrote:
>
> Hello Anup,
>
> different RISC-V platforms have chosen to generate ACPI tables in
> edk2-platforms.
>
> With u-boot-next we can pass ACPI tables generated by
> qemu-system-riscv64 as EFI configuration table to the OS. For x86
> platforms the generation of ACPI tables has been implemented inside
> U-Boot. The same could be done for RISC-V.
>
> Wouldn't it be preferable to move the generation of ACPI tables to the
> OpenSBI layer?
>
> These are the advantages I see:
>
> * Different UEFI implementations don't have to duplicate code. For
> instance you could have a very thin EFI implementation that is just good
> enough to call the Linux entry point (see the discussion about
> Coreboot). Or you could easily switch between EDK II and U-Boot without
> rewriting ACPI related code.
>
> * As far as ACPI tables can be derived from device-trees we could use
> common library functions to generate the tables for all platforms.
>
> To pass ACPI tables from OpenSBI to U-Boot or EDK II we could use a
> device-tree node.

Sharing code to generate ACPI tables between multiple projects (U-Boot
and EDK2) is certainly a good idea but doing it in OpenSBI (M-mode
firmware) has following drawbacks:

1) We will need a DT node to pass the details generated ACPI tables
    which is later redundant.
2) This will bring large amount of code in OpenSBI which is only used
    at boot time and totally unused at runtime.
3) Having it in OpenSBI also makes it RISC-V specific and other
    architectures can't benefit from it.

Instead of the above, I would suggest having an independent dt2acpi
project (just like libfdt) which can be used by both EDK2 and U-Boot.
This will also allow other architectures to use and contribute to the
common dt2acpi project.

Regards,
Anup

>
> Best regards
>
> Heinrich
>
> --
> opensbi mailing list
> opensbi at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/opensbi