[PATCH 0/2] Add rpi5 specific defconfig

[Peter Robinson]

> > > > >> 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?

Typical RPi users want one of two things:
1) use the DT provided by the prior FW stage, this has the advantage
that the FW deals with overlays, will add configs automatically based
on HW/settings/actual device etc.
2) Use the DT provided by the Linux kernel, we have code to detect the
HW and load the right DT in that case

This is why we've never really bothered with the full RPi DT in U-Boot
because it's always a worse experience that either of the above two
options and allows a more straight forward config making support
easier. Even with the RPi5 I am still yet to to be convinced there's a
real reason this would change.

Peter