Hi Dough,
thanks for your mail!
Let me just see if I understand correctly what you're trying to do (and apparently actively doing in production):
On Tue, Nov 18, 2025 at 11:43 PM Doug Anderson dianders@chromium.org wrote:
We would like an officially accepted scheme that lets us more efficiently ship compiled device trees for a handful of related products by breaking the device trees up into a common "base" device tree and then applying "overlay" device trees atop the base to make a full and complete device tree.
(...)
In Android, we do a pretty good job of solving the stated problem using device tree overlays. We describe the SoCs in "dts" files and compile them into "dtb"s. We describe boards in "dtso" files and compile them into "dtbo" files. A bootloader can handle identifying the correct base and overlay (the scheme for doing this is a separate but related topic) and applying the overlay atop the base "dtb". This solution is fully implemented downstream for Android phones and is well documented [2].
So in the kernel we have several arch/*/boot/dts/vendor/ folders where they have:
soc.dtsi included by board.dtsi included by system.dts and the top system.dts is all that get compiled.
So what you say is that you do the same thing but at runtime?
Can you just describe why this is done like this with overlays?
I can only guess that you have one bootloader that needs to compose device trees to many systems and the bootloader only discovers the system it is running on and its constraints at runtime, so shipping the static system.dtb as many people do is not an option for you?
And the reason the bootloader doesn't already know what it is running on and doesn't just pass that one device tree or is just prepared with that one device tree has something to do with manufacturing or so?
Sorry it just evades me.
Probably becayse even U-Boot these days use the provided device tree dtb, for the system targeted, to initialize itself. I suppose your bootloader is generic enough to avoid that chicken-and-egg problem, right?
I guess if I had this problem:
soc.dtsi board-a.dtsi board-b.dtsi system-board-a-v1.dts system-board-a-v2.dts system-board-b-v1.dts
etc having to be combined at runtime, in a bootloader, I would consider shipping exactly these files in a memory-based filesystem in my bootloader, and bake a DTS compiler into my bootloader so it can just build a device tree for what it detects.
But I guess you didn't want to hear that :D
Anyway, please describe how you ended up in this situation, I'm trying to understand this.
It is quite clear that device tree overlays were intended for say plug-n-play additions and minor fragments to be added to a basically complete device tree, what you are doing was probably not how it was intended. (Or let's see if someone proves me wrong on that.)
Yours, Linus Walleij