On Tue, 5 May 2020 at 17:48, Heinrich Schuchardt <[email protected]> wrote:
> On 05.05.20 15:51, Grant Likely wrote: > > > > > > On 05/05/2020 08:30, Andrei Warkentin wrote: > >> *From:* Ard Biesheuvel <[email protected]> > >> > >>> > 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 > > [email protected] > > https://lists.linaro.org/mailman/listinfo/boot-architecture > > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 [email protected] | Skype: ffozog _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
