Andrew Davis <a...@ti.com> schrieb am Do., 6. Juni 2024, 18:39: > 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 current solution is as follows: On the installer image put all device-trees of the installer kernel into directory /dtb of the ESP. U-Boot installs the device-tree matching the board as EFI configuration table. After booting the compatible and model properties are available in /proc/device-tree Now update-grub can write the correct devicetree commands for each installed kernel based on these properties into grub.cfg. > 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. > That ID system seems to add complexity and is not needed for the solution described above. > 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. > Have a look at all.db in Debian's package flash-kernel. It maps the model property to the device-tree file name. A similar lookup table could be integrated into grub.cfg if grub could write a property of the installed device-tree into a variable. Best regards Heinrich > 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? > > Andrew > > > Systemd-boot also provides device-trees and uses the > EFI_DT_FIXUP_PROTOCOL. > > > > Best regards > > > > Heinrich > > _______________________________________________ > > boot-architecture mailing list -- boot-architecture@lists.linaro.org > > To unsubscribe send an email to boot-architecture-le...@lists.linaro.org > _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
