On Wed, May 8, 2024 at 7:19 PM Elliot Berman quic_eberman@quicinc.com wrote:
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.
I don't think there is any way the OS (or OS loader) would be able handle these properties and the logic to parse them. It all looks to be platform specific. This could only work if the OS says to the firmware "here's the 1000 DTB files, which one should I use? That's quite different from the current proposals of how this would work.
Rob