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