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