On Wed, 6 May 2020 at 18:41, Heinrich Schuchardt <xypron.g...@gmx.de> wrote: > > On 06.05.20 17:14, Ard Biesheuvel wrote: > > On 5/6/20 5:01 PM, Grant Likely wrote: ... > >> 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? >
Grant and you keep mentioning fixups like it is common today for the system firmware to go and change the DTB at random times after invoking the next stage. What exactly do you have in mind here, and why do you think it works correctly today? > Should GRUB command be marked as deprecated? - CC Daniel > https://www.gnu.org/software/grub/manual/grub/grub.html#devicetree > I don't think so. There are valid use cases for it, and the system firmware should not be poking around in the DTB anyway after it has launched the next stage loader. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
