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

[Simon Glass]

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.

Regards,
Simon