On Tue, 5 May 2020 at 09:16, Ard Biesheuvel <ard.biesheu...@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. > 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.lik...@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.lik...@arm.com>; Andrei Warkentin > > <awarken...@vmware.com>; Francois Ozog <francois.o...@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 <awarken...@vmware.com> > > Cc: Francois Ozog <francois.o...@linaro.org> > > Signed-off-by: Grant Likely <grant.lik...@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.o...@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
