[PATCH] scripts/Makefile.lib: also consider $(CONFIG_SYS_BOARD)-u-boot.dtsi

[Simon Glass]

Hi Rasmus,

On Mon, 2 Oct 2023 at 13:02, Rasmus Villemoes
<rasmus.villemoes at prevas.dk> wrote:
>
> On 29/09/2023 18.02, Tom Rini wrote:
> > On Fri, Sep 29, 2023 at 09:15:00AM -0600, Simon Glass wrote:
>
> >> Honestly at this point I've forgotten what this is all about.
>
> Fair enough, let me try to recap, though even a summary is a bit long.
>
> (1) I wanted to do what $subject says, and you seemed to be ok with that
>
> https://lore.kernel.org/u-boot/CAPnjgZ1B+3v_5rCSBnUgZ6cVO4odjjDfeS0rx3iMw4vjXUo0VA@mail.gmail.com/
>
> (2) Tom pointed out that, unfortunately, as-is, the patch caused a bunch
> of build failures. With hindsight, that was inevitable.
>
> https://lore.kernel.org/u-boot/c3c94614-9916-7316-e009-04ddbdc205bc@prevas.dk/
>
> (3) I still very much would like the original patch to go in, and so I
> pointed out that most of the current arch/*/dts/Makefile are actually
> completely redundant, with the logic in scripts/Makefile.dts being in place.
>
> This is when the thread turned away from talking about the original
> patch, but rather the cleanup of the makefile logic that turns out to be
> a prerequisite for said patch to go anywhere.
>
> (4) Tom tested a patch that nuked most of the arch/arm/dts/Makefile,
> which revealed a few defects, partly in Makefile.dts (got fixed in
> 6923f49d3ac2) partly in a board defconfig (got fixed in 2d158d3c387d).
>
> >> Perhaps the easiest approach is to create a new Kconfig to control
> >> whether a board-level .dtsi is included in the list of wildcard
> >> searches. Then you can enable it for your board without affecting
> >> others.
> >
> > That's getting things backwards, from what this cleanup does.  Today we
> > have messy lists of "build these device trees" and then don't use most
> > of them, and some of the list is just Wrong (listing dts files as an
> > output).
>
> (5) Then a few months passed. I'm still interested in the original
> patch, and also the cleanup. So I pinged Tom to redo that build test
> with most of the Makefile gone. While revisiting this and doing that
> mechanical strip-down of the Makefile, I noticed that the Makefile has
> grown not just one but two .dts files listed in dtb-y, which is of
> course bogus, and nobody noticed or cared because the
> scripts/Makefile.dts logic JustWorks.
>
> So, given that today, each board, in the form of the defconfig used to
> build for it, in 99.9% of cases already includes all the information the
> build system needs in order to ensure that all relevant .dtb files gets
> built [because there's only one and that's DEFAULT_DEVICETREE, or
> there's more and those are in OF_LIST or SPL_OF_LIST], and the Makefile
> is error-prone to maintain and when adding a new board one chooses some
> semi-random-list to add one's .dtbs (or .dts.....) to, we want to simply
> stop having all those lists in arch/arm/dts/Makefile (and the other
> arch/*/dts/Makefile, but those are much smaller and can be handled
> later). No TARGET lists, no SOC lists, no nothing.
>
> Yes, there may still be some 0.1%. We're trying to figure out if they
> exist, which they are, and how best to handle them. An easy fix is to
> drop the condition on when OF_LIST is settable to something different
> from its default (which is DEFAULT_DEVICETREE). But without knowing just
> exactly which boards and which .dtbs we're talking about, it's hard to
> know what the best solution is or if there is actually anything that
> needs to be done.

Thanks for all the details. My memory for things that last across
months is not good. It is clearer now.

I don't really see any specific problem with this.

It does seem duplicative though, in that each board (in a group that
differ only in their DT) has to have the same list. Why not have it
once, in the Makefile, based on ARCH_SOC...?

Perhaps I am unrealistic in hoping that much of the C code for a board
will go away, but we do see boards which don't have much / any code,
but do have hardware differences.

I would love to put a stake in the ground and say that boards that use
the same SoC should be able to use the same C code and work correctly,
just with a different DT. For example I think most/all rockchip boards
are like that. Then we might head closer to the kernel which can boot
on various boards with the same build.

It seems to me that heading the way you describe, we are making it
harder for people to do this, or even suggesting that it is not
desirable.

Anyway I will leave you and Tom to figure this out, since you seem
very keen on this idea. Thank you again for explaining it all.

Regards,
Simon