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

[Simon Glass]

Hi Tom,

On Mon, 2 Oct 2023 at 09:12, Tom Rini <trini at konsulko.com> wrote:
>
> On Mon, Oct 02, 2023 at 08:43:41AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Mon, 2 Oct 2023 at 08:09, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Sun, Oct 01, 2023 at 07:17:27PM -0600, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Fri, 29 Sept 2023 at 10:02, Tom Rini <trini at konsulko.com> wrote:
> > > > >
> > > > > On Fri, Sep 29, 2023 at 09:15:00AM -0600, Simon Glass wrote:
> > > > > > Hi Rasmus,
> > > > > >
> > > > > > On Mon, 25 Sept 2023 at 13:05, Rasmus Villemoes
> > > > > > <rasmus.villemoes at prevas.dk> wrote:
> > > > > > >
> > > > > > > On 25/09/2023 20.19, Tom Rini wrote:
> > > > > > > > On Mon, Sep 25, 2023 at 10:27:43AM +0200, Rasmus Villemoes wrote:
> > > > > > > >> On 04/05/2023 14.35, Rasmus Villemoes wrote:
> > > > > > > >>> On 03/05/2023 16.54, Tom Rini wrote:
> > > > > > > >>
> > > > > > > >>>> The one last problem now is on stm32mp15_dhcor_basic which is a
> > > > > > > >>>> defconfig missing one from OF_LIST but including it in the its file, so
> > > > > > > >>>> the above is the patch we need.
> > > > > > > >>>>
> > > > > > > >>
> > > > > > > >> Hi Tom
> > > > > > > >>
> > > > > > > >> Can I persuade you to try something like
> > > > > > > >> https://source.denx.de/u-boot/u-boot/-/commit/a05e0d0e6b9103542a1076f9cab0005f400fa072
> > > > > > > >> again, but leaving the .dtbo targets in there?
> > > > > > > >>
> > > > > > > >> I could send a patch, but it's entirely mechanical, and not really meant
> > > > > > > >> for being applied until we know if there's more to be cleaned up.
> > > > > > > >
> > > > > > > > So what ended up being the problem I think is the case Simon pointed out
> > > > > > > > where we do take the output from "make all" and concatenate one of the
> > > > > > > > dtbs that was generated with u-boot.img or so, and it works.  But maybe
> > > > > > > > that should just list all of the valid DTBs that it needs in the
> > > > > > > > defconfig to start with? I don't quite know, it was a case I hadn't
> > > > > > > > considered at the time.
> > > > > > > >
> > > > > > >
> > > > > > > Re-reading the thread, I can't see where that was mentioned.
> > > > > > >
> > > > > > > But yes, if some boards (still) need that, and have more than one
> > > > > > > possible .dtb, the board can't set an OF_LIST different from the default
> > > > > > > consisting of DEFAULT_DEVICE_TREE because changing OF_LIST requires
> > > > > > > SPL_LOAD_FIT || MULTI_DTB_FIT.
> > > > > > >
> > > > > > > How do we figure out if such boards even exist?
> > > > > >
> > > > > > Honestly at this point I've forgotten what this is all about.
> > > > > >
> > > > > > 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).  With the series to handle dtbo files, we could remove
> > > > > virtually all of that, and the only use cases that don't Just Work still
> > > > > are the ones I forget which board you mentioned (I think it was Samsung
> > > > > tho?) where the defconfig doesn't list all of the device trees, just one
> > > > > of them, and the other 5 that we build can also be easily used.  Does
> > > > > that ring a bell?
> > > >
> > > > Yes it does...but what is the problem here?
> > >
> > > Messy and unused and incorrect Makefile content.
> >
> > The problem I see there is people using TARGET in
> > arch/arm/dts/Makefile for example. There are 80 instances of that. The
> > rules should depend on SoC (e.g. use ARCH_EXYNOS5), as Linux does it.
>
> It shouldn't be there at all since there's almost no cases where we
> "just" take an arbitrary dtb file and u-boot.img and then the system
> boot.  That's what this series is about fixing.

I'm really not sure that replacing build rules with a board CONFIG is
a good idea. I suppose part of my confusion is why the Makefile is
considered a problem?

>
> > > > The DT files for an SoC are supposed to be buildable without needing
> > > > to have the context of a particular board.
> > >
> > > They're still buildable, without an explicit rule, they just need to
> > > (like they can now) be built explicitly.
> >
> > But isn't that creating dead code? It will rot.
>
> No, that's the problem we have today, people list something in the
> Makefile, since they think they need to list something, and then put the
> device trees they use in the defconfig.

If they don't list something, it won't build, right?

>
> [snip]
> > > > I am find with making the boards list the DTs that they can run with,
> > > > if there is an easy way of doing that. CONFIG_SPL_OF_LIST is just for
> > > > SPL, I think.
> > >
> > > Yes, every board except for some use case you've described before as far
> > > as I know lists the device trees that they use in the defconfig.  Which
> > > is why there's an impetus to clean up arch/*/dts/Makefile as 95% of
> > > those lines can just be removed.
> >
> > It seems like you are wanting a board-level CONFIG which lists the DTs
> > which need to be built for that board. Is that right? You are
> > suggesting that this already exists, but I am not aware of it. Do you
> > mean SPL_OF_LIST, perhaps?
>
> I mean today CONFIG_DEFAULT_DEVICE_TREE + CONFIG_OF_LIST +
> CONFIG_SPL_OF_LIST is set and correct for everyone board except some use
> case you have, which I think is something about exynos?  And so we only
> need scripts/Makefile.dts in arch/*/dts/Makefile

Yes exynos5 boards (the original reason for DT) have / had the same
u-boot-nodtb.bin and you can add the DT you want to boot it on
particular hardware. That is one of the goals of DT.

The OF_LIST option is a little vague but I think it means that the DTs
are packaged into a FIT in u-boot.img - is that right? But they
presumably have to be built first.

I think this would be better discussed f2f.

Regards,
Simon