On Wed, May 01, 2024 at 09:18:01PM +0000, Humphreys, Jonathan wrote: > The firmware would pass the device tree filename/id to the OS loader, instead > of > the DTB itself. The OS loader would determine the location of the matching > DTBs > based on the chosen OS to boot, load the matching DTB from that location, and > pass to the kernel. <hoisted the footnote> > [1] Rather than using the device tree source filename, to have more > flexibility, > one can conceive an ID or compatible string that the OS could then scan the > DTBs > to find a match.
I say that the firmware already passes on such an identifier, in the form of the compatible string in the root node. I don't think any standard is explicit on the level of detail root node compatible strings should provide but it's certainly idiomatic for these strings to be very detailed already. > Considerations: > - often a DTB requires fixups. The EFI_DT_FIXUP_PROTOCOL could be utilized. > - device tree overlays could be indicated with a scheme using the device tree > ID > passed to the OS loader > - authenticating the DTB would be the responsibility of the OS distribution > and > handled in the same way as the kernel itself is authenticated. The OS is the > entity responsible for signing the DTB, as it should be. > > This proposal should be in addition to supporting the standard way of passing > in > a firmware-provided DT, in cases where the OS doesn't provide or have a need > to > provide a matching DT. The pleasing thing about using the devicetree compatible string is that not much else needs to change. 1. An OS can continue to assume that DT is a firmware problem and expect the firmware to be updated when the board vendor wants it to support new features or fix bugs. 2. An OS that wishes to maintain a collection of DTs can run an EFI application to examine the compatible strings to select and install an alternative DT. One thing I'm unclear about is whether there are any generic operating systems that are willing to ship a collection of DTs and to implement the changes to their bootflow to adopt them automatically (rather than through post-install tuning). I think that is important and is needed to resolve the [long standing EFI_DT_FIXUP_PROTOCOL ticket][1]. IMHO vendor-specific operating systems don't really count here since, if they want to, they can already use the fixup protocol to do exactly the above without any changes to the EBBR spec. Daniel. [1]: https://github.com/ARM-software/ebbr/issues/68 _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
