Le mer. 6 mai 2020 à 20:00, Grant Likely <[email protected]> a écrit :
> > > On 06/05/2020 17:57, Ard Biesheuvel wrote: > > On Wed, 6 May 2020 at 18:41, Heinrich Schuchardt <[email protected]> > 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? > > In the non-EFI boot flow, it is common for U-Boot to load the DTB, and > then updating it in the bootm command to insert the kernel command line > or in another command (e.g. applying overlays). The concern I've heard > is that the EBBR boot flow won't support what is needed in the embedded > space. I have used: Load dTB at address Apply manual fix ups (reserve memory) with fdt U-Boot commands Use the updated dTB with bootefi command Bootefi makes a copy of the passed dTB (regardless if it was modified or not ) Applies the fix ups Heinrich described Install the copied dTB into the efi config table and then invoke the efi app. Are there other things needed for EBBR you had in mind ? > > > I want to make sure we're not ruling out behaviour that is required > because it hasn't been discussed in this context. I suspect the answer > will simply be exactly what you've already described: The DTB becomes > static before any EFI applications are executed. Any fixups after that > point are the responsibility of the boot flow. I want to be sure that > works for the ST, NXP, TI, etc. > > g. > > > > >> 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. > > > -- 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
