On Mon, May 05, 2025 at 11:45:05AM +0200, Rasmus Villemoes wrote: > On Fri, May 02 2025, Tom Rini <tr...@konsulko.com> wrote: > > > On Fri, May 02, 2025 at 01:34:33PM +0200, Bruno Leite wrote: > > > >> 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? > > Not really. > > What we want is to have CONFIG_DEFAULT_DEVICE_TREE to point at the > rpi5's .dts file, because we really want to build that and not some > "random" dts file that doesn't have anything to do with the hardware. I > know that kinda works for the setups where the .dtb built in U-Boot is > not used for anything, but in our case, we really do want to use the > .dtb from the U-Boot build - we inject various U-Boot specific stuff via > the EXTRA_DTSI mechanism, e.g. public key for kernel verification. > > And due to CONFIG_SYS_SOC being bcm283x, and bcm283x-u-boot.dtsi > referencing nodes that simply don't exist when building > bcm2712-rpi-5-b.dts, the build breaks. > > Perhaps the real problem is CONFIG_SYS_SOC being bcm283x for rpi5? I > don't really know why rpi4 is both bcm2711 and bcm2835 and what the > difference is, but rpi5 only seems to include a bcm2712.dtsi which does > not include further dtsi files. > > If rpi5 has nothing to do with bcm283x, then perhaps a better approach > is to ensure that CONFIG_SYS_SOC is bcm2712 when building for > rpi5. Something like adding a CONFIG_TARGET_RPI_5 choice and adding a > 'default "bcm2712" if TARGET_RPI_5' ?
OK, so I guess my next question is, is rpi_arm64 useful enough in the end for Pi 3 and Pi 4? I would have expected that it doesn't matter what tree we build in to U-Boot as we would be using the one passed to us by the prior stage firmware, and then update that at run-time as needed. -- Tom
signature.asc
Description: PGP signature