Hi Elliot, 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: > > Hi Elliot, > > > > 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: > > > > Hi Elliot, > > > > > > > > On Wed, 8 May 2024 at 18:28, Elliot Berman <quic_eber...@quicinc.com> > > > > wrote: > > > > > > > > > > (resending now that I can post to boot-architecture) > > > > > > > > > > On Thu, May 02, 2024 at 09:00:47AM -0500, Rob Herring wrote: > > > > > > On Wed, May 1, 2024 at 4:18 PM Humphreys, Jonathan > > > > > > <j-humphreys(a)ti.com> wrote: > > > > > > > [1] Rather than using the device tree source filename, to have > > > > > > > more flexibility, > > > > > > > one can conceive an ID or compatible string that the OS could > > > > > > > then scan the DTBs > > > > > > > to find a match. > > > > > > > > > > > > I agree with Daniel that we should use the root node compatible for > > > > > > this. We discussed this a while back on this list (or u-boot?). To > > > > > > summarize, both using the filename or root node compatible were > > > > > > proposed. Several folks (myself included) don't like making the > > > > > > filename an ABI. However, there are some cases where the filename is > > > > > > more unique than the root node compatible. We should fix those root > > > > > > node compatibles in that case IMO. > > > > > > > > > > I think firmware-provided compatible string can cause headaches for > > > > > both > > > > > firmware and OS developers. I gave a talk about this at EOSS [1,2] and > > > > > we've been posting some proposals [3,4] to introduce a board-id, which > > > > > allows DTBs to have varying degrees of precision about describing what > > > > > hardware they are applicable to. > > > > > > > > > > Compatible strings should be a mapping of some identifier > > > > > registers/storage into a string. Today, bootloader has to figure out > > > > > that mapping and I understood Jon's proposal as wanting to get > > > > > firmware > > > > > to provide the compatible string. However, the compatible string for a > > > > > DTB could need to describe only a subset of those identifiers > > > > > (compatible string) to get a DTB that works. This would be especially > > > > > true for DT overlays, although there are other real and hypothetical > > > > > situations where a DTB shouldn't/can't describe the complete set of > > > > > identifiers. Firmware either needs to provide every possible > > > > > combination > > > > > of compatible string or knowledge needs to be baked into the OS about > > > > > interpreting the compatible string. In simple terms, the proposal is > > > > > to > > > > > split out the identifers that are baked into the compatible string > > > > > into > > > > > separate "board-id" properties. > > > > > > > > Thank you for the info and link. > > > > > > > > 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. > > > > > > > > 2. It is already widely used in U-Boot > > > > > > There are more bootloaders than U-Boot :) > > > > U-Boot is the main bootloader on embedded ARM devices. It is where > > most development has taken place over many years. Importantly, it has > > produced the FIT standard [6]. > > > > > > > > I think U-boot's best fit matching algorithm has a flaw: > > > > > > Root compatible strings (almost?) always describe the specific board > > > compatible string as well as a compatible or two for the SoC family or > > > other attributes. > > > > > > Example picked at random: > > > arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-dahlia.dts: > > > "toradex,verdin-am62-wifi-dahlia", "toradex,verdin-am62-wifi", > > > "toradex,verdin-am62", "ti,am625" > > > > > > arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-dev.dts: > > > "toradex,verdin-am62-wifi-dev", "toradex,verdin-am62-wifi", > > > "toradex,verdin-am62", "ti,am625" > > > > > > The DT spec says that compatible string matching should be done like > > > this: > > > > > > Example: > > > compatible = "fsl,mpc8641", "ns16550"; > > > In this example, an operating system would first try to locate a > > > device driver that supported fsl,mpc8641. If a driver was not found, > > > it would then try to locate a driver that supported the more general > > > ns16550 device type. > > > > > > There is a problem right away with compatible string matching: what if > > > OS's DTB package doesn't contain the particular board but *does* contain > > > another board with that SoC? How do you ensure the other board isn't > > > picked based off the SoC compatible? This is quite a different problem > > > from compatible strings in the rest of the devicetree. If you fall back > > > to a different compatible in the case of a device node, the device > > > should still generally work. If you fall back in the root node case, you > > > could be loading wrong DTB and have random system instability. > > > > > > My interpretation of U-boot's best match algorithm could pick a > > > configuration that matches the SoC compatible only. IMO, this would lead > > > to undefined behavior as no one tests what happens when you boot board A > > > DTB on board B, even if they have the same SoC. > > > > 'U-Boot', BTW > > > > The U-Boot best-fit mechanism has been used for years over a huge > > variety of boards and manufacturers. It seems to work very well. > > > > Are you worried about the case where there is no DT for the board in > > question? In that case, the best match will indeed not be ideal. The > > solution is to provide a suitable DT. > > > > 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? At least with U-Boot, even when the DTB is packaged with the OS, it is located and provided to the OS by the firmware, just as the OS is. Here is my current proposal: https://github.com/open-source-firmware/flat-image-tree/pull/10/commits Regards, Simon _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
