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 2. It is already widely used in U-Boot 3. It is the foundation for FIT (Flat Image Tree) which is widely supported in bootloaders 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 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. 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. 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. 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] Regards, Simon [5] https://www.kernel.org/doc/html/v6.2/arm/googl.e/chromebook-boot-flow.html > > Thanks, > Elliot > > [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 _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-le...@lists.linaro.org
