On Mon, May 05, 2025 at 10:19:24PM +0200, Mark Kettenis wrote: > > Date: Mon, 5 May 2025 07:48:43 -0600 > > From: Tom Rini <tr...@konsulko.com> > > > > 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. > > Works well enough for us on OpenBSD. And it would be nice if > rpi_arm64 would work for the Pi 5 as well.
But that gets back to my first question. Can we correct the code such that we do whatever is required at run time, as the previous stage will have assembled and passed a correct device tree already? -- Tom
signature.asc
Description: PGP signature
