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 <[email protected]> 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/[email protected]/ >> >> 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
