> > From: Bruno Leite <br...@prevas.dk> > > > > > > Currently rpi5 uses a generic rpi_arm64_defconfig file that builds rpi4 > > devicetree. Add a defconfig that is specific to the rpi5 building the > > now available upstream dts for that board. The defconfig makes use of > > defconfig including that is now available and only changes the DTS > > related config. > > > > It is also necessary to add a more specific u-boot.dtsi to rpi5, since > > due to the ARCH_BCM283X config it will try to build the > > bcm283x-u-boot.dtsi and break. > > My question is, can we not adjust rpi_arm64_defconfig to be generic > enough and not have a problem on Pi 5 due to the default device tree?
I'm not sure I quite understand the question, but in order to not build bcm283x-u-boot.dtsi we would either need to: 1-) not set ARCH_BCM283X for rpi5 2-) provide a higher in hierarchy u-boot.dtsi file The first one would require a rework of ARCH_BCM283X into some closer to the machine config, but that would probably cause some duplication of files and configs, as rpi5 shares lots of things from that ARCH with other rpi machines. Maybe make bcm283x-u-boot.dtsi more machine-specific, probably by duplicating the file to all the machines that need it (I think)? The second option is what I proposed here. Maybe I'm missing some third option? I believe it would be possible to make rpi_arm64_defconfig more generic by removing configs such as DEVICE_TREE and ARCH_BCM283X from there, causing it to be a "include-only file" of sorts that no machine should actually build and boot, but that would not solve any of the issues that the rpi5 has, as it would still need a defconfig of it's own defining both and the u-boot.dtsi in order to not build bcm283x-u-boot.dtsi ------------ Regards, Bruno
