On 13/05/2020 13:54, Ard Biesheuvel wrote:
On 5/13/20 2:48 PM, Grant Likely wrote:
On 12/05/2020 18:54, Ard Biesheuvel wrote:
[...]
""" If a DTB is used to describe the platform to the OS, it must be installed as a EFI configuration table under the appropriate GUID by the system firmware before starting any UEFI applications or drivers that are not part of the system firmware image themselves. Once the DTB is installed as a configuration table, the system firmware must not make any modifications to it.
Works for me.
UEFI applications are permitted to replace the installed DTB. Modifications to the installed DTB are not allowed, but it is permitted to clone the installed DTB, apply any changes to the clone and install it as a replacement.
I think this goes too far. Modifying a DTB in place is normal practice. Why is in not permitted to modify the firmware-provided DTB in-place?
This is related to the below. If the system firmware is permitted to use DTB internally, we should either require it to publish a copy, or require other agents to make a copy. Otherwise, these other agents may modify the data structure that the firmware relies on for its internal implementation. Of course, this assumes the internal and external DT are the same and thus compatible, which may not be the case.
It's probably a bit sloppy in U-Boot land, but that can be cleaned up if so. When U-Boot does configure itself via DT, it typically has a separate copy for passing to the OS. I don't think it is a problem to specify the loaded DTB is handed off and no longer used once EFI application execution begins. This is the model I was attempting to describe in my draft text.
I've reworked the draft. Here is the new text I'm proposing (including some earlier changes that have been discussed):
g.
---- index c42691b..ff80329 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -86,12 +86,41 @@ tables. - An Advanced Configuration and Power Interface [ACPI]_ table, or - a Devicetree [DTSPEC]_ system description
-As stated above, EBBR systems must not provide both ACPI and Devicetree +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 +========== + +If firmware provides a Devicetree system description then it must be provided +in Flattened Devicetree (DTB) format version 17 or higher as described in +[DTSPEC]_ § 5.1. +The following GUID must be used in the EFI system table ([UEFI]_ § 4) +to identify the DTB. +The DTB must be contained in memory of type EfiACPIReclaimMemory. + +.. code-block:: c + + #define EFI_DTB_GUID \ + EFI_GUID(0xb1b621d5, 0xf19c, 0x41a5, \ + 0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0) + +Firmware must have the DTB resident in memory and installed in the EFI system table +before executing any UEFI applications or drivers that are not part of the system +firmware image. +Once the DTB is installed as a configuration table, +the system firmware must not make any modification to it or reference any data +contained within the DTB. + +UEFI applications are permitted to modify or replace the loaded DTB. +System firmware must not depend on any data contained within the DTB. +If system firmware makes use of a DTB for its own configuration, +it should use a separate private copy that is not installed in the +EFI System Table or otherwise be exposed to EFI applications. + UEFI Secure Boot (Optional) ---------------------------