Hi François,
On Wed, 1 Dec 2021 at 10:45, François Ozog francois.ozog@linaro.org wrote:
Hi
Le mer. 1 déc. 2021 à 18:11, Tom Rini trini@konsulko.com a écrit :
On Wed, Dec 01, 2021 at 05:49:54PM +0100, Mark Kettenis wrote:
From: Simon Glass sjg@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