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_eberman@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_eberman@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_eberman@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].
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 ?