[PATCH v1] scripts/Makefile.lib: add CONFIG_SYS_CONFIG_NAME prefix to dtsi search

[E Shattow]

On 8/25/25 01:29, E Shattow wrote:
> Hi Rasmus,
> 
> On 8/25/25 00:50, Rasmus Villemoes wrote:
>> On Sun, Aug 24 2025, E Shattow <e at freeshell.de> wrote:
>>
>>> Add ${CONFIG_SYS_CONFIG_NAME}-u-boot.dtsi into dtsi include search order:
>>> dtsi location, SYS_SOC, SYS_CPU, SYS_VENDOR, (SYS_CONFIG_NAME), no prefix
>>>
>>
>> I tried that, with CONFIG_SYS_BOARD, but for my use case I wanted it to
>> have higher priority than something "just" matching SOC or CPU.
>>
>>   https://lore.kernel.org/u-boot/20230317102639.464263-1-rasmus.villemoes@prevas.dk/
>>
>> Can you explain what board(s) you are going to use this for? Because
>> this having lower priority than SOC, CPU, VENDOR seems wrong, and if
>> there already is some soc-dtsi file for you board, this won't have any
>> effect for you.
>>
>> The problem with my patch was that we build a lot of completely
>> unnecessary .dtb files, and the build of those unneeded dtb files break
>> if/when the .config we're building causes an unrelated .dtsi file to be
>> included (most often because it refers to nodes that do not exist). I've
>> suggested several times that we just nuke most of that dts/Makefile
>> because it's really not useful, it still contains typos, and nobody
>> notices because we nowadays have build logic to automatically build all
>> the .dtbs that are actually relevant to the .config we're building.
>>
>> Rasmus
> 
> The starfive_visionfive2_defconfig target supports a variety of variant
> boards from several vendors and models (and even a range of SoM's)
> having the StarFive Jh7110 CPU;  when before adoption of OF_UPSTREAM we
> go from having:
> 
> arch/riscv/dts/jh7110-milkv-mars.dts
> arch/riscv/dts/jh7110-pine64-star64.dts
> arch/riscv/dts/jh7110-starfive-visionfive-2-v1.2a.dts
> arch/riscv/dts/jh7110-starfive-visionfive-2-v1.3b.dts
> arch/riscv/dts/jh7110-common.dts
> arch/riscv/dts/jh7110.dts
> 
> (and my memory of this is not quite accurate I think there was a
> jh7110-visionfive2.dts or something ... )
> 
> each some confusing not-quite-upstream-Linux mish-mash of copy-and-paste
> from the respective vendor U-Boot firmware from several years in the
> past; More confusingly the U-Boot target to build this is named
> 'starfive_visionfive2_defconfig' which has no visual relation to
> 'jh7110'-named things...
> 
> and then to after sending everything upstream to Linux kernel and
> adoption of OF_UPSTREAM having:
> 
> arch/riscv/dts/jh7110-deepcomputing-fml13v01-u-boot.dtsi
> arch/riscv/dts/jh7110-milkv-mars-u-boot.dtsi
> arch/riscv/dts/jh7110-pine64-star64-u-boot.dtsi
> arch/riscv/dts/jh7110-starfive-visionfive-2-v1.2a-u-boot.dtsi
> arch/riscv/dts/jh7110-starfive-visionfive-2-v1.3b-u-boot.dtsi
> arch/riscv/dts/jh7110-common-u-boot.dtsi
> arch/riscv/dts/jh7110-u-boot.dtsi
> arch/riscv/dts/starfive-visionfive2-binman.dtsi
> arch/riscv/dts/binman.dtsi
> 
> each simply having an '#include "jh7110-common-u-boot.dtsi"' for the
> common stuff that hasn't quite made it upstream yet and also '#include
> "starfive-visionfive2-binman.dtsi"' for the binman specific ops that
> stuff a copy of that particular variant devicetree into the final output
> so that they can be selected at runtime from a heuristic against the
> EEPROM content...
> 
> anyhow all that is to say I would like this to reduce further:
> 
> arch/riscv/dts/starfive-visionfive2-u-boot.dtsi
> arch/riscv/dts/starfive-visionfive2-binman.dtsi
> arch/riscv/dts/binman.dtsi
> 
> and removes any need for file clutter when we are already naming the
> devicetree-rebasing dts target as part of CONFIG_OF_LIST.
> 
> my view is that for multi-variant U-Boot targets the defconfig name
> should match the dtsi override names so they're easy to search for,
> simple as that.
> 
> When the U-Boot target is OF_UPSTREAM then CONFIG_OF_LIST contains the
> list of board dts target names.
> 
> I don't want to push this unnecessarily on any other user in U-Boot, and
> I think it's actually appropriate that it only takes precedence over
> 'u-boot.dtsi'.
> 
> I look at those as the old way, and then introducing some new way should
> be rather optional; if you want to take advantage of it then clearing
> out the SOC, CPU, or VENDOR dtsi that take precedence is necessary.
> 
> For your suggestion of adding BOARD, it is more complicated. There is
> more restriction on naming a board because it can't be something totally
> different than what it is, that would not make sense. But we have
> "coreboot_defconfig" for example what is that? it is not a board. It is
> however a U-Boot board target. So yes things are a bit strange trying to
> go back and add a new class of automatic dtsi include in the search order.
> 
> I think OF_UPSTREAM and CONFIG_OF_LIST with an automatic dtsi include of
> the defconfig name go a long way to what you might want?
> 
> I do have to test this more to be sure it is working like I imagine it
> should be, also.
> 
> -E Shattow

Postscript, I had a think(); about this some more and would like to
clarify that I do not object to promote the proposed SYS_CONFIG_NAME
search order priority ahead of SYS_SOC, SYS_CPU, SYS_VENDOR.

At a glance it should not be any problem in the code base today. The
only affected U-Boot targets are 'coreboot' which anyways matches the
other search ordering on the same keyword itself, and some powerpc
targets which each already include 'u-boot.dtsi' so ... also not a problem.

I'll send v2 shortly with the search order the other way around.

-E