On 9/1/20 12:45 PM, Grant Likely wrote:
Early in EBBR discussions the decision was made that firmware should not provide both DT and ACPI at the same time. The reasoning had been that we didn't want to encourage 'hybrid' approaches where the OS tries to consume both DT and ACPI descriptions.
However, this fear has not so-far born out, and feedback has been that requiring a boot-time switch to select either DT or ACPI is a support issue for OS vendors. They would rather see ACPI (or DT) always turned on if it is an option and the OS can choose to use it or not.
Which OS vendor are your referring to?
Why does that OS vendor not implement both ACPI and DT support to encompass as many devices as possible?
What would we expect to happen if the ACPI and DT content are not equivalent?
Best regards
Heinrich
Thoughts? Can the exclusive or be relaxed here?
Signed-off-by: Grant Likely grant.likely@arm.com
source/chapter2-uefi.rst | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 066fefb..e0e71d6 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -80,18 +80,12 @@ Configuration Tables A UEFI system that complies with this specification may provide the additional tables via the EFI Configuration Table.
-Compliant systems are required to provide one, but not both, of the following +Compliant systems are required to provide at least one of the following tables:
- an Advanced Configuration and Power Interface [ACPI]_ table, or
- a Devicetree [DTSPEC]_ system description
-EBBR systems must not provide both ACPI and Devicetree -tables at the same time. -Systems that support both interfaces must provide a configuration -mechanism to select either ACPI or Devicetree, -and must ensure only the selected interface is provided to the OS loader.
- Devicetree ^^^^^^^^^^