[PATCH 04/40] arm: Allow supporting ACPI-table generation
Simon Glass
sjg at chromium.org
Sun Jan 23 22:54:01 CET 2022
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!
[2]
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.
Regards,
Simon
[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
Applied to u-boot-dm, thanks!
More information about the U-Boot
mailing list