On Thu, Jun 06, 2024 at 11:39:06AM -0500, Andrew Davis wrote: > On 6/6/24 11:03 AM, Heinrich Schuchardt wrote: > > On 06.06.24 17:57, Simon Glass wrote: > > > Hi Elliot, > > > > > > On Wed, 5 Jun 2024 at 11:31, Elliot Berman <quic_eber...@quicinc.com> > > > wrote: > > > > > > > > Hi Simon, > > > > > > > > On Thu, May 30, 2024 at 03:30:39PM -0600, Simon Glass wrote: > > > > > On Wed, 29 May 2024 at 11:02, Elliot Berman > > > > > <quic_eber...@quicinc.com> wrote: > > > > > > On Wed, May 29, 2024 at 10:18:43AM -0600, Simon Glass wrote: > > > > > > > On Mon, 20 May 2024 at 18:27, Elliot Berman > > > > > > > <quic_eber...@quicinc.com> wrote: > > > > > > > > On Sun, May 19, 2024 at 12:22:47PM -0600, Simon Glass wrote: > > > > > > > > > I believe the compatible string is still the best approach. > > > > > > > > > It has a > > > > > > > > > number of benefits: > > > > > > > > > > > > > > > > > > 1. It is in fact the purpose of compatible strings to match > > > > > > > > > hardware > > > > > > > > > with a driver > > > > > > > > > > > > > > > > Agreed. Compatible string matching works great for the rest of > > > > > > > > the > > > > > > > > device tree, but I think matching the root node compatible has > > > > > > > > different > > > > > > > > challenges that the rest of DT doesn't have. > > > > > > > > > > > > > > > > I'm open to use compatible strings, but we (EBBR) should > > > > > > > > describe how > > > > > > > > OSes should pick the DTB based on the compatible strings given > > > > > > > > by > > > > > > > > firmware so that there is consistency. > > > > > > > > > > > > > > Yes, agreed. Do you have a proposal for this? > > > > > > > > > > > > > > > > > > > AMD did some work based off regex strings, maybe this could be > > > > > > expanded > > > > > > and made part of the EBBR and DT spec [1]. > > > > > > > > > > > > [1]: https://resources.linaro.org/en/resource/q7U3Rr7m3ZbZmXzYK7A9u3 > > > > > > > > > > OK, thanks. Note that I consider this a vendor-specific addition to > > > > > U-Boot, similar to the 'hat' approach used by Beaglebone. The actual > > > > > mechanism is using overlays, from what I can tell, with the DT > > > > > modified in Linux by applying overlays. Is that right? If so, it > > > > > doesn't seem relevant to what you propose here. > > > > > > > > > > I think you should take a look at how far you can get with just > > > > > compatible strings, so we can see what is actually missing. > > > > > > > > > > > > > The talk and slides I gave at EOSS covered the challenges we had in > > > > implementing a typical compatible string-based mechanism for DT > > > > selection. > > > > > > I read through the slides a few weeks back and just looked again. I > > > cannot quite see why the existing mechanism doesn't solve your > > > problem. > > > > > > The example of the hugely long string seems excessive to me, in that > > > you should really be using the DT to describe some of that hardware, > > > rather than putting it in the top-level compatible. > > > > > > > > > > > [snip] > > > > > > > > > > > > > > > > The scenario I like to think about is where OS wants to run on many > > > > > > boards/platforms and wants to override DTB for only some of those > > > > > > boards/platforms. Perhaps the firmware-provided DTB on most of the > > > > > > boards is good for the OS, but not good enough for couple boards > > > > > > and the > > > > > > OS provides its own. Firmware has to provide enough information > > > > > > that OS > > > > > > can pick the DTB and also OS need to be able to detect that it > > > > > > doesn't > > > > > > have a DTB for the platform and should fallback to the > > > > > > firmware-provided > > > > > > DT. > > > > > > > > > > > > Maybe the scenario I think about isn't valid -- in that case, we > > > > > > should > > > > > > make sure that the spec says something about how "if OS wants to > > > > > > provide > > > > > > own DTB, it must have DTBs for all the boards the OS could run on". > > > > > > > > > > > > > > > > I don't know of an OS that can find its own DTB. Which particular OS > > > > > are you thinking of? > > > > > > > > Aren't most devices doing that today? Relatively few devices are using > > > > firmware-provided DTs. > > > > > > Oh I mean that the DT is included with the OS, but it is the > > > firmware/bootloader that actually loads it and presents it to the OS. > > > At least that is how supposed to work (if the OS wants its own). Most > > > boards and distros I am aware of seem to do this. > > > > Ubuntu does not. It uses GRUBs devicetree command to load the device-trees > > and U-Boot's EFI_DT_FIXUP_PROTOCOL to add the necessary fixups. > > > > The thing is the "devicetree" command still needs the DTB name > hard-coded which makes the OS image *not* perfectly generic (and > building a menu entry for each possible board is a bit nonsensical). > > The top level solution proposed here *was* to pass that name in from > firmware instead (or find the top level compatible string in the > firmware provided DT and then search for an OS provided DT with the > same compatible). But Elliot's ID system seems like it could allow > for an even better way. > > What we would need extra is to have a file similar to the modalias > file for modules, but for DT. A lookup table generated from DT IDs > that maps from a provided ID to a set (as in a base DT plus overlays) > of DT files to load for the given ID. > > Firmware provides a base DT with enough info to run the bootloader, > then the bootloader uses the ID to quickly find and load the > OS provided DT if available (falling back to just passing the simple > firmware provided DT on to the OS if needed). > > Is that a fair summary?
This, frankly, sounds like a very round-about way of constructing the top-level compatible, again, for a platform and then loading the correct filename. Why not just a modalias type file that says compatible,X is file-y.dtb ? -- Tom _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
