[PATCH 0/2] Add rpi5 specific defconfig

[PATCH 0/2] Add rpi5 specific defconfig

[Bruno Leite]

From: Bruno Leite <brule@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.


Bruno Leite (2):
  arm64: dts: rpi5: add rpi5 u-boot.dtsi
  configs: rpi5: add rpi5 specific defconfig

 arch/arm/dts/bcm2712-rpi-5-b-u-boot.dtsi | 8 ++++++++
 configs/rpi_5_defconfig                  | 4 ++++
 2 files changed, 12 insertions(+)
 create mode 100644 arch/arm/dts/bcm2712-rpi-5-b-u-boot.dtsi
 create mode 100644 configs/rpi_5_defconfig

-- 
2.45.2

[PATCH 1/2] arm64: dts: rpi5: add rpi5 u-boot.dtsi

[Bruno Leite]

From: Bruno Leite <brule@prevas.dk>

bcm283x-u-boot.dtsi modifies dts nodes that the upstream
rpi5 dts does not have and thus break build. add an empty
dtsi that is more specific to the upstream dts to prevent
u-boot from trying to build that one.

Signed-off-by: Bruno Leite <brule@prevas.dk>
---

 arch/arm/dts/bcm2712-rpi-5-b-u-boot.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 arch/arm/dts/bcm2712-rpi-5-b-u-boot.dtsi

diff --git a/arch/arm/dts/bcm2712-rpi-5-b-u-boot.dtsi b/arch/arm/dts/bcm2712-rpi-5-b-u-boot.dtsi
new file mode 100644
index 00000000000..65219f158e4
--- /dev/null
+++ b/arch/arm/dts/bcm2712-rpi-5-b-u-boot.dtsi
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Empty device tree for raspberrypi5
+ *
+ */
+
+/ {
+};
-- 
2.45.2

[PATCH 2/2] configs: rpi5: add rpi5 specific defconfig

[Bruno Leite]

From: Bruno Leite <brule@prevas.dk>

rpi5 is currently built with rpi_arm64_defconfig,
but that is a generic defconfig that does not build
machine-specific things like the devicetree. Add the
rpi5 specific defconfig with it's own dts from upstream.

Signed-off-by: Bruno Leite <brule@prevas.dk>

---

 configs/rpi_5_defconfig | 4 ++++
 1 file changed, 4 insertions(+)
 create mode 100644 configs/rpi_5_defconfig

diff --git a/configs/rpi_5_defconfig b/configs/rpi_5_defconfig
new file mode 100644
index 00000000000..852eff1c455
--- /dev/null
+++ b/configs/rpi_5_defconfig
@@ -0,0 +1,4 @@
+#include <configs/rpi_arm64_defconfig>
+
+CONFIG_DEFAULT_DEVICE_TREE="broadcom/bcm2712-rpi-5-b"
+CONFIG_OF_UPSTREAM=y
-- 
2.45.2

Re: [PATCH 0/2] Add rpi5 specific defconfig

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

On Fri, May 02, 2025 at 01:34:33PM +0200, Bruno Leite wrote:

> From: Bruno Leite <brule@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?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 0/2] Add rpi5 specific defconfig

[Bruno Leite]

> > From: Bruno Leite <brule@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?

I'm not sure I quite understand the question, but in order to not build
bcm283x-u-boot.dtsi we would either need to:

1-) not set ARCH_BCM283X for rpi5
2-) provide a higher in hierarchy u-boot.dtsi file

The first one would require a rework of ARCH_BCM283X into some closer to
the machine config, but that would probably cause some duplication of
files and configs, as rpi5 shares lots of things from that ARCH with
other rpi machines. Maybe make bcm283x-u-boot.dtsi more machine-specific,
probably by duplicating the file to all the machines that need it (I think)?

The second option is what I proposed here. Maybe I'm missing some third option?

I believe it would be possible to make rpi_arm64_defconfig more generic by
removing configs such as DEVICE_TREE and ARCH_BCM283X from there, causing it
to be a "include-only file" of sorts that no machine should actually build and
boot, but that would not solve any of the issues that the rpi5 has, as it would
still need a defconfig of it's own defining both and the u-boot.dtsi in order to
not build bcm283x-u-boot.dtsi

------------

Regards,
Bruno

Re: [PATCH 0/2] Add rpi5 specific defconfig

[Rasmus Villemoes]

On Fri, May 02 2025, Tom Rini <trini@konsulko.com> wrote:

> On Fri, May 02, 2025 at 01:34:33PM +0200, Bruno Leite wrote:
>
>> From: Bruno Leite <brule@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' ?

Rasmus

Re: [PATCH 0/2] Add rpi5 specific defconfig

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2441 bytes --]

