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.villem...@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
