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

[Simon Glass]

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?

The DT files for an SoC are supposed to be buildable without needing
to have the context of a particular board.

I don't know what the point of the dtbo files is...is that for using
overlays somehow at runtime?

The defconfig does not need to mention all the DTs...we just need to
make sure they get built.

Is this another instance of something that needs cleaning up, like the
config fragments?

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.

Regards,
Simon