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