[PATCH 0/2] Add rpi5 specific defconfig

[Rasmus Villemoes]

On Sun, Jun 15 2025, Peter Robinson <pbrobinson at gmail.com> wrote:

> On Tue, 6 May 2025 at 08:30, Rasmus Villemoes <ravi at prevas.dk> 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.
>
> Any reason why CONFIG_OF_LIST= wouldn't work for that?

Yes. The fact that when you try to do that currently,
CONFIG_SYS_SOC="bcm283x" means that the u-boot build system ends up
including bcm283x-u-boot.dtsi, and that has references to nodes that do
not exist in bcm2712-rpi-5-b.dts. Which is exactly what I wrote above.

So what we're suggesting is to add a more-specific *-u-boot.dtsi file
(namely, one named after the base .dts file), which can just be empty,
so that that empty file will instead be picked up when U-Boot builds
bcm2712-rpi-5-b.dtb.

That works just fine. And with that in place, one could add
bcm2712-rpi-5-b to CONFIG_OF_LIST in the rpi64_defconfig.

Rasmus