Message-ID: <CAD++jLkuRQKoiEN928GtAj7wUts5PxH905bLp6ZhKsJ3NnenEA@mail.gmail.com>
Date: Tue, 2 Dec 2025 00:52:25 +0100
From: Linus Walleij <linusw@...nel.org>
To: Doug Anderson <dianders@...omium.org>
Cc: devicetree-spec@...r.kernel.org, boot-architecture@...ts.linaro.org, 
	Chen-Yu Tsai <wenst@...omium.org>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk@...nel.org>, 
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, 
	Linux ARM <linux-arm-kernel@...ts.infradead.org>, 
	William McVicker <willmcvicker@...gle.com>, Julius Werner <jwerner@...omium.org>, 
	Conor Dooley <conor+dt@...nel.org>, Peter Griffin <peter.griffin@...aro.org>, 
	Tudor Ambarus <tudor.ambarus@...aro.org>, André Draszik <andre.draszik@...aro.org>
Subject: Re: Proposal: Officially allow "incomplete" trees as a base

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@...omium.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

Powered by blists - more mailing lists