On Thu, Jun 06, 2024 at 06:03:51PM +0200, 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. > > Systemd-boot also provides device-trees and uses the EFI_DT_FIXUP_PROTOCOL.
I'm sorry but that seems like a distinction without a difference. Simon said "/bootloader" and GRUB/systemd-boot are very much "bootloader". And anyhow, what are both of those cases going to be doing with a UKI, which is much more like what dealing with a FIT is, with FIT having already defined "find the right device tree" whereas I do not know if UKI has moved past "implementation dependent" or so there. -- Tom _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
