Hi,
On Tue, Dec 2, 2025 at 2:07 AM Russell King (Oracle) linux@armlinux.org.uk wrote:
Having worked on the SolidRun i.MX6 platforms, I agree with this. Within these platforms there are:
SoC SOM Platform imx6dl pre-v1.5 cubox imx6q v1.5 hummingboard v1.5 + emmc hummingboard2
On top of these, I have specific "user" extensions for hardware that I've connected - e.g.
- the NoIR RPi camera needs DT modification.
- for monitoring a mechanical church clock, a "gps" variant that allowed PPS to be used with a GPIO pin, and a "capture" variant that configured the hardware to allow precise event stamping.
- 1-wire, for ds18b20 temperature sensors.
Without the user extensions, this adds up to 18 DTB files: arch/arm/boot/dts/nxp/imx/imx6dl-cubox-i-emmc-som-v15.dts arch/arm/boot/dts/nxp/imx/imx6dl-cubox-i-som-v15.dts arch/arm/boot/dts/nxp/imx/imx6dl-cubox-i.dts arch/arm/boot/dts/nxp/imx/imx6dl-hummingboard-emmc-som-v15.dts arch/arm/boot/dts/nxp/imx/imx6dl-hummingboard-som-v15.dts arch/arm/boot/dts/nxp/imx/imx6dl-hummingboard.dts arch/arm/boot/dts/nxp/imx/imx6dl-hummingboard2-emmc-som-v15.dts arch/arm/boot/dts/nxp/imx/imx6dl-hummingboard2-som-v15.dts arch/arm/boot/dts/nxp/imx/imx6dl-hummingboard2.dts arch/arm/boot/dts/nxp/imx/imx6q-cubox-i-emmc-som-v15.dts arch/arm/boot/dts/nxp/imx/imx6q-cubox-i-som-v15.dts arch/arm/boot/dts/nxp/imx/imx6q-cubox-i.dts arch/arm/boot/dts/nxp/imx/imx6q-hummingboard-emmc-som-v15.dts arch/arm/boot/dts/nxp/imx/imx6q-hummingboard-som-v15.dts arch/arm/boot/dts/nxp/imx/imx6q-hummingboard.dts arch/arm/boot/dts/nxp/imx/imx6q-hummingboard2-emmc-som-v15.dts arch/arm/boot/dts/nxp/imx/imx6q-hummingboard2-som-v15.dts arch/arm/boot/dts/nxp/imx/imx6q-hummingboard2.dts
basically, every combination needs to be enumerated. So, having two SoC dt files, three for the SOM, and three for the platform that the boot loader combines would significantly cut this down - to 8.
However, it isn't that simple. For example, when the Hummingboard2 is used with the iMX6Q SoC, there's a SATA device present in the SoC level that needs Hummingboard2 specific properties to tune the signal waveform. However, iMX6DL doesn't have this SATA device in silicon, so the node doesn't exist in the base SoC DT file. The situation is the same for Hummingboard, but the tuning parameters, being board specific, are different.
This means is that there are DT properties that are dependent on the SoC DT component and the platform DT component which do not fit with splitting the DT files into their individual "component" levels.
Wow, it sounds complicated! Yeah, in your specific case where you need specific tuning parameters for each combination of SoC and SoM the easiest might be to just keep things separate as you have it. If you're looking to optimize the total size of the distributed device trees instead of the total number of files, overlays still could possibly help you out, though. I could imagine a case where you first apply the "coarse" overlays (SoC, SoM, board) and then you look for finer-grained overlays that are applied atop that. You'd still need a bunch of these "finer grained" overlays (one for each unique combination) but each one would be tiny.
To make it concrete, I'd imagine: - imx6q - base dtb - som1.5 - overlay - hummingboard2 - overlay - hummingboard2-with-imx6q - overlay
...and the "hummingboard2-with-imx6q" could _just_ have the SATA tunings in it. I think that would be possible, right?
The other issue would be the /model property - for example:
model = "SolidRun HummingBoard2 Solo/DualLite"; model = "SolidRun HummingBoard2 Solo/DualLite (1.5som+emmc)"; model = "SolidRun HummingBoard2 Solo/DualLite (1.5som)"; model = "SolidRun HummingBoard Solo/DualLite"; model = "SolidRun HummingBoard2 Dual/Quad"; model = "SolidRun Cubox-i Solo/DualLite";as a set of examples. I don't see a clear way to generate these from a fragmented scheme. There's a similar problem with the board-level compatible:
compatible = "solidrun,cubox-i/dl", "fsl,imx6dl"; compatible = "solidrun,hummingboard2/dl", "fsl,imx6dl"; compatible = "solidrun,hummingboard/dl", "fsl,imx6dl"; compatible = "solidrun,hummingboard2/q", "fsl,imx6q";These don't include the SoM information.
Right. This is the question many of the messages in this thread have been struggling with.
Things become a bit easier if you simply don't expect the top-level "compatible" to describe everything. ...but in your case it sounds like things are _very_ dynamic (everything can be combined with everything), so if we want to solve your problem it seems like we truly do need a way to "combine" compatible strings.
As per one of my earlier replies, it's possible we'll postpone this and start with simpler cases where we don't need to do any top-level compatible/model munging, but it's good to know that there's a use case that really needs it.
Maybe what would work would be a high-level DT file that contains paths to the lower levels that need to be combined, along with properties that need to be merged. E.g.
/ { model = "SolidRun HummingBoard2 Dual/Quad"; compatible = "solidrun,hummingboard2/q", "fsl,imx6q";
dts-components { compatible = "boot/dt"; component@1 { compatible = "dt"; path = "imx6q.dtbo"; }; component@2 { compatible = "dt"; path = "imx6qdl-sr-som-v1.5.dtbo"; }; component@3 { compatible = "dt"; path = "imx6qdl-hummingboard2.dtbo"; }; component@4 { compatible = "dt"; path = "imx6ql-hummingboard2-emmc.dtbo"; }; }; soc { sata@2200000 { .. sata tuning properties .. }; };};
Or something similar.
Yeah, the question of how to know which files to combine is an important and related point, but I've been trying to keep it separate so we don't have to solve every complex problem at once. This is, I believe, also the subject of one of Chen-Yu's talks at Plumbers.
However, this would mean we would still need the 18 or so top level DT files, but also each component as well, which will increase the number of files we're having to manage on a target platform - so I'm wondering whether it's worth it.
I don't think we'll be able to get away from this problem: it's likely that there will continue to be properties that are specific across several "levels" of a split DT setup, and apart from something like the above, I don't really see a way to handle them.
I also don't see a sensible way without something like the above for a boot loader to know the filenames of each of the components for a platform - and it would need to be told the order to glue those components together.
Right, this kind of thing would be a judgement call. How you'd want to organize things / use overlays would be up to you.
I would have liked to use overlays for these platforms, but ISTR they either weren't supported at the time, or frowned upon, and even so I can only see them working for the simplest of cases due to the issue I mention above.
The fact that you have similar needs at least makes me continue to be confident that this is an important problem to try to solve.
-Doug