On Wed, 6 May 2020 at 20:00, Grant Likely grant.likely@arm.com 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.
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.