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? > > Systemd-boot also provides device-trees and uses the EFI_DT_FIXUP_PROTOCOL. OK. Regards, SImon _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
