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

Tom Rini trini at konsulko.com
Fri Sep 29 18:02:30 CEST 2023


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?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20230929/1e4285ef/attachment.sig>


More information about the U-Boot mailing list