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 _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
