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

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

[E Shattow]

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

Signed-off-by: E Shattow <e@freeshell.de>
---
 scripts/Makefile.lib | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 5db2fbc418a..e5193126411 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -201,6 +201,7 @@ u_boot_dtsi_options = $(strip $(wildcard $(u_boot_dtsi_loc)$(basename $(notdir $
 	$(wildcard $(u_boot_dtsi_loc)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi) \
 	$(wildcard $(u_boot_dtsi_loc)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi) \
 	$(wildcard $(u_boot_dtsi_loc)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi) \
+	$(wildcard $(u_boot_dtsi_loc)$(subst $\",,$(CONFIG_SYS_CONFIG_NAME))-u-boot.dtsi) \
 	$(wildcard $(u_boot_dtsi_loc)u-boot.dtsi))
 
 u_boot_dtsi_options_raw = $(warning Automatic .dtsi inclusion: options: \
@@ -208,6 +209,7 @@ u_boot_dtsi_options_raw = $(warning Automatic .dtsi inclusion: options: \
 	$(u_boot_dtsi_loc)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi \
 	$(u_boot_dtsi_loc)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi \
 	$(u_boot_dtsi_loc)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi \
+	$(u_boot_dtsi_loc)$(subst $\",,$(CONFIG_SYS_CONFIG_NAME))-u-boot.dtsi \
 	$(u_boot_dtsi_loc)u-boot.dtsi ... \
 	found: $(if $(u_boot_dtsi_options),"$(u_boot_dtsi_options)",nothing!))
 

base-commit: cb0b67fa49df836627230ba62fc718ea4afddf60
-- 
2.50.0

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

[Rasmus Villemoes]

On Sun, Aug 24 2025, E Shattow <e@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

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

[E Shattow]

Hi Rasmus,

On 8/25/25 00:50, Rasmus Villemoes wrote:
> On Sun, Aug 24 2025, E Shattow <e@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

Re: [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@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