On Mon, May 05, 2025 at 11:45:05AM +0200, Rasmus Villemoes wrote:
> On Fri, May 02 2025, Tom Rini <trini@konsulko.com> wrote:
> 
> > On Fri, May 02, 2025 at 01:34:33PM +0200, Bruno Leite wrote:
> >
> >> From: Bruno Leite <brule@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 0/2] Add rpi5 specific defconfig

[Mark Kettenis]

> Date: Mon, 5 May 2025 07:48:43 -0600
> From: Tom Rini <trini@konsulko.com>
> 
> On Mon, May 05, 2025 at 11:45:05AM +0200, Rasmus Villemoes wrote:
> > On Fri, May 02 2025, Tom Rini <trini@konsulko.com> wrote:
> > 
> > > On Fri, May 02, 2025 at 01:34:33PM +0200, Bruno Leite wrote:
> > >
> > >> From: Bruno Leite <brule@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.

Re: [PATCH 0/2] Add rpi5 specific defconfig

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3109 bytes --]

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@konsulko.com>
> > 
> > On Mon, May 05, 2025 at 11:45:05AM +0200, Rasmus Villemoes wrote:
> > > On Fri, May 02 2025, Tom Rini <trini@konsulko.com> wrote:
> > > 
> > > > On Fri, May 02, 2025 at 01:34:33PM +0200, Bruno Leite wrote:
> > > >
> > > >> From: Bruno Leite <brule@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 0/2] Add rpi5 specific defconfig

[Rasmus Villemoes]

On Mon, May 05 2025, Tom Rini <trini@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@konsulko.com>
>> > 
>> > On Mon, May 05, 2025 at 11:45:05AM +0200, Rasmus Villemoes wrote:
>> > > On Fri, May 02 2025, Tom Rini <trini@konsulko.com> wrote:
>> > > 
>> > > > On Fri, May 02, 2025 at 01:34:33PM +0200, Bruno Leite wrote:
>> > > >
>> > > >> From: Bruno Leite <brule@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.

Rasmus

[*] That's mostly a solved packaging problem outside the scope of
U-Boot itself: Just put whatever .dtb one wishes the prior stage to pass
to U-Boot along with u-boot.bin in the FAT filesystem, and put

kernel=u-boot.bin
device_tree=u-boot.dtb

in config.txt (sure, there might be drivers that need updating to take
different compatibles or whatnot into account).

Re: [PATCH 0/2] Add rpi5 specific defconfig

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 4849 bytes --]

On Tue, May 06, 2025 at 09:30:11AM +0200, Rasmus Villemoes wrote:
> On Mon, May 05 2025, Tom Rini <trini@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@konsulko.com>
> >> > 
> >> > On Mon, May 05, 2025 at 11:45:05AM +0200, Rasmus Villemoes wrote:
> >> > > On Fri, May 02 2025, Tom Rini <trini@konsulko.com> wrote:
> >> > > 
> >> > > > On Fri, May 02, 2025 at 01:34:33PM +0200, Bruno Leite wrote:
> >> > > >
> >> > > >> From: Bruno Leite <brule@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [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

Re: [PATCH 0/2] Add rpi5 specific defconfig

[Peter Robinson]

On Tue, 6 May 2025 at 08:30, Rasmus Villemoes <ravi@prevas.dk> wrote:
>
> On Mon, May 05 2025, Tom Rini <trini@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@konsulko.com>
> >> >
> >> > On Mon, May 05, 2025 at 11:45:05AM +0200, Rasmus Villemoes wrote:
> >> > > On Fri, May 02 2025, Tom Rini <trini@konsulko.com> wrote:
> >> > >
> >> > > > On Fri, May 02, 2025 at 01:34:33PM +0200, Bruno Leite wrote:
> >> > > >
> >> > > >> From: Bruno Leite <brule@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?

> 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.
>
> Rasmus
>
> [*] That's mostly a solved packaging problem outside the scope of
> U-Boot itself: Just put whatever .dtb one wishes the prior stage to pass
> to U-Boot along with u-boot.bin in the FAT filesystem, and put
>
> kernel=u-boot.bin
> device_tree=u-boot.dtb
>
> in config.txt (sure, there might be drivers that need updating to take
> different compatibles or whatnot into account).

Re: [PATCH 0/2] Add rpi5 specific defconfig

[Rasmus Villemoes]

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

> On Tue, 6 May 2025 at 08:30, Rasmus Villemoes <ravi@prevas.dk> wrote:
>>
>> On Mon, May 05 2025, Tom Rini <trini@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@konsulko.com>
>> >> >
>> >> > On Mon, May 05, 2025 at 11:45:05AM +0200, Rasmus Villemoes wrote:
>> >> > > On Fri, May 02 2025, Tom Rini <trini@konsulko.com> wrote:
>> >> > >
>> >> > > > On Fri, May 02, 2025 at 01:34:33PM +0200, Bruno Leite wrote:
>> >> > > >
>> >> > > >> From: Bruno Leite <brule@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