On 05.05.20 15:51, Grant Likely wrote: > > > On 05/05/2020 08:30, Andrei Warkentin wrote: >> *From:* Ard Biesheuvel <ard.biesheu...@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 _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
