Hi Heinrich, On Mon, 10 Jun 2024 at 08:13, Heinrich Schuchardt <heinrich.schucha...@canonical.com> wrote: > > On 10.06.24 15:52, Simon Glass wrote: > > Hi Heinrich, > > > > On Thu, 6 Jun 2024 at 10:03, Heinrich Schuchardt > > <heinrich.schucha...@canonical.com> 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. > > > > I was considering grub to be a bootloader, though. The OS doesn't find > > the file itself, right? > > The Linux kernel does not scan for device-trees. It requires that the > correct device-tree or ACPI tables are installed as EFI configuration > table. This can be done by firmware or by the bootloader provided by the OS.
Right, so I believe we should use the best-match mechanism in U-Boot to locate the correct DT and provide it. Is that possible? Regards, Simon _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
