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

[Simon Glass]

Hi Rasmus,

On Mon, 1 May 2023 at 02:49, Rasmus Villemoes
<rasmus.villemoes at prevas.dk> wrote:
>
> On 27/04/2023 19.31, Tom Rini wrote:
> >>
> >> Well, I'm not sure there's a use case for building all of the extra
> >> device trees. I think what I'll do right now is fire off a CI run (or a
> >> few, in the event of problems) where we just use the logic of
> >> 3609e1dc5f4d and see what falls down.
> >
> > So this gets us a few failures.  You can see them on
> > https://source.denx.de/u-boot/u-boot/-/jobs/618127 but one type of
> > failure seems to be the case where CONFIG_DEFAULT_DEVICE_TREE isn't
> > contained in CONFIG_OF_LIST (ls1088aqds_tfa for example) and the other
> > case is where CONFIG_OF_LIST != CONFIG_SPL_OF_LIST and this fails
> > because fdtgrep runs NOT on spl/arch/.../foo.dtb but rather
> > arch/.../foo.dtb and so we don't have the dtb file around.
> >
>
> Hm, the former sounds like a bug in the defconfig, the second sounds
> like a legit use case (or why would we have SPL_OF_LIST). Anyway, both
> should be fixable by just changing the logic of scripts/Makefile.dts a
> little; say add the union of DEFAULT_DEVICE_TREE, OF_LIST and
> SPL_OF_LIST to dtb-y. Something like
>
> diff --git a/scripts/Makefile.dts b/scripts/Makefile.dts
> index 2561025da8..5e2429c617 100644
> --- a/scripts/Makefile.dts
> +++ b/scripts/Makefile.dts
> @@ -1,3 +1,3 @@
>  # SPDX-License-Identifier: GPL-2.0+
>
> -dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_$(SPL_)OF_LIST)))
> +dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE)
> $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST)))

I think we should require that all the DTs in the list are already
built using the standard rule.

i.e. Makefile.dts should just have a check that OF_LIST doesn't bring
in anything new. If it does, then the build should fail.

The list is really about which ones should be put into the FIT. We
shouldn't be putting in things that don't exist normally for that SoC.

Meanwhile I think we should move towards prohibiting CONFIG_TARGET_...
in Makefile rules, since this is creating some of this problem. i.e.
we should do what Linux does. I was pushing back on this problem in
reviews, but not for a while, and I see that it has grown. That could
be a checkpatch rule.

It should be possible to use 'moveconfig -i' to find which SoC things belong to.

Regards,
Simon