On Tue, 5 May 2020 at 10:38, François Ozog francois.ozog@linaro.org wrote:
On Tue, 5 May 2020 at 09:16, Ard Biesheuvel ard.biesheuvel@arm.com wrote:
On 5/4/20 8:34 PM, Andrei Warkentin wrote:
Hi Grant,
Please also factor in requirements for how memory containing DT must be described in the memory map (Ard mentioned using EfiACPIReclaimMemory).
Maybe something like:
- Devicetree loaded at boot time must be contained in memory of type EfiACPIReclaimMemory.
Ack.
Are there any alignment requirements? I think of 64KB pages OS.
Even though EfiACPIReclaimMemory is not listed as having memory type constraints as EfiACPIReclaimMemoryNVS in section 2.3, I wonder if architecture's last level largest page size alignment is of interest here.
We could add a general guideline to align the allocation to the lowest power-of-2 value that exceeds the size. That way, it can be mapped (or omitted) optimally regardless of the OS page size.
Note that these alignment constraints are mostly to avoid mismatched attributes within the same page frame. For instance, the NVS memory may need to be mapped uncached by the firmware internally, so it cannot share a 64k page with another firmware provided allocation that requires cacheable attributes.
For reclaim memory, the semantics are clearly that it is ordinary memory, and that the contents are only of interest to the OS if it chooses to consume them. This is why the alignment constraints do not cover this type.
Not a strong position, but you may also want to put the foot down on
*when* the exposed Devicetree blob must be consistent (consistent with some firmware setting changes). Perhaps thats at ReadyToBoot or ExitBootServices.
ReadyToBoot is a PI concept, not a UEFI concept. And EBS() is way too late. But I don't think there is any need to specify this: the firmware needs to make the DT available before calling the OS loader - I don't think we need to spell that out.
But this brings something else to mind: in the past, we had to push back on efforts to upstream Linux changes to install the DTB back into the configuration table, so that at EBS() time, the firmware would see the modified version. *That* is something we should rule out:
""" Firmware must not consume device tree descriptions installed as configuration tables under this GUID by the OS loader or other boot stages that are not part of the system firmware itself """
I don't think the exact choice matters as long as it's called out, so that an OS loader can be coded to fetch the blob exactly once at the right time, and be guaranteed to work on any EBBR-compliant implementation (IIRC ACPI has the same problem, but you have the luxury of having to worry about that).
You might want to expand the GUID text to be something like:
The following GUID must be used to describe the flattened Devicetree blob (dtb) in the EFI_CONFIGURATION_TABLE structure referenced by the EFI System Table.
A
*From:* Grant Likely grant.likely@arm.com *Sent:* Monday, May 4, 2020 12:20 PM *To:* boot-architecture@lists.linaro.org boot-architecture@lists.linaro.org *Cc:* Grant Likely grant.likely@arm.com; Andrei Warkentin awarkentin@vmware.com; Francois Ozog francois.ozog@linaro.org *Subject:* [EBBR PATCH] Add EFI GUID for device tree blob None of the relevent specs (EFI, DT, EBBR) specify the GUID for passing a DTB. Add it to the EBBR document so it is documented somewhere relevant.
Fixes: #45 Cc: Andrei Warkentin awarkentin@vmware.com Cc: Francois Ozog francois.ozog@linaro.org Signed-off-by: Grant Likely grant.likely@arm.com
source/chapter2-uefi.rst | 10 ++++++++++ 1 file changed, 10 insertions(+)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index f6a5802..cf2f652 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -86,6 +86,16 @@ tables.
- An Advanced Configuration and Power Interface [ACPI]_ table, or
- a Devicetree [DTSPEC]_ system description
+A Devicetree system description MUST be provided in Flattened Devicetree (DTB) +format version 17 or higher. +The following GUID must be used in the EFT system table to identify the DTB.
+.. code-block:: c
- #define EFI_DTB_GUID \
EFI_GUID(0xb1b621d5, 0xf19c, 0x41a5, \0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0)- As stated above, EBBR systems must not provide both ACPI and Devicetree tables at the same time. Systems that support both interfaces must provide a configuration
-- 2.20.1
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
-- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture