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.
On 5/4/20 7:20 PM, Grant Likely wrote:
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.
It is not self-evident what format version 17 might refer to.
I would suggest :
A Devicetree system description MUST be provided in Flattened Device Tree (DTB) format version 17 (described in Devicetree Specification 0.2) or higher.
+The following GUID must be used in the EFT system table to identify the DTB.
I would not know what EFT refers to. I cannot find that term in the UEFI spec. And it is not used in EBBR version 1.0. I suggest:
The configuration table with the Flattened Devicetree is identified by the following GUID in the UEFI system table:
Best regards
Heinrich
+.. 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. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On 04/05/2020 19:30, Heinrich Schuchardt wrote:
On 5/4/20 7:20 PM, Grant Likely wrote:
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.
It is not self-evident what format version 17 might refer to.
I would suggest :
A Devicetree system description MUST be provided in Flattened Device Tree (DTB) format version 17 (described in Devicetree Specification 0.2) or higher.
+The following GUID must be used in the EFT system table to identify the DTB.
I would not know what EFT refers to. I cannot find that term in the UEFI spec. And it is not used in EBBR version 1.0. I suggest:
The configuration table with the Flattened Devicetree is identified by the following GUID in the UEFI system table:
Fixed both. Thanks.
g. 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.
On 05.05.20 11:10, Grant Likely wrote:
On 04/05/2020 19:30, Heinrich Schuchardt wrote:
On 5/4/20 7:20 PM, Grant Likely wrote:
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.
It is not self-evident what format version 17 might refer to.
I would suggest :
A Devicetree system description MUST be provided in Flattened Device Tree (DTB) format version 17 (described in Devicetree Specification 0.2) or higher.
+The following GUID must be used in the EFT system table to identify the DTB.
I would not know what EFT refers to. I cannot find that term in the UEFI spec. And it is not used in EBBR version 1.0. I suggest:
The configuration table with the Flattened Devicetree is identified by the following GUID in the UEFI system table:
Fixed both. Thanks.
g. 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.
Hello Grant,
in your repo the new version looks fine. I did not yet see it in any mail. To which list should I subscribe?
Best regards
Heinrich
On 05/05/2020 17:39, Heinrich Schuchardt wrote:
On 05.05.20 11:10, Grant Likely wrote:
On 04/05/2020 19:30, Heinrich Schuchardt wrote:
On 5/4/20 7:20 PM, Grant Likely wrote:
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.
It is not self-evident what format version 17 might refer to.
I would suggest :
A Devicetree system description MUST be provided in Flattened Device Tree (DTB) format version 17 (described in Devicetree Specification 0.2) or higher.
+The following GUID must be used in the EFT system table to identify the DTB.
I would not know what EFT refers to. I cannot find that term in the UEFI spec. And it is not used in EBBR version 1.0. I suggest:
The configuration table with the Flattened Devicetree is identified by the following GUID in the UEFI system table:
Fixed both. Thanks.
g. 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.
Hello Grant,
in your repo the new version looks fine. I did not yet see it in any mail. To which list should I subscribe?
boot-architecture@lists.linaro.org.
I've not yet posted the latest version. I'm still collecting review feedback before I post a v2, which I will do before it gets committed to mainline.
g.
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.
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.
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. 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.
Typo: (IIRC ACPI has the same problem [with consistency], but you have the luxury of NOT having to worry about that [in the context of EBBR]). ________________________________ From: Andrei Warkentin awarkentin@vmware.com Sent: Monday, May 4, 2020 1:34 PM To: Grant Likely grant.likely@arm.com; boot-architecture@lists.linaro.org boot-architecture@lists.linaro.org Cc: Francois Ozog francois.ozog@linaro.org; Ard Biesheuvel Ard.Biesheuvel@arm.com Subject: Re: [EBBR PATCH] Add EFI GUID for device tree blob
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.
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. 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.
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.
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.
From: Ard Biesheuvel ard.biesheuvel@arm.com
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:
Got it. Agreed.
A
On 05/05/2020 08:30, Andrei Warkentin wrote:
*From:* Ard Biesheuvel ard.biesheuvel@arm.com
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:
Got it. Agreed.
Needs to be worded carefully since it is a valid use case to replace the DTB entirely before ExitBootServices(). It needs to be clear that firmware is not required to consume the DTB if it gets replaced.
How about:
+If an OS Loader or other EFI application loads a new DTB that replaces +the DTB provided by firmware and registers it into the EFI_SYSTEM_TABLE, then firmware must not parse, modify, or +otherwise use the data contained in the new DTB. +In this scenario, the application becomes wholly responsible for the DTB data.
g. 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.
On 05.05.20 15:51, Grant Likely wrote:
On 05/05/2020 08:30, Andrei Warkentin wrote:
*From:* Ard Biesheuvel ard.biesheuvel@arm.com
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:
Got it. Agreed.
Needs to be worded carefully since it is a valid use case to replace the DTB entirely before ExitBootServices(). It needs to be clear that firmware is not required to consume the DTB if it gets replaced.
How about:
+If an OS Loader or other EFI application loads a new DTB that replaces +the DTB provided by firmware and registers it into the EFI_SYSTEM_TABLE, then firmware must not parse, modify, or +otherwise use the data contained in the new DTB. +In this scenario, the application becomes wholly responsible for the DTB data.
U-Boot currently makes at least the following changes to the device trees before registering them in the system table:
fdt_root(): Set property 'serial' from environment variable 'serial#'
fdt_chosen(): Set property chosen/bootargs Set property chosen/linux,stdout-path
arch_fixup_fdt() [RISC-V]: Set property chosen/boot-hartid
fdt_fixup_ethernet(): Set property mac-address and local-mac-address
board specific fixups like * setting property fsl,sc_rsrc_id on imx8 * disabling of nodes soc/can, soc/gpu depending on board configuration on STM32MP * enable GPU nodes on Nvidia Tegra (nvidia,gk20a, nvidia,gk20a)
optee_copy_fdt_nodes(): * transfer of optee nodes to new fdt
efi_carve_out_dt_rsv(): * create reserved memory nodes
GRUB is one software that may register a new devicetree as configuration table via the 'devicetree' tree command. Currently none of the fixups above will be applied. This may result in boot failure.
A software like GRUB is not meant to have any device specific knowledge. So it cannot possibly know which fix-ups are needed.
I stumbled over this problem when I booted devices via iSCSI. As up to now Linux device trees are not interchangeable between kernel versions I would have loved to have kernel, initrd, and device tree on the iSCSI drive and managed by GRUB. This would only work out if the device specific fix-ups would be applied after GRUB loads a device-tree. Cf. https://savannah.gnu.org/bugs/?52939.
As long as device-trees loaded by an EFI application like GRUB do not fully describe boards and miss on copying memory reservations, boot-hartid and everything else needed for successful booting the requirement not to fix-up device trees is not plausible to me.
Best regards
Heinrich
g. 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. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On Tue, 5 May 2020 at 17:49, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
...
As long as device-trees loaded by an EFI application like GRUB do not fully describe boards and miss on copying memory reservations, boot-hartid and everything else needed for successful booting the requirement not to fix-up device trees is not plausible to me.
This is a fair point. The point I made was about firmware relying on changes made by the kernel's EFI stub between entry and the point where it calls ExitBootServices().
On 05/05/2020 16:57, Ard Biesheuvel wrote:
On Tue, 5 May 2020 at 17:49, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
...
As long as device-trees loaded by an EFI application like GRUB do not fully describe boards and miss on copying memory reservations, boot-hartid and everything else needed for successful booting the requirement not to fix-up device trees is not plausible to me.
This is a fair point. The point I made was about firmware relying on changes made by the kernel's EFI stub between entry and the point where it calls ExitBootServices().
Can we create a flow-diagram of who needs to modify what? Here's a first attempt:
Scenario 1: Firmware provides DTB
1) Firmware loads stock DTB into EfiACPIReclaimMemory 2) Firmware updates DTB /chosen and /memory with current config ---- DTB becomes immutable to firmware 3) Firmware calls EFI Application or OS Loader 4) ExitBootServices() 5) OS Consumes firmware-provided DTB
Scenario 2: EFI Application provides replacement DTB and handles fixups
1) Firmware loads stock DTB into EfiACPIReclaimMemory 2) Firmware updates DTB /chosen and /memory with current config ---- DTB becomes immutable to firmware 3) Firmware calls EFI Application which provides replacement DTB a) Application loads replacement DTB into EfiACPIReclaimMemory b) Application updates replacement DTB with /chosen & /memory from default DTB c) Application calls OS Loader 5) ExitBootServices() 6) OS Consumes replacement DTB
Scenario 3: EFI Application provides replacement DTB; but depends on firmware to provide fixups
1) Firmware loads stock DTB into EfiACPIReclaimMemory 2) Firmware calls EFI Application which provides replacement DTB a) Application loads replacement DTB into EfiACPIReclaimMemory b) Application calls OS Loader 3) ExitBootServices() a) Firmware updates current DTB /chosen and /memory with current config ---- DTB becomes immutable to firmware 4) OS Consumes replacement DTB
These are obviously trivial descriptions, but I'd like to flush out what is actually required. There is going to be tension here between what OS vendors need, and what vertically integrated embedded users will need.
g.
On Wed, 6 May 2020 at 15:56, Grant Likely grant.likely@arm.com wrote:
On 05/05/2020 16:57, Ard Biesheuvel wrote:
On Tue, 5 May 2020 at 17:49, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
...
As long as device-trees loaded by an EFI application like GRUB do not fully describe boards and miss on copying memory reservations, boot-hartid and everything else needed for successful booting the requirement not to fix-up device trees is not plausible to me.
This is a fair point. The point I made was about firmware relying on changes made by the kernel's EFI stub between entry and the point where it calls ExitBootServices().
Can we create a flow-diagram of who needs to modify what? Here's a first attempt:
Scenario 1: Firmware provides DTB
- Firmware loads stock DTB into EfiACPIReclaimMemory
- Firmware updates DTB /chosen and /memory with current config
---- DTB becomes immutable to firmware 3) Firmware calls EFI Application or OS Loader 4) ExitBootServices() 5) OS Consumes firmware-provided DTB
Scenario 2: EFI Application provides replacement DTB and handles fixups
- Firmware loads stock DTB into EfiACPIReclaimMemory
- Firmware updates DTB /chosen and /memory with current config
---- DTB becomes immutable to firmware 3) Firmware calls EFI Application which provides replacement DTB a) Application loads replacement DTB into EfiACPIReclaimMemory b) Application updates replacement DTB with /chosen & /memory from default DTB c) Application calls OS Loader 5) ExitBootServices() 6) OS Consumes replacement DTB
Scenario 3: EFI Application provides replacement DTB; but depends on firmware to provide fixups
- Firmware loads stock DTB into EfiACPIReclaimMemory
- Firmware calls EFI Application which provides replacement DTB a) Application loads replacement DTB into EfiACPIReclaimMemory b) Application calls OS Loader
- ExitBootServices() a) Firmware updates current DTB /chosen and /memory with current config
---- DTB becomes immutable to firmware 4) OS Consumes replacement DTB
This doesn't make sense to me. EFI boot does not use /memory nodes in the first place (or /memreserve/s), but the OS does not even install the DTB back into the config table array. In Linux, the EFI stub just passes its address in memory via r0, because that is what the bare metal boot protocol stipulates.
So whatever is in the config table array when the OS loader executes is what it will consume. It is fine if some intermediate agent replaces the DTB entirely, but the firmware should not expect to be able to make any changes to it once it hands off to the next boot stage.
This is essentially why I brought this up: the firmware should provide the DTB. We know that in reality, people used DTBs shipped with the OS, and this is not great but acceptable. If we allow firmware to have a reverse dependency on the DTB, we make this dependency hell only worse, since you may find yourself in the situation where your kernel does not support the DT shipped with your firmware, and your firmware does not support the DT shipped with your kernel.
These are obviously trivial descriptions, but I'd like to flush out what is actually required. There is going to be tension here between what OS vendors need, and what vertically integrated embedded users will need.
On 06/05/2020 15:21, Ard Biesheuvel wrote:
On Wed, 6 May 2020 at 15:56, Grant Likely grant.likely@arm.com wrote:
On 05/05/2020 16:57, Ard Biesheuvel wrote:
On Tue, 5 May 2020 at 17:49, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
...
As long as device-trees loaded by an EFI application like GRUB do not fully describe boards and miss on copying memory reservations, boot-hartid and everything else needed for successful booting the requirement not to fix-up device trees is not plausible to me.
This is a fair point. The point I made was about firmware relying on changes made by the kernel's EFI stub between entry and the point where it calls ExitBootServices().
Can we create a flow-diagram of who needs to modify what? Here's a first attempt:
Scenario 1: Firmware provides DTB
- Firmware loads stock DTB into EfiACPIReclaimMemory
- Firmware updates DTB /chosen and /memory with current config
---- DTB becomes immutable to firmware 3) Firmware calls EFI Application or OS Loader 4) ExitBootServices() 5) OS Consumes firmware-provided DTB
Scenario 2: EFI Application provides replacement DTB and handles fixups
- Firmware loads stock DTB into EfiACPIReclaimMemory
- Firmware updates DTB /chosen and /memory with current config
---- DTB becomes immutable to firmware 3) Firmware calls EFI Application which provides replacement DTB a) Application loads replacement DTB into EfiACPIReclaimMemory b) Application updates replacement DTB with /chosen & /memory from default DTB c) Application calls OS Loader 5) ExitBootServices() 6) OS Consumes replacement DTB
Scenario 3: EFI Application provides replacement DTB; but depends on firmware to provide fixups
- Firmware loads stock DTB into EfiACPIReclaimMemory
- Firmware calls EFI Application which provides replacement DTB a) Application loads replacement DTB into EfiACPIReclaimMemory b) Application calls OS Loader
- ExitBootServices() a) Firmware updates current DTB /chosen and /memory with current config
---- DTB becomes immutable to firmware 4) OS Consumes replacement DTB
This doesn't make sense to me. EFI boot does not use /memory nodes in the first place (or /memreserve/s), but the OS does not even install the DTB back into the config table array. In Linux, the EFI stub just passes its address in memory via r0, because that is what the bare metal boot protocol stipulates.
Ah right, I forgot about that detail. Ignore the bits about /memory. My intent wasn't to be super-accurate at this point, but to start a chat about what firmware updates may need to be applied to a replacement DTB.
So whatever is in the config table array when the OS loader executes is what it will consume. It is fine if some intermediate agent replaces the DTB entirely, but the firmware should not expect to be able to make any changes to it once it hands off to the next boot stage.
This is essentially why I brought this up: the firmware should provide the DTB. We know that in reality, people used DTBs shipped with the OS, and this is not great but acceptable. If we allow firmware to have a reverse dependency on the DTB, we make this dependency hell only worse, since you may find yourself in the situation where your kernel does not support the DT shipped with your firmware, and your firmware does not support the DT shipped with your kernel.
Only if the door is wide open. If there is a /real need/ for a limited set of changes to the dtb, then those specific cases can be spelled out as things firmware is allowed to modify in a replacement DTB. Any scenarios here need to be very specific.
What specific cases do we know about?
g.
On 5/6/20 4:38 PM, Grant Likely wrote:
On 06/05/2020 15:21, Ard Biesheuvel wrote:
On Wed, 6 May 2020 at 15:56, Grant Likely grant.likely@arm.com wrote:
On 05/05/2020 16:57, Ard Biesheuvel wrote:
On Tue, 5 May 2020 at 17:49, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
...
As long as device-trees loaded by an EFI application like GRUB do not fully describe boards and miss on copying memory reservations, boot-hartid and everything else needed for successful booting the requirement not to fix-up device trees is not plausible to me.
This is a fair point. The point I made was about firmware relying on changes made by the kernel's EFI stub between entry and the point where it calls ExitBootServices().
Can we create a flow-diagram of who needs to modify what? Here's a first attempt:
Scenario 1: Firmware provides DTB
- Firmware loads stock DTB into EfiACPIReclaimMemory
- Firmware updates DTB /chosen and /memory with current config
---- DTB becomes immutable to firmware 3) Firmware calls EFI Application or OS Loader 4) ExitBootServices() 5) OS Consumes firmware-provided DTB
Scenario 2: EFI Application provides replacement DTB and handles fixups
- Firmware loads stock DTB into EfiACPIReclaimMemory
- Firmware updates DTB /chosen and /memory with current config
---- DTB becomes immutable to firmware 3) Firmware calls EFI Application which provides replacement DTB a) Application loads replacement DTB into EfiACPIReclaimMemory b) Application updates replacement DTB with /chosen & /memory from default DTB c) Application calls OS Loader 5) ExitBootServices() 6) OS Consumes replacement DTB
Scenario 3: EFI Application provides replacement DTB; but depends on firmware to provide fixups
- Firmware loads stock DTB into EfiACPIReclaimMemory
- Firmware calls EFI Application which provides replacement DTB
a) Application loads replacement DTB into EfiACPIReclaimMemory b) Application calls OS Loader 3) ExitBootServices() a) Firmware updates current DTB /chosen and /memory with current config ---- DTB becomes immutable to firmware 4) OS Consumes replacement DTB
This doesn't make sense to me. EFI boot does not use /memory nodes in the first place (or /memreserve/s), but the OS does not even install the DTB back into the config table array. In Linux, the EFI stub just passes its address in memory via r0, because that is what the bare metal boot protocol stipulates.
Ah right, I forgot about that detail. Ignore the bits about /memory. My intent wasn't to be super-accurate at this point, but to start a chat about what firmware updates may need to be applied to a replacement DTB.
So whatever is in the config table array when the OS loader executes is what it will consume. It is fine if some intermediate agent replaces the DTB entirely, but the firmware should not expect to be able to make any changes to it once it hands off to the next boot stage.
This is essentially why I brought this up: the firmware should provide the DTB. We know that in reality, people used DTBs shipped with the OS, and this is not great but acceptable. If we allow firmware to have a reverse dependency on the DTB, we make this dependency hell only worse, since you may find yourself in the situation where your kernel does not support the DT shipped with your firmware, and your firmware does not support the DT shipped with your kernel.
Only if the door is wide open. If there is a /real need/ for a limited set of changes to the dtb, then those specific cases can be spelled out as things firmware is allowed to modify in a replacement DTB. Any scenarios here need to be very specific.
What specific cases do we know about?
None. There is no way the firmware can currently manipulate the DTB after the EFI stub has taken ownership of it. We load the firmware provided one, copy it into a new allocation and make our changes there. This version is the one that is passed to the OS.
On 06/05/2020 15:52, Ard Biesheuvel wrote:
On 5/6/20 4:38 PM, Grant Likely wrote:
Only if the door is wide open. If there is a /real need/ for a limited set of changes to the dtb, then those specific cases can be spelled out as things firmware is allowed to modify in a replacement DTB. Any scenarios here need to be very specific.
What specific cases do we know about?
None. There is no way the firmware can currently manipulate the DTB after the EFI stub has taken ownership of it. We load the firmware provided one, copy it into a new allocation and make our changes there. This version is the one that is passed to the OS.
Before ExitBootServices()?
g.
On 5/6/20 4:54 PM, Grant Likely wrote:
On 06/05/2020 15:52, Ard Biesheuvel wrote:
On 5/6/20 4:38 PM, Grant Likely wrote:
Only if the door is wide open. If there is a /real need/ for a limited set of changes to the dtb, then those specific cases can be spelled out as things firmware is allowed to modify in a replacement DTB. Any scenarios here need to be very specific.
What specific cases do we know about?
None. There is no way the firmware can currently manipulate the DTB after the EFI stub has taken ownership of it. We load the firmware provided one, copy it into a new allocation and make our changes there. This version is the one that is passed to the OS.
Before ExitBootServices()?
Yes.
On 06/05/2020 15:56, Ard Biesheuvel wrote:
On 5/6/20 4:54 PM, Grant Likely wrote:
On 06/05/2020 15:52, Ard Biesheuvel wrote:
On 5/6/20 4:38 PM, Grant Likely wrote:
Only if the door is wide open. If there is a /real need/ for a limited set of changes to the dtb, then those specific cases can be spelled out as things firmware is allowed to modify in a replacement DTB. Any scenarios here need to be very specific.
What specific cases do we know about?
None. There is no way the firmware can currently manipulate the DTB after the EFI stub has taken ownership of it. We load the firmware provided one, copy it into a new allocation and make our changes there. This version is the one that is passed to the OS.
Before ExitBootServices()?
Yes.
Right, so the kernel stub is completely out and language is needed for when the DTB becomes 'sedimented'. - Before ExitBootServices() - After ???
Second, if an Efi application replaces the DTB, what are the known scenarios for wanting firmware to apply fixups to the DTB (again; need to be very specific)
g.
On Wed, 6 May 2020 at 17:01, Grant Likely grant.likely@arm.com wrote:
On 06/05/2020 15:56, Ard Biesheuvel wrote:
On 5/6/20 4:54 PM, Grant Likely wrote:
On 06/05/2020 15:52, Ard Biesheuvel wrote:
On 5/6/20 4:38 PM, Grant Likely wrote:
Only if the door is wide open. If there is a /real need/ for a limited set of changes to the dtb, then those specific cases can be spelled out as things firmware is allowed to modify in a replacement DTB. Any scenarios here need to be very specific.
What specific cases do we know about?
None. There is no way the firmware can currently manipulate the DTB after the EFI stub has taken ownership of it. We load the firmware provided one, copy it into a new allocation and make our changes there. This version is the one that is passed to the OS.
Before ExitBootServices()?
Yes.
Right, so the kernel stub is completely out and language is needed for when the DTB becomes 'sedimented'.
- Before ExitBootServices()
- After ???
Second, if an Efi application replaces the DTB, what are the known scenarios for wanting firmware to apply fixups to the DTB (again; need to be very specific)
The use of additional helpers such as shim, grub, efibootguard and their DTB handling as well as OS specific fixups (Linux, BSD...) should be out of scope of DTB handover discussion: should just be the GUID, memory type to be used, alignment. I think the only point to note is the DTB inside the table is immutable at the moment the EFIApp is called.
g.
On 5/6/20 5:01 PM, Grant Likely wrote:
On 06/05/2020 15:56, Ard Biesheuvel wrote:
On 5/6/20 4:54 PM, Grant Likely wrote:
On 06/05/2020 15:52, Ard Biesheuvel wrote:
On 5/6/20 4:38 PM, Grant Likely wrote:
Only if the door is wide open. If there is a /real need/ for a limited set of changes to the dtb, then those specific cases can be spelled out as things firmware is allowed to modify in a replacement DTB. Any scenarios here need to be very specific.
What specific cases do we know about?
None. There is no way the firmware can currently manipulate the DTB after the EFI stub has taken ownership of it. We load the firmware provided one, copy it into a new allocation and make our changes there. This version is the one that is passed to the OS.
Before ExitBootServices()?
Yes.
Right, so the kernel stub is completely out and language is needed for when the DTB becomes 'sedimented'.
- Before ExitBootServices()
- After ???
No changes should be made to the DTB after it has been installed as a config table.
Second, if an Efi application replaces the DTB, what are the known scenarios for wanting firmware to apply fixups to the DTB (again; need to be very specific)
None. The firmware should not expect to be given the opportunity to tweak the DTB after it hands off to the next stage.
On 06.05.20 17:14, Ard Biesheuvel wrote:
On 5/6/20 5:01 PM, Grant Likely wrote:
On 06/05/2020 15:56, Ard Biesheuvel wrote:
On 5/6/20 4:54 PM, Grant Likely wrote:
On 06/05/2020 15:52, Ard Biesheuvel wrote:
On 5/6/20 4:38 PM, Grant Likely wrote:
Only if the door is wide open. If there is a /real need/ for a limited set of changes to the dtb, then those specific cases can be spelled out as things firmware is allowed to modify in a replacement DTB. Any scenarios here need to be very specific.
What specific cases do we know about?
None. There is no way the firmware can currently manipulate the DTB after the EFI stub has taken ownership of it. We load the firmware provided one, copy it into a new allocation and make our changes there. This version is the one that is passed to the OS.
Before ExitBootServices()?
Yes.
Right, so the kernel stub is completely out and language is needed for when the DTB becomes 'sedimented'.
- Before ExitBootServices()
- After ???
No changes should be made to the DTB after it has been installed as a config table.
Second, if an Efi application replaces the DTB, what are the known scenarios for wanting firmware to apply fixups to the DTB (again; need to be very specific)
None. The firmware should not expect to be given the opportunity to tweak the DTB after it hands off to the next stage.
This would imply that GRUB should not offer a devicetree command if it does not know what fix-ups are needed?
Should GRUB command be marked as deprecated? - CC Daniel https://www.gnu.org/software/grub/manual/grub/grub.html#devicetree
Best regards
Heinrich
On Wed, 6 May 2020 at 18:40, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06.05.20 17:14, Ard Biesheuvel wrote:
On 5/6/20 5:01 PM, Grant Likely wrote:
On 06/05/2020 15:56, Ard Biesheuvel wrote:
On 5/6/20 4:54 PM, Grant Likely wrote:
On 06/05/2020 15:52, Ard Biesheuvel wrote:
On 5/6/20 4:38 PM, Grant Likely wrote: > Only if the door is wide open. If there is a /real need/ for a > limited set of changes to the dtb, then those specific cases can > be spelled out as things firmware is allowed to modify in a > replacement DTB. Any scenarios here need to be very specific. > > What specific cases do we know about? >
None. There is no way the firmware can currently manipulate the DTB after the EFI stub has taken ownership of it. We load the firmware provided one, copy it into a new allocation and make our changes there. This version is the one that is passed to the OS.
Before ExitBootServices()?
Yes.
Right, so the kernel stub is completely out and language is needed for when the DTB becomes 'sedimented'.
- Before ExitBootServices()
- After ???
No changes should be made to the DTB after it has been installed as a config table.
Second, if an Efi application replaces the DTB, what are the known scenarios for wanting firmware to apply fixups to the DTB (again; need to be very specific)
None. The firmware should not expect to be given the opportunity to tweak the DTB after it hands off to the next stage.
This would imply that GRUB should not offer a devicetree command if it does not know what fix-ups are needed?
grub could apply its own fixups on the provided DTB assuming that the
result is still EFIAcpiReclaim memory.
Should GRUB command be marked as deprecated? - CC Daniel
https://www.gnu.org/software/grub/manual/grub/grub.html#devicetree
Best regards
Heinrich
On Wed, 6 May 2020 at 18:41, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06.05.20 17:14, Ard Biesheuvel wrote:
On 5/6/20 5:01 PM, Grant Likely wrote:
...
Right, so the kernel stub is completely out and language is needed for when the DTB becomes 'sedimented'.
- Before ExitBootServices()
- After ???
No changes should be made to the DTB after it has been installed as a config table.
Second, if an Efi application replaces the DTB, what are the known scenarios for wanting firmware to apply fixups to the DTB (again; need to be very specific)
None. The firmware should not expect to be given the opportunity to tweak the DTB after it hands off to the next stage.
This would imply that GRUB should not offer a devicetree command if it does not know what fix-ups are needed?
Grant and you keep mentioning fixups like it is common today for the system firmware to go and change the DTB at random times after invoking the next stage. What exactly do you have in mind here, and why do you think it works correctly today?
Should GRUB command be marked as deprecated? - CC Daniel https://www.gnu.org/software/grub/manual/grub/grub.html#devicetree
I don't think so. There are valid use cases for it, and the system firmware should not be poking around in the DTB anyway after it has launched the next stage loader.
On 06/05/2020 17:57, Ard Biesheuvel wrote:
On Wed, 6 May 2020 at 18:41, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06.05.20 17:14, Ard Biesheuvel wrote:
On 5/6/20 5:01 PM, Grant Likely wrote:
...
Right, so the kernel stub is completely out and language is needed for when the DTB becomes 'sedimented'.
- Before ExitBootServices()
- After ???
No changes should be made to the DTB after it has been installed as a config table.
Second, if an Efi application replaces the DTB, what are the known scenarios for wanting firmware to apply fixups to the DTB (again; need to be very specific)
None. The firmware should not expect to be given the opportunity to tweak the DTB after it hands off to the next stage.
This would imply that GRUB should not offer a devicetree command if it does not know what fix-ups are needed?
Grant and you keep mentioning fixups like it is common today for the system firmware to go and change the DTB at random times after invoking the next stage. What exactly do you have in mind here, and why do you think it works correctly today?
In the non-EFI boot flow, it is common for U-Boot to load the DTB, and then updating it in the bootm command to insert the kernel command line or in another command (e.g. applying overlays). The concern I've heard is that the EBBR boot flow won't support what is needed in the embedded space.
I want to make sure we're not ruling out behaviour that is required because it hasn't been discussed in this context. I suspect the answer will simply be exactly what you've already described: The DTB becomes static before any EFI applications are executed. Any fixups after that point are the responsibility of the boot flow. I want to be sure that works for the ST, NXP, TI, etc.
g.
Should GRUB command be marked as deprecated? - CC Daniel https://www.gnu.org/software/grub/manual/grub/grub.html#devicetree
I don't think so. There are valid use cases for it, and the system firmware should not be poking around in the DTB anyway after it has launched the next stage loader.
Le mer. 6 mai 2020 à 20:00, Grant Likely grant.likely@arm.com a écrit :
On 06/05/2020 17:57, Ard Biesheuvel wrote:
On Wed, 6 May 2020 at 18:41, Heinrich Schuchardt xypron.glpk@gmx.de
wrote:
On 06.05.20 17:14, Ard Biesheuvel wrote:
On 5/6/20 5:01 PM, Grant Likely wrote:
...
Right, so the kernel stub is completely out and language is needed for when the DTB becomes 'sedimented'.
- Before ExitBootServices()
- After ???
No changes should be made to the DTB after it has been installed as a config table.
Second, if an Efi application replaces the DTB, what are the known scenarios for wanting firmware to apply fixups to the DTB (again; need to be very specific)
None. The firmware should not expect to be given the opportunity to tweak the DTB after it hands off to the next stage.
This would imply that GRUB should not offer a devicetree command if it does not know what fix-ups are needed?
Grant and you keep mentioning fixups like it is common today for the system firmware to go and change the DTB at random times after invoking the next stage. What exactly do you have in mind here, and why do you think it works correctly today?
In the non-EFI boot flow, it is common for U-Boot to load the DTB, and then updating it in the bootm command to insert the kernel command line or in another command (e.g. applying overlays). The concern I've heard is that the EBBR boot flow won't support what is needed in the embedded space.
I have used: Load dTB at address Apply manual fix ups (reserve memory) with fdt U-Boot commands Use the updated dTB with bootefi command Bootefi makes a copy of the passed dTB (regardless if it was modified or not ) Applies the fix ups Heinrich described Install the copied dTB into the efi config table and then invoke the efi app. Are there other things needed for EBBR you had in mind ?
I want to make sure we're not ruling out behaviour that is required because it hasn't been discussed in this context. I suspect the answer will simply be exactly what you've already described: The DTB becomes static before any EFI applications are executed. Any fixups after that point are the responsibility of the boot flow. I want to be sure that works for the ST, NXP, TI, etc.
g.
Should GRUB command be marked as deprecated? - CC Daniel https://www.gnu.org/software/grub/manual/grub/grub.html#devicetree
I don't think so. There are valid use cases for it, and the system firmware should not be poking around in the DTB anyway after it has launched the next stage loader.
On Wed, 6 May 2020 at 20:00, Grant Likely grant.likely@arm.com wrote:
On 06/05/2020 17:57, Ard Biesheuvel wrote:
On Wed, 6 May 2020 at 18:41, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06.05.20 17:14, Ard Biesheuvel wrote:
On 5/6/20 5:01 PM, Grant Likely wrote:
...
Right, so the kernel stub is completely out and language is needed for when the DTB becomes 'sedimented'.
- Before ExitBootServices()
- After ???
No changes should be made to the DTB after it has been installed as a config table.
Second, if an Efi application replaces the DTB, what are the known scenarios for wanting firmware to apply fixups to the DTB (again; need to be very specific)
None. The firmware should not expect to be given the opportunity to tweak the DTB after it hands off to the next stage.
This would imply that GRUB should not offer a devicetree command if it does not know what fix-ups are needed?
Grant and you keep mentioning fixups like it is common today for the system firmware to go and change the DTB at random times after invoking the next stage. What exactly do you have in mind here, and why do you think it works correctly today?
In the non-EFI boot flow, it is common for U-Boot to load the DTB, and then updating it in the bootm command to insert the kernel command line or in another command (e.g. applying overlays). The concern I've heard is that the EBBR boot flow won't support what is needed in the embedded space.
I want to make sure we're not ruling out behaviour that is required because it hasn't been discussed in this context. I suspect the answer will simply be exactly what you've already described: The DTB becomes static before any EFI applications are executed. Any fixups after that point are the responsibility of the boot flow. I want to be sure that works for the ST, NXP, TI, etc.
I think this is just a terminology clash: in the embedded world, the DT is read from a file (which may be shipped separately), and so a 'fixup' step is required to put actual runtime data into it.
In the EDK/ACPI/SBBR world, 'fixing up' the firmware tables is the same as generating them in the first place, since the input is not taken from a file, and not necessarily in true DT format at all: Overdrive in edk2-platforms is a good example, it has a .dtb builtin in with lots of pieces missing, and these are all generated and inserted on the fly. On SynQuacer, I do something similar, but also apply overlays depending on what is plugged into the 96boards LS connector (in theory - only Secure96 is supported at the moment)
So we are basically talking about the same thing, and whatever the firmware needs to at runtime to produce a correct and accurate DT needs to be completed before it calls the next boot stage.
On Wed, May 06, 2020 at 06:59:54PM +0100, Grant Likely wrote:
On 06/05/2020 17:57, Ard Biesheuvel wrote:
On Wed, 6 May 2020 at 18:41, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 06.05.20 17:14, Ard Biesheuvel wrote:
On 5/6/20 5:01 PM, Grant Likely wrote:
...
Right, so the kernel stub is completely out and language is needed for when the DTB becomes 'sedimented'.
- Before ExitBootServices()
- After ???
No changes should be made to the DTB after it has been installed as a config table.
Second, if an Efi application replaces the DTB, what are the known scenarios for wanting firmware to apply fixups to the DTB (again; need to be very specific)
None. The firmware should not expect to be given the opportunity to tweak the DTB after it hands off to the next stage.
This would imply that GRUB should not offer a devicetree command if it does not know what fix-ups are needed?
Grant and you keep mentioning fixups like it is common today for the system firmware to go and change the DTB at random times after invoking the next stage. What exactly do you have in mind here, and why do you think it works correctly today?
In the non-EFI boot flow, it is common for U-Boot to load the DTB, and then updating it in the bootm command to insert the kernel command line or in another command (e.g. applying overlays). The concern I've heard is that the EBBR boot flow won't support what is needed in the embedded space.
Are we concerned to ensure EBBR boot flow supports what is needed (e.g. all the required features are in the spec) or simply that EBBR does not contradict an implementation wishing to do this (no requirement prevents an implementation from doing this)?
I want to make sure we're not ruling out behaviour that is required because it hasn't been discussed in this context. I suspect the answer will simply be exactly what you've already described: The DTB becomes static before any EFI applications are executed.
Same here.
We should consider bootefi in a similar light to bootm. It is *obviously* crazy for any resident component of u-boot to start messing with the DTB after we call bootm. It does not become any less crazy just because we run in boot services... u-boot does not understand what changes the OS bootloader might with to make to the DTB or why and cannot safely alter it.
Daniel.
Any fixups after that point are the responsibility of the boot flow. I want to be sure that works for the ST, NXP, TI, etc.
g.
Should GRUB command be marked as deprecated? - CC Daniel https://www.gnu.org/software/grub/manual/grub/grub.html#devicetree
I don't think so. There are valid use cases for it, and the system firmware should not be poking around in the DTB anyway after it has launched the next stage loader.
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On Wed, May 06, 2020 at 06:40:49PM +0200, Heinrich Schuchardt wrote:
On 06.05.20 17:14, Ard Biesheuvel wrote:
On 5/6/20 5:01 PM, Grant Likely wrote:
On 06/05/2020 15:56, Ard Biesheuvel wrote:
On 5/6/20 4:54 PM, Grant Likely wrote:
On 06/05/2020 15:52, Ard Biesheuvel wrote:
On 5/6/20 4:38 PM, Grant Likely wrote: > Only if the door is wide open. If there is a /real need/ for a > limited set of changes to the dtb, then those specific cases can > be spelled out as things firmware is allowed to modify in a > replacement DTB. Any scenarios here need to be very specific. > > What specific cases do we know about? >
None. There is no way the firmware can currently manipulate the DTB after the EFI stub has taken ownership of it. We load the firmware provided one, copy it into a new allocation and make our changes there. This version is the one that is passed to the OS.
Before ExitBootServices()?
Yes.
Right, so the kernel stub is completely out and language is needed for when the DTB becomes 'sedimented'.
- Before ExitBootServices()
- After ???
No changes should be made to the DTB after it has been installed as a config table.
Second, if an Efi application replaces the DTB, what are the known scenarios for wanting firmware to apply fixups to the DTB (again; need to be very specific)
None. The firmware should not expect to be given the opportunity to tweak the DTB after it hands off to the next stage.
This would imply that GRUB should not offer a devicetree command if it does not know what fix-ups are needed?
Quite the opposite.
It is partly *because* grub (which is part of the OS, not part of the system firmware) is entitled to make changes that the system firmware must leave the DTB alone.
Daniel.
On Thu, 7 May 2020 at 16:50, Daniel Thompson daniel.thompson@linaro.org wrote:
On Wed, May 06, 2020 at 06:40:49PM +0200, Heinrich Schuchardt wrote:
On 06.05.20 17:14, Ard Biesheuvel wrote:
On 5/6/20 5:01 PM, Grant Likely wrote:
On 06/05/2020 15:56, Ard Biesheuvel wrote:
On 5/6/20 4:54 PM, Grant Likely wrote:
On 06/05/2020 15:52, Ard Biesheuvel wrote: > On 5/6/20 4:38 PM, Grant Likely wrote: >> Only if the door is wide open. If there is a /real need/ for a >> limited set of changes to the dtb, then those specific cases can >> be spelled out as things firmware is allowed to modify in a >> replacement DTB. Any scenarios here need to be very specific. >> >> What specific cases do we know about? >> > > None. There is no way the firmware can currently manipulate the DTB > after the EFI stub has taken ownership of it. We load the firmware > provided one, copy it into a new allocation and make our changes > there. This version is the one that is passed to the OS.
Before ExitBootServices()?
Yes.
Right, so the kernel stub is completely out and language is needed for when the DTB becomes 'sedimented'.
- Before ExitBootServices()
- After ???
No changes should be made to the DTB after it has been installed as a config table.
Second, if an Efi application replaces the DTB, what are the known scenarios for wanting firmware to apply fixups to the DTB (again; need to be very specific)
None. The firmware should not expect to be given the opportunity to tweak the DTB after it hands off to the next stage.
This would imply that GRUB should not offer a devicetree command if it does not know what fix-ups are needed?
Quite the opposite.
It is partly *because* grub (which is part of the OS, not part of the system firmware) is entitled to make changes that the system firmware must leave the DTB alone.
Isn't it more accurate to say that grub is part of Linux distros targeting
servers and desktops. In embedded, I am not sure grub is in the picture all the time. In your view, what is the role of grub in the DT lifecycle? I see it as the "authoritative entity" to deal with chosen node (bootargs, cma) and speical reverved-memory for kexec...
Daniel.
On Thu, May 07, 2020 at 05:32:40PM +0200, François Ozog wrote:
On Thu, 7 May 2020 at 16:50, Daniel Thompson daniel.thompson@linaro.org wrote:
On Wed, May 06, 2020 at 06:40:49PM +0200, Heinrich Schuchardt wrote:
On 06.05.20 17:14, Ard Biesheuvel wrote:
On 5/6/20 5:01 PM, Grant Likely wrote:
On 06/05/2020 15:56, Ard Biesheuvel wrote:
On 5/6/20 4:54 PM, Grant Likely wrote: > > > On 06/05/2020 15:52, Ard Biesheuvel wrote: >> On 5/6/20 4:38 PM, Grant Likely wrote: >>> Only if the door is wide open. If there is a /real need/ for a >>> limited set of changes to the dtb, then those specific cases can >>> be spelled out as things firmware is allowed to modify in a >>> replacement DTB. Any scenarios here need to be very specific. >>> >>> What specific cases do we know about? >>> >> >> None. There is no way the firmware can currently manipulate the DTB >> after the EFI stub has taken ownership of it. We load the firmware >> provided one, copy it into a new allocation and make our changes >> there. This version is the one that is passed to the OS. > > Before ExitBootServices()? >
Yes.
Right, so the kernel stub is completely out and language is needed for when the DTB becomes 'sedimented'.
- Before ExitBootServices()
- After ???
No changes should be made to the DTB after it has been installed as a config table.
Second, if an Efi application replaces the DTB, what are the known scenarios for wanting firmware to apply fixups to the DTB (again; need to be very specific)
None. The firmware should not expect to be given the opportunity to tweak the DTB after it hands off to the next stage.
This would imply that GRUB should not offer a devicetree command if it does not know what fix-ups are needed?
Quite the opposite.
It is partly *because* grub (which is part of the OS, not part of the system firmware) is entitled to make changes that the system firmware must leave the DTB alone.
Isn't it more accurate to say that grub is part of Linux distros targeting servers and desktops. In embedded, I am not sure grub is in the picture all the time.
Sure grub isn't a mandatory but on systems which include it then it is part of the OS.
In your view, what is the role of grub in the DT lifecycle? I see it as the "authoritative entity" to deal with chosen node (bootargs, cma) and speical reverved-memory for kexec...
Er... I mostly use it to workaround broken system firmware ;-) and for development and testing.
However from an EBBR point of view there is no reason to care about the role of grub in the DT lifecycle because it is not in scope. Once we have handed over to next component (whether it is grub, the efistub, a bsd loader or any other OS component) then we no longer get a say in what happens to the DT.
Daniel.
On 07/05/2020 20:15, Daniel Thompson wrote:
On Thu, May 07, 2020 at 05:32:40PM +0200, François Ozog wrote:
On Thu, 7 May 2020 at 16:50, Daniel Thompson daniel.thompson@linaro.org wrote:
On Wed, May 06, 2020 at 06:40:49PM +0200, Heinrich Schuchardt wrote:
On 06.05.20 17:14, Ard Biesheuvel wrote:
On 5/6/20 5:01 PM, Grant Likely wrote:
On 06/05/2020 15:56, Ard Biesheuvel wrote: > On 5/6/20 4:54 PM, Grant Likely wrote: >> >> >> On 06/05/2020 15:52, Ard Biesheuvel wrote: >>> On 5/6/20 4:38 PM, Grant Likely wrote: >>>> Only if the door is wide open. If there is a /real need/ for a >>>> limited set of changes to the dtb, then those specific cases can >>>> be spelled out as things firmware is allowed to modify in a >>>> replacement DTB. Any scenarios here need to be very specific. >>>> >>>> What specific cases do we know about? >>>> >>> >>> None. There is no way the firmware can currently manipulate the DTB >>> after the EFI stub has taken ownership of it. We load the firmware >>> provided one, copy it into a new allocation and make our changes >>> there. This version is the one that is passed to the OS. >> >> Before ExitBootServices()? >> > > Yes.
Right, so the kernel stub is completely out and language is needed for when the DTB becomes 'sedimented'.
- Before ExitBootServices()
- After ???
No changes should be made to the DTB after it has been installed as a config table.
Second, if an Efi application replaces the DTB, what are the known scenarios for wanting firmware to apply fixups to the DTB (again; need to be very specific)
None. The firmware should not expect to be given the opportunity to tweak the DTB after it hands off to the next stage.
This would imply that GRUB should not offer a devicetree command if it does not know what fix-ups are needed?
Quite the opposite.
It is partly *because* grub (which is part of the OS, not part of the system firmware) is entitled to make changes that the system firmware must leave the DTB alone.
Isn't it more accurate to say that grub is part of Linux distros targeting servers and desktops. In embedded, I am not sure grub is in the picture all the time.
Sure grub isn't a mandatory but on systems which include it then it is part of the OS.
In your view, what is the role of grub in the DT lifecycle? I see it as the "authoritative entity" to deal with chosen node (bootargs, cma) and speical reverved-memory for kexec...
Er... I mostly use it to workaround broken system firmware ;-) and for development and testing.
However from an EBBR point of view there is no reason to care about the role of grub in the DT lifecycle because it is not in scope. Once we have handed over to next component (whether it is grub, the efistub, a bsd loader or any other OS component) then we no longer get a say in what happens to the DT.
To get back to something concrete in the EBBR text, how about the addition of the following text to the Devicetree section?
--- Firmware must have the DTB resident in memory and listed in the EFI system table before executing any UEFI applications. Firmware must not modify the resident DTB while a UEFI application is executing, including during calls to boot services or runtime services.
UEFI applications are permitted to modify or replace the loaded DTB. Firmware must ignore any changes to the DTB made by an application and simply pass the modified or replaced DTB through to the operating system. Firmware must not depend on the in-memory DTB for its own operation. I.e., Once execution of a UEFI application begins, firmware must treat the resident DTB as an anonymous blob and not depend on any data in the DTB. ---
I think that covers the use cases of UEFI applications making changes to the DTB (for any number of valid reasons); but spells out that the firmware is not to make use of or change the DTB once application execution begins.
Daniel.
On Tue, 12 May 2020 at 19:05, Grant Likely grant.likely@arm.com wrote:
On 07/05/2020 20:15, Daniel Thompson wrote:
On Thu, May 07, 2020 at 05:32:40PM +0200, François Ozog wrote:
On Thu, 7 May 2020 at 16:50, Daniel Thompson daniel.thompson@linaro.org wrote:
On Wed, May 06, 2020 at 06:40:49PM +0200, Heinrich Schuchardt wrote:
On 06.05.20 17:14, Ard Biesheuvel wrote:
On 5/6/20 5:01 PM, Grant Likely wrote: > On 06/05/2020 15:56, Ard Biesheuvel wrote: >> On 5/6/20 4:54 PM, Grant Likely wrote: >>> >>> >>> On 06/05/2020 15:52, Ard Biesheuvel wrote: >>>> On 5/6/20 4:38 PM, Grant Likely wrote: >>>>> Only if the door is wide open. If there is a /real need/ for a >>>>> limited set of changes to the dtb, then those specific cases can >>>>> be spelled out as things firmware is allowed to modify in a >>>>> replacement DTB. Any scenarios here need to be very specific. >>>>> >>>>> What specific cases do we know about? >>>>> >>>> >>>> None. There is no way the firmware can currently manipulate the DTB >>>> after the EFI stub has taken ownership of it. We load the firmware >>>> provided one, copy it into a new allocation and make our changes >>>> there. This version is the one that is passed to the OS. >>> >>> Before ExitBootServices()? >>> >> >> Yes. > > Right, so the kernel stub is completely out and language is needed for > when the DTB becomes 'sedimented'. > - Before ExitBootServices() > - After ??? >
No changes should be made to the DTB after it has been installed as a config table.
> Second, if an Efi application replaces the DTB, what are the known > scenarios for wanting firmware to apply fixups to the DTB (again; need > to be very specific) >
None. The firmware should not expect to be given the opportunity to tweak the DTB after it hands off to the next stage.
This would imply that GRUB should not offer a devicetree command if it does not know what fix-ups are needed?
Quite the opposite.
It is partly *because* grub (which is part of the OS, not part of the system firmware) is entitled to make changes that the system firmware must leave the DTB alone.
Isn't it more accurate to say that grub is part of Linux distros targeting servers and desktops. In embedded, I am not sure grub is in the picture all the time.
Sure grub isn't a mandatory but on systems which include it then it is part of the OS.
In your view, what is the role of grub in the DT lifecycle? I see it as the "authoritative entity" to deal with chosen node (bootargs, cma) and speical reverved-memory for kexec...
Er... I mostly use it to workaround broken system firmware ;-) and for development and testing.
However from an EBBR point of view there is no reason to care about the role of grub in the DT lifecycle because it is not in scope. Once we have handed over to next component (whether it is grub, the efistub, a bsd loader or any other OS component) then we no longer get a say in what happens to the DT.
To get back to something concrete in the EBBR text, how about the addition of the following text to the Devicetree section?
Firmware must have the DTB resident in memory and listed in the EFI system table before executing any UEFI applications. Firmware must not modify the resident DTB while a UEFI application is executing, including during calls to boot services or runtime services.
UEFI applications are permitted to modify or replace the loaded DTB. Firmware must ignore any changes to the DTB made by an application and simply pass the modified or replaced DTB through to the operating system. Firmware must not depend on the in-memory DTB for its own operation. I.e., Once execution of a UEFI application begins, firmware must treat the resident DTB as an anonymous blob and not depend on any data in the DTB.
I think that covers the use cases of UEFI applications making changes to the DTB (for any number of valid reasons); but spells out that the firmware is not to make use of or change the DTB once application execution begins.
This still suggests that the system firmware is involved at all in passing the DTB once it has handed off to any UEFI application including the OS loader, but it shouldn't be.
The system firmware should simply a) *produce* the DTB as a config table before calling any other applications (or even other 3rd party drivers if they are supported - this amounts to the meaning of EndOfDxe in PI) b) not *consume* a DTB from the config table - even if it uses DT internally, it should not reload the DT that a loader may have installed.
On 12/05/2020 18:16, Ard Biesheuvel wrote:
On Tue, 12 May 2020 at 19:05, Grant Likely grant.likely@arm.com wrote:
On 07/05/2020 20:15, Daniel Thompson wrote:
On Thu, May 07, 2020 at 05:32:40PM +0200, François Ozog wrote:
On Thu, 7 May 2020 at 16:50, Daniel Thompson daniel.thompson@linaro.org wrote:
On Wed, May 06, 2020 at 06:40:49PM +0200, Heinrich Schuchardt wrote:
On 06.05.20 17:14, Ard Biesheuvel wrote: > On 5/6/20 5:01 PM, Grant Likely wrote: >> On 06/05/2020 15:56, Ard Biesheuvel wrote: >>> On 5/6/20 4:54 PM, Grant Likely wrote: >>>> >>>> >>>> On 06/05/2020 15:52, Ard Biesheuvel wrote: >>>>> On 5/6/20 4:38 PM, Grant Likely wrote: >>>>>> Only if the door is wide open. If there is a /real need/ for a >>>>>> limited set of changes to the dtb, then those specific cases can >>>>>> be spelled out as things firmware is allowed to modify in a >>>>>> replacement DTB. Any scenarios here need to be very specific. >>>>>> >>>>>> What specific cases do we know about? >>>>>> >>>>> >>>>> None. There is no way the firmware can currently manipulate the DTB >>>>> after the EFI stub has taken ownership of it. We load the firmware >>>>> provided one, copy it into a new allocation and make our changes >>>>> there. This version is the one that is passed to the OS. >>>> >>>> Before ExitBootServices()? >>>> >>> >>> Yes. >> >> Right, so the kernel stub is completely out and language is needed for >> when the DTB becomes 'sedimented'. >> - Before ExitBootServices() >> - After ??? >> > > No changes should be made to the DTB after it has been installed as a > config table. > >> Second, if an Efi application replaces the DTB, what are the known >> scenarios for wanting firmware to apply fixups to the DTB (again; need >> to be very specific) >> > > None. The firmware should not expect to be given the opportunity to > tweak the DTB after it hands off to the next stage.
This would imply that GRUB should not offer a devicetree command if it does not know what fix-ups are needed?
Quite the opposite.
It is partly *because* grub (which is part of the OS, not part of the system firmware) is entitled to make changes that the system firmware must leave the DTB alone.
Isn't it more accurate to say that grub is part of Linux distros targeting servers and desktops. In embedded, I am not sure grub is in the picture all the time.
Sure grub isn't a mandatory but on systems which include it then it is part of the OS.
In your view, what is the role of grub in the DT lifecycle? I see it as the "authoritative entity" to deal with chosen node (bootargs, cma) and speical reverved-memory for kexec...
Er... I mostly use it to workaround broken system firmware ;-) and for development and testing.
However from an EBBR point of view there is no reason to care about the role of grub in the DT lifecycle because it is not in scope. Once we have handed over to next component (whether it is grub, the efistub, a bsd loader or any other OS component) then we no longer get a say in what happens to the DT.
To get back to something concrete in the EBBR text, how about the addition of the following text to the Devicetree section?
Firmware must have the DTB resident in memory and listed in the EFI system table before executing any UEFI applications. Firmware must not modify the resident DTB while a UEFI application is executing, including during calls to boot services or runtime services.
UEFI applications are permitted to modify or replace the loaded DTB. Firmware must ignore any changes to the DTB made by an application and simply pass the modified or replaced DTB through to the operating system. Firmware must not depend on the in-memory DTB for its own operation. I.e., Once execution of a UEFI application begins, firmware must treat the resident DTB as an anonymous blob and not depend on any data in the DTB.
I think that covers the use cases of UEFI applications making changes to the DTB (for any number of valid reasons); but spells out that the firmware is not to make use of or change the DTB once application execution begins.
This still suggests that the system firmware is involved at all in passing the DTB once it has handed off to any UEFI application including the OS loader, but it shouldn't be.
The system firmware should simply a) *produce* the DTB as a config table before calling any other applications (or even other 3rd party drivers if they are supported - this amounts to the meaning of EndOfDxe in PI) b) not *consume* a DTB from the config table - even if it uses DT internally, it should not reload the DT that a loader may have installed.
Can you suggest how I describe this in the spec?
g.
On 5/12/20 7:23 PM, Grant Likely wrote:
On 12/05/2020 18:16, Ard Biesheuvel wrote:
On Tue, 12 May 2020 at 19:05, Grant Likely grant.likely@arm.com wrote:
On 07/05/2020 20:15, Daniel Thompson wrote:
On Thu, May 07, 2020 at 05:32:40PM +0200, François Ozog wrote:
On Thu, 7 May 2020 at 16:50, Daniel Thompson daniel.thompson@linaro.org wrote:
On Wed, May 06, 2020 at 06:40:49PM +0200, Heinrich Schuchardt wrote: > On 06.05.20 17:14, Ard Biesheuvel wrote: >> On 5/6/20 5:01 PM, Grant Likely wrote: >>> On 06/05/2020 15:56, Ard Biesheuvel wrote: >>>> On 5/6/20 4:54 PM, Grant Likely wrote: >>>>> >>>>> >>>>> On 06/05/2020 15:52, Ard Biesheuvel wrote: >>>>>> On 5/6/20 4:38 PM, Grant Likely wrote: >>>>>>> Only if the door is wide open. If there is a /real need/ for a >>>>>>> limited set of changes to the dtb, then those specific >>>>>>> cases can >>>>>>> be spelled out as things firmware is allowed to modify in a >>>>>>> replacement DTB. Any scenarios here need to be very specific. >>>>>>> >>>>>>> What specific cases do we know about? >>>>>>> >>>>>> >>>>>> None. There is no way the firmware can currently manipulate >>>>>> the DTB >>>>>> after the EFI stub has taken ownership of it. We load the >>>>>> firmware >>>>>> provided one, copy it into a new allocation and make our >>>>>> changes >>>>>> there. This version is the one that is passed to the OS. >>>>> >>>>> Before ExitBootServices()? >>>>> >>>> >>>> Yes. >>> >>> Right, so the kernel stub is completely out and language is >>> needed for >>> when the DTB becomes 'sedimented'. >>> - Before ExitBootServices() >>> - After ??? >>> >> >> No changes should be made to the DTB after it has been installed >> as a >> config table. >> >>> Second, if an Efi application replaces the DTB, what are the known >>> scenarios for wanting firmware to apply fixups to the DTB >>> (again; need >>> to be very specific) >>> >> >> None. The firmware should not expect to be given the opportunity to >> tweak the DTB after it hands off to the next stage. > > This would imply that GRUB should not offer a devicetree command > if it > does not know what fix-ups are needed?
Quite the opposite.
It is partly *because* grub (which is part of the OS, not part of the system firmware) is entitled to make changes that the system firmware must leave the DTB alone.
Isn't it more accurate to say that grub is part of Linux distros targeting servers and desktops. In embedded, I am not sure grub is in the picture all the time.
Sure grub isn't a mandatory but on systems which include it then it is part of the OS.
In your view, what is the role of grub in the DT lifecycle? I see it as the "authoritative entity" to deal with chosen node (bootargs, cma) and speical reverved-memory for kexec...
Er... I mostly use it to workaround broken system firmware ;-) and for development and testing.
However from an EBBR point of view there is no reason to care about the role of grub in the DT lifecycle because it is not in scope. Once we have handed over to next component (whether it is grub, the efistub, a bsd loader or any other OS component) then we no longer get a say in what happens to the DT.
To get back to something concrete in the EBBR text, how about the addition of the following text to the Devicetree section?
Firmware must have the DTB resident in memory and listed in the EFI system table before executing any UEFI applications. Firmware must not modify the resident DTB while a UEFI application is executing, including during calls to boot services or runtime services.
UEFI applications are permitted to modify or replace the loaded DTB. Firmware must ignore any changes to the DTB made by an application and simply pass the modified or replaced DTB through to the operating system. Firmware must not depend on the in-memory DTB for its own operation. I.e., Once execution of a UEFI application begins, firmware must treat the resident DTB as an anonymous blob and not depend on any data in the DTB.
I think that covers the use cases of UEFI applications making changes to the DTB (for any number of valid reasons); but spells out that the firmware is not to make use of or change the DTB once application execution begins.
This still suggests that the system firmware is involved at all in passing the DTB once it has handed off to any UEFI application including the OS loader, but it shouldn't be.
The system firmware should simply a) *produce* the DTB as a config table before calling any other applications (or even other 3rd party drivers if they are supported - this amounts to the meaning of EndOfDxe in PI) b) not *consume* a DTB from the config table - even if it uses DT internally, it should not reload the DT that a loader may have installed.
Can you suggest how I describe this in the spec?
Perhaps something along the lines of:
""" 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.
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.
The system firmware may use DTB internally in its implementation, but it must not rely on DTB images that are installed as EFI configuration tables by other agents under the reserved DTB GUID. """
On 12/05/2020 18:54, Ard Biesheuvel wrote:
On 5/12/20 7:23 PM, Grant Likely wrote:
On 12/05/2020 18:16, Ard Biesheuvel wrote:
On Tue, 12 May 2020 at 19:05, Grant Likely grant.likely@arm.com wrote:
On 07/05/2020 20:15, Daniel Thompson wrote:
On Thu, May 07, 2020 at 05:32:40PM +0200, François Ozog wrote:
On Thu, 7 May 2020 at 16:50, Daniel Thompson daniel.thompson@linaro.org wrote:
> On Wed, May 06, 2020 at 06:40:49PM +0200, Heinrich Schuchardt wrote: >> On 06.05.20 17:14, Ard Biesheuvel wrote: >>> On 5/6/20 5:01 PM, Grant Likely wrote: >>>> On 06/05/2020 15:56, Ard Biesheuvel wrote: >>>>> On 5/6/20 4:54 PM, Grant Likely wrote: >>>>>> >>>>>> >>>>>> On 06/05/2020 15:52, Ard Biesheuvel wrote: >>>>>>> On 5/6/20 4:38 PM, Grant Likely wrote: >>>>>>>> Only if the door is wide open. If there is a /real need/ >>>>>>>> for a >>>>>>>> limited set of changes to the dtb, then those specific >>>>>>>> cases can >>>>>>>> be spelled out as things firmware is allowed to modify in a >>>>>>>> replacement DTB. Any scenarios here need to be very specific. >>>>>>>> >>>>>>>> What specific cases do we know about? >>>>>>>> >>>>>>> >>>>>>> None. There is no way the firmware can currently manipulate >>>>>>> the DTB >>>>>>> after the EFI stub has taken ownership of it. We load the >>>>>>> firmware >>>>>>> provided one, copy it into a new allocation and make our >>>>>>> changes >>>>>>> there. This version is the one that is passed to the OS. >>>>>> >>>>>> Before ExitBootServices()? >>>>>> >>>>> >>>>> Yes. >>>> >>>> Right, so the kernel stub is completely out and language is >>>> needed for >>>> when the DTB becomes 'sedimented'. >>>> - Before ExitBootServices() >>>> - After ??? >>>> >>> >>> No changes should be made to the DTB after it has been >>> installed as a >>> config table. >>> >>>> Second, if an Efi application replaces the DTB, what are the >>>> known >>>> scenarios for wanting firmware to apply fixups to the DTB >>>> (again; need >>>> to be very specific) >>>> >>> >>> None. The firmware should not expect to be given the >>> opportunity to >>> tweak the DTB after it hands off to the next stage. >> >> This would imply that GRUB should not offer a devicetree command >> if it >> does not know what fix-ups are needed? > > Quite the opposite. > > It is partly *because* grub (which is part of the OS, not part of > the > system firmware) is entitled to make changes that the system > firmware > must leave the DTB alone.
Isn't it more accurate to say that grub is part of Linux distros targeting servers and desktops. In embedded, I am not sure grub is in the picture all the time.
Sure grub isn't a mandatory but on systems which include it then it is part of the OS.
In your view, what is the role of grub in the DT lifecycle? I see it as the "authoritative entity" to deal with chosen node (bootargs, cma) and speical reverved-memory for kexec...
Er... I mostly use it to workaround broken system firmware ;-) and for development and testing.
However from an EBBR point of view there is no reason to care about the role of grub in the DT lifecycle because it is not in scope. Once we have handed over to next component (whether it is grub, the efistub, a bsd loader or any other OS component) then we no longer get a say in what happens to the DT.
To get back to something concrete in the EBBR text, how about the addition of the following text to the Devicetree section?
Firmware must have the DTB resident in memory and listed in the EFI system table before executing any UEFI applications. Firmware must not modify the resident DTB while a UEFI application is executing, including during calls to boot services or runtime services.
UEFI applications are permitted to modify or replace the loaded DTB. Firmware must ignore any changes to the DTB made by an application and simply pass the modified or replaced DTB through to the operating system. Firmware must not depend on the in-memory DTB for its own operation. I.e., Once execution of a UEFI application begins, firmware must treat the resident DTB as an anonymous blob and not depend on any data in the DTB.
I think that covers the use cases of UEFI applications making changes to the DTB (for any number of valid reasons); but spells out that the firmware is not to make use of or change the DTB once application execution begins.
This still suggests that the system firmware is involved at all in passing the DTB once it has handed off to any UEFI application including the OS loader, but it shouldn't be.
The system firmware should simply a) *produce* the DTB as a config table before calling any other applications (or even other 3rd party drivers if they are supported - this amounts to the meaning of EndOfDxe in PI) b) not *consume* a DTB from the config table - even if it uses DT internally, it should not reload the DT that a loader may have installed.
Can you suggest how I describe this in the spec?
Perhaps something along the lines of:
""" 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?
The system firmware may use DTB internally in its implementation, but it must not rely on DTB images that are installed as EFI configuration tables by other agents under the reserved DTB GUID.
Works for me
g.
"""
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
On 5/13/20 2:48 PM, Grant Likely wrote:
On 12/05/2020 18:54, Ard Biesheuvel wrote:
On 5/12/20 7:23 PM, Grant Likely wrote:
On 12/05/2020 18:16, Ard Biesheuvel wrote:
On Tue, 12 May 2020 at 19:05, Grant Likely grant.likely@arm.com wrote:
On 07/05/2020 20:15, Daniel Thompson wrote:
On Thu, May 07, 2020 at 05:32:40PM +0200, François Ozog wrote: > On Thu, 7 May 2020 at 16:50, Daniel Thompson > daniel.thompson@linaro.org > wrote: > >> On Wed, May 06, 2020 at 06:40:49PM +0200, Heinrich Schuchardt >> wrote: >>> On 06.05.20 17:14, Ard Biesheuvel wrote: >>>> On 5/6/20 5:01 PM, Grant Likely wrote: >>>>> On 06/05/2020 15:56, Ard Biesheuvel wrote: >>>>>> On 5/6/20 4:54 PM, Grant Likely wrote: >>>>>>> >>>>>>> >>>>>>> On 06/05/2020 15:52, Ard Biesheuvel wrote: >>>>>>>> On 5/6/20 4:38 PM, Grant Likely wrote: >>>>>>>>> Only if the door is wide open. If there is a /real need/ >>>>>>>>> for a >>>>>>>>> limited set of changes to the dtb, then those specific >>>>>>>>> cases can >>>>>>>>> be spelled out as things firmware is allowed to modify in a >>>>>>>>> replacement DTB. Any scenarios here need to be very >>>>>>>>> specific. >>>>>>>>> >>>>>>>>> What specific cases do we know about? >>>>>>>>> >>>>>>>> >>>>>>>> None. There is no way the firmware can currently >>>>>>>> manipulate the DTB >>>>>>>> after the EFI stub has taken ownership of it. We load the >>>>>>>> firmware >>>>>>>> provided one, copy it into a new allocation and make our >>>>>>>> changes >>>>>>>> there. This version is the one that is passed to the OS. >>>>>>> >>>>>>> Before ExitBootServices()? >>>>>>> >>>>>> >>>>>> Yes. >>>>> >>>>> Right, so the kernel stub is completely out and language is >>>>> needed for >>>>> when the DTB becomes 'sedimented'. >>>>> - Before ExitBootServices() >>>>> - After ??? >>>>> >>>> >>>> No changes should be made to the DTB after it has been >>>> installed as a >>>> config table. >>>> >>>>> Second, if an Efi application replaces the DTB, what are the >>>>> known >>>>> scenarios for wanting firmware to apply fixups to the DTB >>>>> (again; need >>>>> to be very specific) >>>>> >>>> >>>> None. The firmware should not expect to be given the >>>> opportunity to >>>> tweak the DTB after it hands off to the next stage. >>> >>> This would imply that GRUB should not offer a devicetree >>> command if it >>> does not know what fix-ups are needed? >> >> Quite the opposite. >> >> It is partly *because* grub (which is part of the OS, not part >> of the >> system firmware) is entitled to make changes that the system >> firmware >> must leave the DTB alone. > > Isn't it more accurate to say that grub is part of Linux distros > targeting > servers and desktops. > In embedded, I am not sure grub is in the picture all the time.
Sure grub isn't a mandatory but on systems which include it then it is part of the OS.
> In your view, what is the role of grub in the DT lifecycle? I see > it as the > "authoritative entity" to deal with chosen node (bootargs, cma) and > speical reverved-memory for kexec...
Er... I mostly use it to workaround broken system firmware ;-) and for development and testing.
However from an EBBR point of view there is no reason to care about the role of grub in the DT lifecycle because it is not in scope. Once we have handed over to next component (whether it is grub, the efistub, a bsd loader or any other OS component) then we no longer get a say in what happens to the DT.
To get back to something concrete in the EBBR text, how about the addition of the following text to the Devicetree section?
Firmware must have the DTB resident in memory and listed in the EFI system table before executing any UEFI applications. Firmware must not modify the resident DTB while a UEFI application is executing, including during calls to boot services or runtime services.
UEFI applications are permitted to modify or replace the loaded DTB. Firmware must ignore any changes to the DTB made by an application and simply pass the modified or replaced DTB through to the operating system. Firmware must not depend on the in-memory DTB for its own operation. I.e., Once execution of a UEFI application begins, firmware must treat the resident DTB as an anonymous blob and not depend on any data in the DTB.
I think that covers the use cases of UEFI applications making changes to the DTB (for any number of valid reasons); but spells out that the firmware is not to make use of or change the DTB once application execution begins.
This still suggests that the system firmware is involved at all in passing the DTB once it has handed off to any UEFI application including the OS loader, but it shouldn't be.
The system firmware should simply a) *produce* the DTB as a config table before calling any other applications (or even other 3rd party drivers if they are supported - this amounts to the meaning of EndOfDxe in PI) b) not *consume* a DTB from the config table - even if it uses DT internally, it should not reload the DT that a loader may have installed.
Can you suggest how I describe this in the spec?
Perhaps something along the lines of:
""" 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.
The system firmware may use DTB internally in its implementation, but it must not rely on DTB images that are installed as EFI configuration tables by other agents under the reserved DTB GUID.
Works for me
g.
"""
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
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) ---------------------------
On 06/05/2020 15:52, Ard Biesheuvel wrote:
On 5/6/20 4:38 PM, Grant Likely wrote:
On 06/05/2020 15:21, Ard Biesheuvel wrote:
On Wed, 6 May 2020 at 15:56, Grant Likely grant.likely@arm.com wrote:
On 05/05/2020 16:57, Ard Biesheuvel wrote:
On Tue, 5 May 2020 at 17:49, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
...
As long as device-trees loaded by an EFI application like GRUB do not fully describe boards and miss on copying memory reservations, boot-hartid and everything else needed for successful booting the requirement not to fix-up device trees is not plausible to me.
This is a fair point. The point I made was about firmware relying on changes made by the kernel's EFI stub between entry and the point where it calls ExitBootServices().
Can we create a flow-diagram of who needs to modify what? Here's a first attempt:
Scenario 1: Firmware provides DTB
- Firmware loads stock DTB into EfiACPIReclaimMemory
- Firmware updates DTB /chosen and /memory with current config
---- DTB becomes immutable to firmware 3) Firmware calls EFI Application or OS Loader 4) ExitBootServices() 5) OS Consumes firmware-provided DTB
Scenario 2: EFI Application provides replacement DTB and handles fixups
- Firmware loads stock DTB into EfiACPIReclaimMemory
- Firmware updates DTB /chosen and /memory with current config
---- DTB becomes immutable to firmware 3) Firmware calls EFI Application which provides replacement DTB a) Application loads replacement DTB into EfiACPIReclaimMemory b) Application updates replacement DTB with /chosen & /memory from default DTB c) Application calls OS Loader 5) ExitBootServices() 6) OS Consumes replacement DTB
Scenario 3: EFI Application provides replacement DTB; but depends on firmware to provide fixups
- Firmware loads stock DTB into EfiACPIReclaimMemory
- Firmware calls EFI Application which provides replacement DTB
a) Application loads replacement DTB into EfiACPIReclaimMemory b) Application calls OS Loader 3) ExitBootServices() a) Firmware updates current DTB /chosen and /memory with current config ---- DTB becomes immutable to firmware 4) OS Consumes replacement DTB
This doesn't make sense to me. EFI boot does not use /memory nodes in the first place (or /memreserve/s), but the OS does not even install the DTB back into the config table array. In Linux, the EFI stub just passes its address in memory via r0, because that is what the bare metal boot protocol stipulates.
Ah right, I forgot about that detail. Ignore the bits about /memory. My intent wasn't to be super-accurate at this point, but to start a chat about what firmware updates may need to be applied to a replacement DTB.
So whatever is in the config table array when the OS loader executes is what it will consume. It is fine if some intermediate agent replaces the DTB entirely, but the firmware should not expect to be able to make any changes to it once it hands off to the next boot stage.
This is essentially why I brought this up: the firmware should provide the DTB. We know that in reality, people used DTBs shipped with the OS, and this is not great but acceptable. If we allow firmware to have a reverse dependency on the DTB, we make this dependency hell only worse, since you may find yourself in the situation where your kernel does not support the DT shipped with your firmware, and your firmware does not support the DT shipped with your kernel.
Only if the door is wide open. If there is a /real need/ for a limited set of changes to the dtb, then those specific cases can be spelled out as things firmware is allowed to modify in a replacement DTB. Any scenarios here need to be very specific.
What specific cases do we know about?
None. There is no way the firmware can currently manipulate the DTB after the EFI stub has taken ownership of it. We load the firmware provided one, copy it into a new allocation and make our changes there. This version is the one that is passed to the OS.
To clarify; I was not talking about the kernel's EFI stub in any scenario. I was asking about other EFI applications making changes before the kernel stub is called.
g.
On Wed, 6 May 2020 at 15:56, Grant Likely grant.likely@arm.com wrote:
On 05/05/2020 16:57, Ard Biesheuvel wrote:
On Tue, 5 May 2020 at 17:49, Heinrich Schuchardt xypron.glpk@gmx.de
wrote:
...
As long as device-trees loaded by an EFI application like GRUB do not fully describe boards and miss on copying memory reservations, boot-hartid and everything else needed for successful booting the requirement not to fix-up device trees is not plausible to me.
This is a fair point. The point I made was about firmware relying on changes made by the kernel's EFI stub between entry and the point where it calls ExitBootServices().
Can we create a flow-diagram of who needs to modify what? Here's a first attempt:
Scenario 1: Firmware provides DTB
- Firmware loads stock DTB into EfiACPIReclaimMemory
- Firmware updates DTB /chosen and /memory with current config
---- DTB becomes immutable to firmware 3) Firmware calls EFI Application or OS Loader 4) ExitBootServices() 5) OS Consumes firmware-provided DTB
Scenario 2: EFI Application provides replacement DTB and handles fixups
- Firmware loads stock DTB into EfiACPIReclaimMemory
- Firmware updates DTB /chosen and /memory with current config
---- DTB becomes immutable to firmware 3) Firmware calls EFI Application which provides replacement DTB a) Application loads replacement DTB into EfiACPIReclaimMemory b) Application updates replacement DTB with /chosen & /memory from default DTB c) Application calls OS Loader 5) ExitBootServices() 6) OS Consumes replacement DTB
Scenario 3: EFI Application provides replacement DTB; but depends on firmware to provide fixups
- Firmware loads stock DTB into EfiACPIReclaimMemory
- Firmware calls EFI Application which provides replacement DTB a) Application loads replacement DTB into EfiACPIReclaimMemory b) Application calls OS Loader
- ExitBootServices() a) Firmware updates current DTB /chosen and /memory with current config
---- DTB becomes immutable to firmware 4) OS Consumes replacement DTB
These are obviously trivial descriptions, but I'd like to flush out what is actually required. There is going to be tension here between what OS vendors need, and what vertically integrated embedded users will need.
This flow is the target of a set of work items in the DTE project. I
wouldn't describe the result of work before we actually complete the work ;-) If the goal is to give an overview of what is currently happening with U-Boot, I would use what Heinrich described earlier in the thread. BTW,
g.
On Tue, 5 May 2020 at 17:48, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 05.05.20 15:51, Grant Likely wrote:
On 05/05/2020 08:30, Andrei Warkentin wrote:
*From:* Ard Biesheuvel ard.biesheuvel@arm.com
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:
Got it. Agreed.
Needs to be worded carefully since it is a valid use case to replace the DTB entirely before ExitBootServices(). It needs to be clear that firmware is not required to consume the DTB if it gets replaced.
How about:
+If an OS Loader or other EFI application loads a new DTB that replaces +the DTB provided by firmware and registers it into the EFI_SYSTEM_TABLE, then firmware must not parse, modify, or +otherwise use the data contained in the new DTB. +In this scenario, the application becomes wholly responsible for the DTB data.
U-Boot currently makes at least the following changes to the device trees before registering them in the system table:
fdt_root(): Set property 'serial' from environment variable 'serial#'
fdt_chosen(): Set property chosen/bootargs Set property chosen/linux,stdout-path
arch_fixup_fdt() [RISC-V]: Set property chosen/boot-hartid
fdt_fixup_ethernet(): Set property mac-address and local-mac-address
board specific fixups like
- setting property fsl,sc_rsrc_id on imx8
- disabling of nodes soc/can, soc/gpu depending on board configuration
on STM32MP
- enable GPU nodes on Nvidia Tegra (nvidia,gk20a, nvidia,gk20a)
optee_copy_fdt_nodes():
- transfer of optee nodes to new fdt
I start to think that, ultimately, there should be tfa_copy_fdt_nodes() equivalent so that the release cycle between TFA and other components are fully independent. The current behavior is U-Boot injects PSCI nodes (psci_fdt@arch/arm/lib/psci-dt.c) based on its assumption of the underlying TFA. As the release cycle has not be very rapid, this has not been a big issue. But all signs are showing that the speed of change will be faster on the TFA side, and not just for S-EL2.
efi_carve_out_dt_rsv():
- create reserved memory nodes
GRUB is one software that may register a new devicetree as configuration table via the 'devicetree' tree command. Currently none of the fixups above will be applied. This may result in boot failure.
A software like GRUB is not meant to have any device specific knowledge. So it cannot possibly know which fix-ups are needed.
I stumbled over this problem when I booted devices via iSCSI. As up to now Linux device trees are not interchangeable between kernel versions I would have loved to have kernel, initrd, and device tree on the iSCSI drive and managed by GRUB. This would only work out if the device specific fix-ups would be applied after GRUB loads a device-tree. Cf. https://savannah.gnu.org/bugs/?52939.
As long as device-trees loaded by an EFI application like GRUB do not fully describe boards and miss on copying memory reservations, boot-hartid and everything else needed for successful booting the requirement not to fix-up device trees is not plausible to me.
Cannot agree more. Isn't it true that systemd-boot has something similar?
Boot orchestration is one job very different from handing over a trustable platform description (=hw + firmware services such PSCI, SPCI...).
Best regards
Heinrich
g. 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. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
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.
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.
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
boot-architecture@lists.linaro.org
-
Andrei Warkentin -
Ard Biesheuvel -
Ard Biesheuvel -
Daniel Thompson -
François Ozog -
Grant Likely -
Heinrich Schuchardt