On 06/05/2020 17:57, Ard Biesheuvel wrote:
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?
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.
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.
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
