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. > 2. It is already widely used in U-Boot There are more bootloaders than U-Boot :) 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. > 3. It is the foundation for FIT (Flat Image Tree) which is widely > supported in bootloaders I don't think board-id isn't incompatible with FIT, although additions to the spec are needed to allow for the properties. > 4. Linux now has a 'make fit' target which uses this information, > allowing bootloaders to automatically boot a Linux kernel with the > correct dtb. > 5. It allows vendors to decide their own naming of the different > boards, without needing anything to change in U-Boot or LInux board-id has the same benefit, I think. I have a v3 of board-id based more on my slides which I can send out tomorrow. I've included the selection algorithm and some tests to demo how it could work. > > The problems mentioned with compatible strings have already been > solved, so far as I can tell. In all of arm64 / Linux I believe there > is only 1 board with a problem (or is it 2?) where the compatible > string is not unique. I'm not sure they are all solved yet. depthcharge and u-boot have different algorithms to match the DTBs. Compatible strings and DT fixups are an ideal solution, but I think there are corner cases which need to be considered. Can Chromebooks switch to u-boot's best match algorithm? > The parsing code we are talking about is not large...about 100 lines > of code which seems much easier than creating an entirely new way of > doing things. The slides in [1] are certainly an interesting idea, but > I struggle to see the need. For what its worth, the board-id matching can also be done in <100 lines of code in the bootloader and should also be simple for firmware to implement. > Adding things like the display panel to the top-level compatible > string seems unnecessary. Can you not add nodes for each one and > select the correct driver at runtime? Or, since presumably the > bootloader knows which display is being used, it can do any necessary > fix-ups? This is widely done in U-Boot. Display panel may not be the greatest example because it's mostly a leaf node. Different PMIC might be a better example since there are references to regulators throughout the DT which would need fixups. > > The one area which I think could be improved is dealing with minor > board variants, sometimes called SKUs. There is a ChromiumOS proposal > on this which has been used for some years, though [5] Depthcharge is ChromiumOS specific and I don't know how to make it more generic. Really, board-id is just QuIC's msm-id made a generic. I'm not glued to board-id, but I think it's a clean solution for Jonathan's original problem statement. I'd like to help review/improve a compatible string-based matching algorithm; hope my feedback on the u-boot approach can be considered. Thanks, Elliot > [5] https://www.kernel.org/doc/html/v6.2/arm/google/chromebook-boot-flow.html > > [1]: > > https://static.sched.com/hosted_files/eoss24/11/Shipping%20Multiple%20Devicetrees%20-%20EOSS%202024.pdf > > [2]: https://www.youtube.com/watch?v=k-oxkdpChGk > > [3]: > > https://lore.kernel.org/all/1705749649-4708-1-git-send-email-quic_amria...@quicinc.com/ > > [4]: > > https://lore.kernel.org/all/1710418312-6559-1-git-send-email-quic_amria...@quicinc.com/ _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
