[PATCH 04/40] arm: Allow supporting ACPI-table generation

Simon Glass sjg at chromium.org
Wed Dec 1 19:02:18 CET 2021

Hi François,

On Wed, 1 Dec 2021 at 10:45, François Ozog <francois.ozog at linaro.org> wrote:
> Hi
> Le mer. 1 déc. 2021 à 18:11, Tom Rini <trini at konsulko.com> a écrit :
>> On Wed, Dec 01, 2021 at 05:49:54PM +0100, Mark Kettenis wrote:
>> > > From: Simon Glass <sjg at chromium.org>
>> > > Date: Wed,  1 Dec 2021 09:02:38 -0700
>> > >
>> > > Some ARM boards are using ACPI now. It seems that U-Boot should support
>> > > this method. Add ARM to the list of archs which can generate ACPI tables.
>> >
>> > Can you explain why you think U-Boot should care?
>> >
>> > Because I think promoting ACPI as a viable firmware interface for the
>> > type of boards supported by U-Boot would be a serious mistake...
>> Given the large overlap of SoCs that support both SystemReady IR and
>> SystemReady ES, I asked Simon how hard it would be to pass ACPI tables,
>> instead of DTB.  Are there going to be some challenges to be able to get
>> ES certified under U-Boot?  Certainly.  But I'm not convinced that
>> U-Boot is just a wrong-fit for the ES case when part of the whole point
>> of these certifications is that it doesn't matter what's implementing
>> it, it's a standard.
> looks like an exciting endeavor !
> If we factor in safety certification, there are probably more chances to achieve this with U-Boot that EDK2. That said, AML implementation in U-Boot, which may end up being necessary, need special care.

BTW there is a fair bit of AML-generation code behind CONFIG_ACPIGEN
[1]. It is widely used on coral, for example. It also has unit tests!

As to Mark's point, I am very happy to share my own opinions on ACPI,
but I think that is sideways of the discussion here.


[1] https://github.com/u-boot/u-boot/blob/master/include/acpi/acpigen.h
[2] https://github.com/u-boot/u-boot/blob/master/test/dm/acpigen.c

More information about the U-Boot mailing list