[PATCH 1/2] global: Clean up arch/*/dts/Makefile

[Rasmus Villemoes]

On 19/11/2023 20.09, Simon Glass wrote:

> On Fri, 17 Nov 2023 at 15:52, Tom Rini <trini at konsulko.com> wrote:
>>
>> With commit 3609e1dc ("dts: automatically build necessary .dtb files")
>> we now have logic that will ensure that all device trees needed in the
>> binary are built automatically. Any device tree that the developer needs
>> while working can still be built normally via make arch/.../foo.dtb so
>> we can simply drop the rest of this logic.

>>  13 files changed, 6 insertions(+), 1570 deletions(-)
> 
> I can see the motivation for this, but it ends up moving us away from
> driver model and devicetree, IMO. 

No, it does not.

> For example, rk3399 and other
> rockchip boards use DT for their init so the same U-Boot can be used
> for all, mostly. 

Huh? I just took a look at a few random _defconfigs that mention various
rk3399-* as CONFIG_DEFAULT_DEVICE_TREE. And they vary _wildly_ beyond
just that DEFAULT_DEVICE_TREE, so the U-Boot binary (as in the ELF file,
before being concat'ed with a .dtb or wrapped in some container) that
comes out of those must be similarly wildly different.

> Ideally that is the way all boards would be, as they
> are in Linux.

As Tom notes, that's just not gonna happen, ever, not even within a
single SOC. Something as simple as the amount of RAM may need to be
hardcoded by _some_ stage of the boot process. (Not all, I'm sure you
can find examples of SOCs where it is possible to actually build a quite
generic u-boot binary, but how that binary is then going to figure out
which .dtb is relevant either to itself or to the kernel its job is to
load is then hard to know... something like a top-level compatible
string would still need to be hard-coded somewhere in the binary).

> But here I have to manually add all the rk3399 boards to OF_LIST for
> each board

No, why? If you want to create such a generic U-Boot, you create one
single _defconfig that has all the options needed by all the various
rk3399 variants it's supposed to support, and add all the relevant .dtbs
to that defconfig's OF_LIST.

> So this is teaching people to use a board.c file, to use #ifdefs for
> device-specific differences, etc. It will be easier to do that than to
> do the right thing.

I'm sorry, but I really don't see how that follows. All this does is
eliminate duplication in our build system. Each defconfig already lists
the dtbs it works with (/is supposed to work with), which can be a wide
or narrow range of boards; some boards have multiple defconfigs simply
because the users may choose to store U-Boot (or its environment, or...)
in nand or emmc or SPI-NOR or... Sure, some of that info could come from
a .dtb, and the .dtb could somehow be chosen at run-time or some earlier
stage be tasked with figuring it out (which just leads to an elephants
all the way down problem).

> With Linux right now I can build an arm64 build which supports most of
> the boards...with about 990 devicetree files. 

Well, the kernel can get away with a kitchen-sink defconfig build
resulting in a 40+MB kernel image plus hundreds of MB of modules on top.
And relying on an earlier stage picking the right .dtb for it. U-Boot
simply doesn't have that luxury, because U-Boot is that earlier stage.

Rasmus