On Fri, Nov 14, 2025 at 3:26 AM Krzysztof Kozlowski [off-list ref] wrote:

On Thu, Nov 13, 2025 at 10:04:53AM -0800, Doug Anderson wrote:

quoted

Hi,


On Thu, Nov 13, 2025 at 9:43 AM Krzysztof Kozlowski [off-list ref] wrote:

quoted

quoted

quoted

quoted

Yes, the complexity of just "hooking up" the components on an SoC is
an order of magnitude harder than a Raspberry Pi, but it's still just
hooking it up to external components. In both cases, we are modeling
the core "brains" (the part that contains the processor) as the DTB
and everything else just "hooks up" to interfaces.

You mix the topics, so I don't follow. I speak here about bindings - you
cannot have the that compatible alone, because it is incomplete, just
like compatible for "transistor" is not correct in that context. You
speak what could or could be DTB, different topic.

A "SoC" is "complete". It has a processor that can run instructions.

Then show me executing any piece of software, which is the consumer of
the bindings, and runs on the SoC without the rest of the hardware system.

Show me something that runs on a Raspberry Pi (the models that don't
have eMMC) that runs without hooking up power and plugging in an SD
card. :-P

It has MMC controller/slot described in the DTS and the SDcard itself is
DT-transparent, meaning you do not describe it in DTS, plus I can easily
insert such card, thus for sake of this discussion that RPi still works
fine with DTS.

This SoC cannot work without other pieces described in DT, that's why it
is incomplete and unusable on its own.

You are right that my previous arguments of hooking components are
incomplete, so let me rephrase it - the DTS file should be complete from
DT point of view and completly usable on its own. That's why DTS
represents board (with the exceptions of few SoMs as explaiend to me
long time ago).

SoC does not meet this criteria, therefore it is not suitable for DTS.

And if you claim that SoC could be fitting DTS, then I claim that
individual transistor or one IP block like DWC USB3 could be there as
well. With your arguments we could create DTS files for DWC USB3 nodes.
Fact that transistor or DWC USB3 cannot execute code on their own does
not matter, because it is nowhere said that DTS represents something
which can execute code. CPU executes code, so following this argument
DTS could contain only CPU device nodes..

If we allow subpieces, like SoC components or SoCs (both still unusable
on their own), as DTS files we open the pandora box of all possible
styles and formats. I don't see reasoon why would we want it, what
benefits this would bring to the ecosystem maintenance.

We did not document it that DTS represents usable board, but it is
implied all over the software projects, like GRUB devicetree [1] which
takes one DTB to load. Only one.

Obviously at the grub and kernel level we support only 1 DTB. No one
is debating that here. Can we back up and stop debating implementation
details.

The problem is in early boot before there's DT used where you
determine the SoC and/or board at runtime and need to load the DTB
from that information. Both are dynamic in Google's case, but it could
easily be only the SoC or only the board is determined at runtime.
There's another similar usecase of booting a SoM with a SoM DT and
then applying the baseboard DT overlay. You could want to do both in
the same system. Your options are either have every possible
combination as a full DT or have a way to combine them at runtime in
some way. I'm pretty certain the answer for the former will be there's
not enough storage. So that leaves the latter option.

The only real answers here are a) your usecase is not valid or b) how
to implement the usecase.

Rob