On Wed, 6 May 2020 at 20:00, Grant Likely <[email protected]> wrote: > > > > 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 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. >
I think this is just a terminology clash: in the embedded world, the DT is read from a file (which may be shipped separately), and so a 'fixup' step is required to put actual runtime data into it. In the EDK/ACPI/SBBR world, 'fixing up' the firmware tables is the same as generating them in the first place, since the input is not taken from a file, and not necessarily in true DT format at all: Overdrive in edk2-platforms is a good example, it has a .dtb builtin in with lots of pieces missing, and these are all generated and inserted on the fly. On SynQuacer, I do something similar, but also apply overlays depending on what is plugged into the 96boards LS connector (in theory - only Secure96 is supported at the moment) So we are basically talking about the same thing, and whatever the firmware needs to at runtime to produce a correct and accurate DT needs to be completed before it calls the next boot stage. _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
