Re: ACPI vs Device Tree - moving forward

[Matthew Garrett <mjg59@srcf.ucam.org>]

On Fri, Aug 23, 2013 at 04:25:43PM -0700, Darren Hart wrote:

> It had been my hope at the start of this project to open the creation of
> SSDTs up to inventors and hackers who want to create Lures for the
> MinnowBoard in such a way that they could write these SSDTs and load
> them from a file at boot time, modify, rebuild, iterate, etc. When/if
> the Lure goes to production, the SSDT could either be stored on an
> EEPROM, or for very low volume boards, possibly just shipped as a binary
> to be loaded (with source available of course).

There's no fundamental problem with doing this, especially on UEFI 
systems. As long as you know the host ACPI code, it's trivial to merge 
an SSDT in from a UEFI option ROM.

> It appears that Matthew, at least, would prefer this latter scenario
> just used DT instead. However, that seems to leave a gap in the
> transition to incorporating the table into the board firmware should a
> derivative product be made. e.g. no good way to prototype with ACPI. It
> also seems to have all the same problems raised regarding mixing ACPI
> and DT on the same system.

I've no problem with additional hardware shipping with ACPI support - my 
position was more that if a vendor ships a system with ACPI that fails 
to describe the integrated hardware (or does so incorrectly), it's 
probably easier to replace it with DT than a fixed ACPI table. Still, if 
people *do* want to replace shipped ACPI tables, it's probably 
preferable to do that at the bootloader level than the kernel level.

-- 
Matthew Garrett | mjg59@srcf.ucam.org