On Thu, 7 May 2020 at 16:50, Daniel Thompson <[email protected]> wrote:
> 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. > > Isn't it more accurate to say that grub is part of Linux distros targeting servers and desktops. In embedded, I am not sure grub is in the picture all the time. In your view, what is the role of grub in the DT lifecycle? I see it as the "authoritative entity" to deal with chosen node (bootargs, cma) and speical reverved-memory for kexec... > Daniel. > -- 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
