19:53 <shadows> is there a mechanism in U-Boot for OF_UPSTREAM firmware to negate the need to have a common include file for each board variant of some U-Boot board target?

19:55 <shadows> for starfive jh7110 (U-Boot starfive visionfive2 board target) there's arch/riscv/dts/jh7110-{vendor}-{product}-u-boot.dtsi for each variant listed in the starfive_visionfive2_defconfig and all they need to do is each include starfive-visionfive2-binman.dtsi

19:58 <shadows> the build process complains if any of those arch/riscv/dts/jh7110-{vendor}-{product}-u-boot.dtsi files are absent, and I would rather it be a common dtsi arch/riscv/dts/starfive-visionfive2-binman.dtsi either default or specified somewhere in the config

20:00 <shadows> n.b. s/firmware/board target/

20:07 <shadows> maybe, if CONFIG_OF_LIST item does not have a representative *-u-boot.dtsi then attempt to load a u-boot board target *-binman.dtsi or something...

20:07 <shadows> or both.

20:13 <shadows> looks like the checks are currently for SOC, CPU, VENDOR. Okay, maybe what I want can be done.

20:18 <shadows> would have to be something like adding a check for CONFIG_NAME as well

20:26 <shadows> scripts/Makefile.lib:200 or so

22:10 <shadows> sjg1: one file in the whole repo I find is suspicious if I make this change, is arch/x86/dts/coreboot-u-boot.dtsi which I think would be remedied by adding an include statement for "u-boot.dtsi" however I'm not sure if that is correct, I only know about starfive jh7110 targets

22:11 <shadows> there's also some powerpc targets but they all have this u-boot.dtsi include statement anyways, so I reason they're not going to be affected

22:21 <shadows> maybe that is not the desired action though, hmm

22:23 <shadows> already then is CONFIG_SYS_SOC="coreboot" taking precedence. will send patch without any change to it