[PATCH 0/2] Add rpi5 specific defconfig

[Tom Rini]

On Tue, May 06, 2025 at 09:30:11AM +0200, Rasmus Villemoes wrote:
> On Mon, May 05 2025, Tom Rini <trini at konsulko.com> wrote:
> 
> > 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 <trini at konsulko.com>
> >> > 
> >> > On Mon, May 05, 2025 at 11:45:05AM +0200, Rasmus Villemoes wrote:
> >> > > On Fri, May 02 2025, Tom Rini <trini at konsulko.com> wrote:
> >> > > 
> >> > > > On Fri, May 02, 2025 at 01:34:33PM +0200, Bruno Leite wrote:
> >> > > >
> >> > > >> From: Bruno Leite <brule at 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?
> 
> I think this is sort-of asking the wrong question. The problem is not
> about what dtb the prior stage hands us or what to do at run-time. [*]
> 
> The problem is to have a defconfig that will compile
> bcm2712-rpi-5-b.dts, as part of the U-Boot build. As I said, it's quite
> likely that rpi5 isn't at all a part of the 'menu "Broadcom BCM283X
> family"', and it's the CONFIG_SYS_SOC="bcm283x" that prevents
> bcm2712-rpi-5-b.dts from being compiled (because the bcm283x-u-boot.dtsi
> doesn't apply to that .dts). Bruno's patches achieve that by adding a
> more-specific -u-boot.dtsi file (it doesn't seem that we need any of the
> bootph-all settings from the bcm283x.dtsi file), and adding a defconfig
> file that is based on arm64, but just changes the dt settings.
> 
> Those who simply ignore what .dtbs are part of the U-Boot build and use
> blobs coming from elsewhere can probably use rpi_arm64_defconfig as-is
> for rpi5.

I think I finally get it, thanks for being persistent. I'd like to see
if we can solve this without making things less generic. In snapdragon
for example we've been making progress on having more (and different)
platforms work in a single build and this feels like a step backwards.
If there's not other non-Pi platforms for these SoCs maybe we need to
think less in terms of "mach-bcm.." and more in terms of
"mach-raspberrypi" or something along those lines.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250506/0cd5f378/attachment.sig>