On Wed, May 06, 2020 at 06:59:54PM +0100, Grant Likely wrote:
On 06/05/2020 17:57, Ard Biesheuvel wrote:
On Wed, 6 May 2020 at 18:41, Heinrich Schuchardt xypron.glpk@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.
Are we concerned to ensure EBBR boot flow supports what is needed (e.g. all the required features are in the spec) or simply that EBBR does not contradict an implementation wishing to do this (no requirement prevents an implementation from doing this)?
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.
Same here.
We should consider bootefi in a similar light to bootm. It is *obviously* crazy for any resident component of u-boot to start messing with the DTB after we call bootm. It does not become any less crazy just because we run in boot services... u-boot does not understand what changes the OS bootloader might with to make to the DTB or why and cannot safely alter it.
Daniel.
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