[Buildroot] [PATCH v3 0/3] U-Boot on RPi boards

[Buildroot] [PATCH v3 0/3] U-Boot on RPi boards

[Fiona Klute via buildroot]

From: "Fiona Klute (WIWA)" <fiona.klute@gmx.de>

I'm working on a system that needs U-Boot to manage booting on an
RPi-based board. These first two patches make working with this setup
easier, the third adds a defconfig to demonstrate a minimal bootable
U-Boot setup.

Fiona Klute (WIWA) (3):
  board/raspberrypi: Support boot.scr for U-Boot
  board/raspberrypi: allow non-matching globs for DTBs
  configs/raspberrypicm4io_64_uboot_defconfig: new defconfig

 board/raspberrypi/boot.scr.in                 | 18 +++++++++
 .../raspberrypi/config_cm4io_64bit_uboot.txt  | 23 +++++++++++
 board/raspberrypi/post-image.sh               |  8 ++++
 board/raspberrypi/readme.txt                  |  4 ++
 configs/raspberrypicm4io_64_uboot_defconfig   | 40 +++++++++++++++++++
 5 files changed, 93 insertions(+)
 create mode 100644 board/raspberrypi/boot.scr.in
 create mode 100644 board/raspberrypi/config_cm4io_64bit_uboot.txt
 create mode 100644 configs/raspberrypicm4io_64_uboot_defconfig

-- 
2.47.2

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v3 1/3] board/raspberrypi: Support boot.scr for U-Boot

[Fiona Klute via buildroot]

From: "Fiona Klute (WIWA)" <fiona.klute@gmx.de>

If using U-Boot as "kernel" for the raspberrypi bootloader, include
boot.scr in the boot partition if it exists.

To use this, use BR2_PACKAGE_RPI_FIRMWARE_CONFIG_FILE to set a config
file that uses U-Boot, and enable building a boot script in the U-Boot
host tool settings.

Signed-off-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
Reviewed-by: Yann E. MORIN <yann.morin.1998@free.fr>
Tested-by: Gaël PORTAY <gael.portay+rtone@gmail.com>
---
 board/raspberrypi/post-image.sh | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/board/raspberrypi/post-image.sh b/board/raspberrypi/post-image.sh
index 9b9eac972b..e4611d05dd 100755
--- a/board/raspberrypi/post-image.sh
+++ b/board/raspberrypi/post-image.sh
@@ -19,6 +19,12 @@ if [ ! -e "${GENIMAGE_CFG}" ]; then
 	KERNEL=$(sed -n 's/^kernel=//p' "${BINARIES_DIR}/rpi-firmware/config.txt")
 	FILES+=( "${KERNEL}" )
 
+	# If config.txt calls for running U-Boot, include the boot
+	# script if any.
+	if [ "${KERNEL}" = "u-boot.bin" ] && [ -e "${BINARIES_DIR}/boot.scr" ]; then
+		FILES+=( "boot.scr" )
+	fi
+
 	BOOT_FILES=$(printf '\\t\\t\\t"%s",\\n' "${FILES[@]}")
 	sed "s|#BOOT_FILES#|${BOOT_FILES}|" "${BOARD_DIR}/genimage.cfg.in" \
 		> "${GENIMAGE_CFG}"
-- 
2.47.2

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v3 2/3] board/raspberrypi: allow non-matching globs for DTBs

[Fiona Klute via buildroot]

From: "Fiona Klute (WIWA)" <fiona.klute@gmx.de>

When installing DTBs from the rpi-firmware package
(BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTBS=y), there's no DTB directly in
the images directory because the kernel build doesn't provide one.

Using pre-compiled DTBs is discouraged, but useful for using mainline
kernels until suitable DTS can be merged, or to provide U-Boot with a
DTB (via the firmware bootloader) independent of whatever kernel DTB
is in use.

Signed-off-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
Reviewed-by: Gaël PORTAY <gael.portay+rtone@gmail.com>
---
Changes v1 -> v2:
* Check for existance of paths returned by the DTB glob expressions
  instead of changing shell glob behavior

 board/raspberrypi/post-image.sh | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/board/raspberrypi/post-image.sh b/board/raspberrypi/post-image.sh
index e4611d05dd..a3a2d8d620 100755
--- a/board/raspberrypi/post-image.sh
+++ b/board/raspberrypi/post-image.sh
@@ -13,6 +13,8 @@ if [ ! -e "${GENIMAGE_CFG}" ]; then
 	FILES=()
 
 	for i in "${BINARIES_DIR}"/*.dtb "${BINARIES_DIR}"/rpi-firmware/*; do
+		# ignore literal globs that didn't match anything
+		[ -e "${i}" ] || continue
 		FILES+=( "${i#${BINARIES_DIR}/}" )
 	done
 
-- 
2.47.2

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v3 2/3] board/raspberrypi: allow non-matching globs for DTBs

[Niklas Cassel via buildroot]

Hello Fiona,

On Fri, Feb 07, 2025 at 06:14:57PM +0100, Fiona Klute via buildroot wrote:
> From: "Fiona Klute (WIWA)" <fiona.klute@gmx.de>
> 
> When installing DTBs from the rpi-firmware package
> (BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTBS=y), there's no DTB directly in
> the images directory because the kernel build doesn't provide one.

Your new defconfig does not seem to have BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTBS
set. What am I missing?

Regardless, perhaps clarify/rephrase your commit message.


> 
> Using pre-compiled DTBs is discouraged, but useful for using mainline
> kernels until suitable DTS can be merged, or to provide U-Boot with a
> DTB (via the firmware bootloader) independent of whatever kernel DTB
> is in use.

I don't really understand which pre-compiled DTB you are using, since
your series is not adding any DTB, and your defconfig does not have
BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTBS set.

However, wouldn't it be much better to rebase this series on either:

1) Romain's series:
https://lore.kernel.org/buildroot/20250204163622.192932-3-romain.naour@smile.fr/
which introduces BR2_LINUX_KERNEL_CUSTOM_DTS_PATH

or

2) Your own series:
https://lore.kernel.org/buildroot/20250207183455.1468220-1-fiona.klute@gmx.de/


Then this series could provide a DT source file (.dts) instead of a binary
blob (.dtb). Having a DTS file would make it easier for other buildroot
contributors to make changes, and once upstream has a DTS merged, you can
remove your DTS file provided by buildroot.


Kind regards,
Niklas
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v3 2/3] board/raspberrypi: allow non-matching globs for DTBs

[Fiona Klute via buildroot]

Hi Niklas!

Am 10.02.25 um 13:47 schrieb Niklas Cassel:
> On Fri, Feb 07, 2025 at 06:14:57PM +0100, Fiona Klute via buildroot wrote:
>> From: "Fiona Klute (WIWA)" <fiona.klute@gmx.de>
>>
>> When installing DTBs from the rpi-firmware package
>> (BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTBS=y), there's no DTB directly in
>> the images directory because the kernel build doesn't provide one.
>
> Your new defconfig does not seem to have BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTBS
> set. What am I missing?

This change is independent of the defconfig, which is aimed at a board
that's well supported by in-tree DTS (both mainline and RPi downstream).
The only connection is that both are about support for RPi boards.

> Regardless, perhaps clarify/rephrase your commit message.

What needs clarifying in your opinion?

>> Using pre-compiled DTBs is discouraged, but useful for using mainline
>> kernels until suitable DTS can be merged, or to provide U-Boot with a
>> DTB (via the firmware bootloader) independent of whatever kernel DTB
>> is in use.
>
> I don't really understand which pre-compiled DTB you are using, since
> your series is not adding any DTB, and your defconfig does not have
> BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTBS set.
>
> However, wouldn't it be much better to rebase this series on either:
>
> 1) Romain's series:
> https://lore.kernel.org/buildroot/20250204163622.192932-3-romain.naour@smile.fr/
> which introduces BR2_LINUX_KERNEL_CUSTOM_DTS_PATH
>
> or
>
> 2) Your own series:
> https://lore.kernel.org/buildroot/20250207183455.1468220-1-fiona.klute@gmx.de/
>
>
> Then this series could provide a DT source file (.dts) instead of a binary
> blob (.dtb). Having a DTS file would make it easier for other buildroot
> contributors to make changes, and once upstream has a DTS merged, you can
> remove your DTS file provided by buildroot.

This patch has nothing to do with either series. Both of those series
aim to support building out-of-tree DTS and installing the resulting DTB.

This patch allows the post-image script to work if the user does not
have the kernel (or tools added by one of those series) build a DTB, and
instead sets BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTBS=y. If they have a
suitable DTS to build, there's no point in using that option. The
rpi-firmware package installs its pre-compiled DTBs into
"${BINARIES_DIR}"/rpi-firmware/, so the "${BINARIES_DIR}"/*.dtb glob
won't match anything, and including the literal glob in the FILES list
will lead to "file not found" errors.

In short: The purpose of this patch is only to make
BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTBS=y work without forcing the user to
adjust the post-image script.

Best regards,
Fiona

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v3 2/3] board/raspberrypi: allow non-matching globs for DTBs

[Niklas Cassel]

On Mon, Feb 17, 2025 at 01:33:52PM +0100, Fiona Klute wrote:
> Hi Niklas!
> 
> Am 10.02.25 um 13:47 schrieb Niklas Cassel:
> > On Fri, Feb 07, 2025 at 06:14:57PM +0100, Fiona Klute via buildroot wrote:
> > > From: "Fiona Klute (WIWA)" <fiona.klute@gmx.de>
> > > 
> > > When installing DTBs from the rpi-firmware package
> > > (BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTBS=y), there's no DTB directly in
> > > the images directory because the kernel build doesn't provide one.
> > 
> > Your new defconfig does not seem to have BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTBS
> > set. What am I missing?
> 
> This change is independent of the defconfig, which is aimed at a board
> that's well supported by in-tree DTS (both mainline and RPi downstream).
> The only connection is that both are about support for RPi boards.
> 
> > Regardless, perhaps clarify/rephrase your commit message.
> 
> What needs clarifying in your opinion?

This series adds a new defconfig:
configs/raspberrypicm4io_64_uboot_defconfig

Since these 3 patches are in a series, it is logical that patches 1-2 are
actually needed for patch 3.

The commit message in patch 2 references
BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTBS=y
However, the defconfig in patch 3 does not select this config.

So, if patch 2 is completely unrelated to patch 3, why submit it in the
same series?


After looking at package/rpi-firmware/Config.in it appears that
BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTBS is "default y"
(and you new defconfig does select BR2_PACKAGE_RPI_FIRMWARE).

So I guess the answer is: because package/rpi-firmware/Config.in is silly.

A config option to install something is usually never "default y".
To me it is very counter-intuitive that defconfigs that want firmware
installed, but do not want DTBs installed would have to do:
BR2_PACKAGE_RPI_FIRMWARE=y
# BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTBS is not set

Rather than configs that want both installed would do:
BR2_PACKAGE_RPI_FIRMWARE=y
BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTBS=y

But this is unrelated to you series, so feel free to ignore my comment.


> 
> > > Using pre-compiled DTBs is discouraged, but useful for using mainline
> > > kernels until suitable DTS can be merged, or to provide U-Boot with a
> > > DTB (via the firmware bootloader) independent of whatever kernel DTB
> > > is in use.
> > 
> > I don't really understand which pre-compiled DTB you are using, since
> > your series is not adding any DTB, and your defconfig does not have
> > BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTBS set.
> > 
> > However, wouldn't it be much better to rebase this series on either:
> > 
> > 1) Romain's series:
> > https://lore.kernel.org/buildroot/20250204163622.192932-3-romain.naour@smile.fr/
> > which introduces BR2_LINUX_KERNEL_CUSTOM_DTS_PATH
> > 
> > or
> > 
> > 2) Your own series:
> > https://lore.kernel.org/buildroot/20250207183455.1468220-1-fiona.klute@gmx.de/
> > 
> > 
> > Then this series could provide a DT source file (.dts) instead of a binary
> > blob (.dtb). Having a DTS file would make it easier for other buildroot
> > contributors to make changes, and once upstream has a DTS merged, you can
> > remove your DTS file provided by buildroot.
> 
> This patch has nothing to do with either series. Both of those series
> aim to support building out-of-tree DTS and installing the resulting DTB.
> 
> This patch allows the post-image script to work if the user does not
> have the kernel (or tools added by one of those series) build a DTB, and
> instead sets BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTBS=y. If they have a
> suitable DTS to build, there's no point in using that option. The
> rpi-firmware package installs its pre-compiled DTBs into
> "${BINARIES_DIR}"/rpi-firmware/, so the "${BINARIES_DIR}"/*.dtb glob
> won't match anything, and including the literal glob in the FILES list
> will lead to "file not found" errors.
> 
> In short: The purpose of this patch is only to make
> BR2_PACKAGE_RPI_FIRMWARE_INSTALL_DTBS=y work without forcing the user to
> adjust the post-image script.

Ok, thank you for clarifying.


Kind regards,
Niklas
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH v3 3/3] configs/raspberrypicm4io_64_uboot_defconfig: new defconfig

[Fiona Klute via buildroot]

From: "Fiona Klute (WIWA)" <fiona.klute@gmx.de>

The new config deviates from the existing
configs/raspberrypicm4io_64_defconfig only as far as necessary to
demonstrate booting through U-Boot instead of having the firmware load
the kernel directly. The sample boot script loads the kernel from the
rootfs and uses the device tree provided by the firmware, and should
be compatible with any RPi device that runs U-Boot.

Signed-off-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
---
The config I'm usually using is a bit different, including using a
mainline kernel (which seems strongly preferable to me), but for
defconfig maintenance staying close to the other RPi defconfigs is
probably easiest.

Changes v2 -> v3:
* Regenerate defconfig according to current standards
* Modify boot.scr.in so the script should work on any RPi device

 board/raspberrypi/boot.scr.in                 | 18 +++++++++
 .../raspberrypi/config_cm4io_64bit_uboot.txt  | 23 +++++++++++
 board/raspberrypi/readme.txt                  |  4 ++
 configs/raspberrypicm4io_64_uboot_defconfig   | 40 +++++++++++++++++++
 4 files changed, 85 insertions(+)
 create mode 100644 board/raspberrypi/boot.scr.in
 create mode 100644 board/raspberrypi/config_cm4io_64bit_uboot.txt
 create mode 100644 configs/raspberrypicm4io_64_uboot_defconfig

diff --git a/board/raspberrypi/boot.scr.in b/board/raspberrypi/boot.scr.in
new file mode 100644
index 0000000000..1ba733ceaa
--- /dev/null
+++ b/board/raspberrypi/boot.scr.in
@@ -0,0 +1,18 @@
+# Please note that this is only a sample, we recommend you to change
+# it to fit your needs. You should override this file using
+# BR2_PACKAGE_HOST_UBOOT_TOOLS_BOOT_SCRIPT_SOURCE.
+
+# On most Raspberry Pi boards UART0 is ttyAMA0, Raspberry Pi 5 is
+# different.
+if test "$board_name" = "5 Model B"; then
+    env set serial_uart "ttyAMA10,115200"
+else
+    env set serial_uart "ttyAMA0,115200"
+fi
+env set bootargs "root=/dev/mmcblk0p2 rootwait console=tty1 console=${serial_uart}"
+
+# load kernel from the root partition
+load mmc 0:2 ${kernel_addr_r} boot/Image
+
+# boot using the FDT provided by firmware
+booti ${kernel_addr_r} - ${fdt_addr}
diff --git a/board/raspberrypi/config_cm4io_64bit_uboot.txt b/board/raspberrypi/config_cm4io_64bit_uboot.txt
new file mode 100644
index 0000000000..eef929186c
--- /dev/null
+++ b/board/raspberrypi/config_cm4io_64bit_uboot.txt
@@ -0,0 +1,23 @@
+# Please note that this is only a sample, we recommend you to change it to fit
+# your needs.
+# You should override this file using BR2_PACKAGE_RPI_FIRMWARE_CONFIG_FILE.
+# See http://buildroot.org/manual.html#rootfs-custom
+# and http://elinux.org/RPiconfig for a description of config.txt syntax
+
+start_file=start4.elf
+fixup_file=fixup4.dat
+
+kernel=u-boot.bin
+
+# Enable UART0 for serial console on ttyAMA0
+dtoverlay=miniuart-bt
+
+# enable RTC
+dtparam=i2c_vc=on
+dtoverlay=i2c-rtc,pcf85063a,i2c_csi_dsi
+
+# enable dwc2 USB controller (USB 2.0)
+dtoverlay=dwc2,dr_mode=host
+
+# enable 64bits support
+arm_64bit=1
diff --git a/board/raspberrypi/readme.txt b/board/raspberrypi/readme.txt
index 64f0e2a26f..6bf76df2ef 100644
--- a/board/raspberrypi/readme.txt
+++ b/board/raspberrypi/readme.txt
@@ -69,6 +69,10 @@ or for CM4 (on IO Board - 64 bit):
 
   $ make raspberrypicm4io_64_defconfig
 
+or to boot CM4 (on IO Board - 64 bit) using U-Boot:
+
+  $ make raspberrypicm4io_64_uboot_defconfig
+
 For model 5 B:
 
   $ make raspberrypi5_defconfig
diff --git a/configs/raspberrypicm4io_64_uboot_defconfig b/configs/raspberrypicm4io_64_uboot_defconfig
new file mode 100644
index 0000000000..056c9051b6
--- /dev/null
+++ b/configs/raspberrypicm4io_64_uboot_defconfig
@@ -0,0 +1,40 @@
+BR2_aarch64=y
+BR2_cortex_a72=y
+BR2_ARM_FPU_VFPV4=y
+BR2_TOOLCHAIN_EXTERNAL=y
+BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
+BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_AARCH64_GLIBC_STABLE=y
+BR2_GLOBAL_PATCH_DIR="board/raspberrypi/patches"
+BR2_DOWNLOAD_FORCE_CHECK_HASHES=y
+BR2_SYSTEM_DHCP="eth0"
+BR2_ROOTFS_POST_BUILD_SCRIPT="board/raspberrypicm4io-64/post-build.sh"
+BR2_ROOTFS_POST_IMAGE_SCRIPT="board/raspberrypicm4io-64/post-image.sh"
+BR2_LINUX_KERNEL=y
+BR2_LINUX_KERNEL_CUSTOM_TARBALL=y
+BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION="$(call github,raspberrypi,linux,576cc10e1ed50a9eacffc7a05c796051d7343ea4)/linux-576cc10e1ed50a9eacffc7a05c796051d7343ea4.tar.gz"
+BR2_LINUX_KERNEL_DEFCONFIG="bcm2711"
+BR2_LINUX_KERNEL_DTS_SUPPORT=y
+BR2_LINUX_KERNEL_INTREE_DTS_NAME="broadcom/bcm2711-rpi-cm4"
+BR2_LINUX_KERNEL_INSTALL_TARGET=y
+BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y
+BR2_PACKAGE_BUSYBOX_SHOW_OTHERS=y
+BR2_PACKAGE_XZ=y
+BR2_PACKAGE_RPI_FIRMWARE=y
+BR2_PACKAGE_RPI_FIRMWARE_VARIANT_PI4=y
+BR2_PACKAGE_RPI_FIRMWARE_CONFIG_FILE="board/raspberrypicm4io-64/config_cm4io_64bit_uboot.txt"
+BR2_PACKAGE_KMOD=y
+BR2_PACKAGE_KMOD_TOOLS=y
+BR2_TARGET_ROOTFS_EXT2=y
+BR2_TARGET_ROOTFS_EXT2_4=y
+BR2_TARGET_ROOTFS_EXT2_SIZE="120M"
+# BR2_TARGET_ROOTFS_TAR is not set
+BR2_TARGET_UBOOT=y
+BR2_TARGET_UBOOT_BOARD_DEFCONFIG="rpi_arm64"
+BR2_PACKAGE_HOST_DOSFSTOOLS=y
+BR2_PACKAGE_HOST_GENIMAGE=y
+BR2_PACKAGE_HOST_KMOD_XZ=y
+BR2_PACKAGE_HOST_MTOOLS=y
+BR2_PACKAGE_HOST_RASPBERRYPI_USBBOOT=y
+BR2_PACKAGE_HOST_UBOOT_TOOLS=y
+BR2_PACKAGE_HOST_UBOOT_TOOLS_BOOT_SCRIPT=y
+BR2_PACKAGE_HOST_UBOOT_TOOLS_BOOT_SCRIPT_SOURCE="board/raspberrypicm4io-64/boot.scr.in"
-- 
2.47.2

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v3 3/3] configs/raspberrypicm4io_64_uboot_defconfig: new defconfig

[Arnout Vandecappelle via buildroot]

  Hi Fiona,

On 07/02/2025 18:14, Fiona Klute via buildroot wrote:
> From: "Fiona Klute (WIWA)" <fiona.klute@gmx.de>
> 
> The new config deviates from the existing
> configs/raspberrypicm4io_64_defconfig only as far as necessary to
> demonstrate booting through U-Boot instead of having the firmware load
> the kernel directly. The sample boot script loads the kernel from the
> rootfs and uses the device tree provided by the firmware, and should
> be compatible with any RPi device that runs U-Boot.

  Looks good at first sight. I'm thinking though: wouldn't it be easier if we 
convert all RPi configs (gradually) to U-Boot, and mention in the readme (and 
config.txt comments) how to boot without U-Boot?

> 
> Signed-off-by: Fiona Klute (WIWA) <fiona.klute@gmx.de>
> ---
> The config I'm usually using is a bit different, including using a
> mainline kernel (which seems strongly preferable to me), but for
> defconfig maintenance staying close to the other RPi defconfigs is
> probably easiest.

  We actually discussed the "rule" for whether or not to use upstream kernels in 
the Vienna dev days last year [1]. This hasn't made it into the manual yet 
unfortunately.

 >>>> There is often a choice between vendor kernel (and U-Boot, and graphics) or
 >>>> mainline kernel (and U-Boot, and mesa3d). It's up to the contributor to
 >>>> choose. We can also have two defconfigs for the same board, one vendor and
 >>>> one mainline. In that case, the vendor variant should be called
 >>>> <board>_vendor_defconfig. Nobody volunteered to do this rename for the
 >>>> existing defconfigs.

  I don't know if nowadays there is still a need to use vendor kernels on the 
RPies. In the past it used to be the case that the RPi used all kinds of 
non-standard userspace APIs with the result that all online guides stop working 
if you use a mainline kernel - I don't know if that is still the case. But 
anyway, adding a mainline defconfig is certainly a good idea IMHO.

  Regards,
  Arnout

[1] https://elinux.org/Buildroot:DeveloperDaysELCE2024#Rules_for_defconfigs


> 
> Changes v2 -> v3:
> * Regenerate defconfig according to current standards
> * Modify boot.scr.in so the script should work on any RPi device
> 
>   board/raspberrypi/boot.scr.in                 | 18 +++++++++
>   .../raspberrypi/config_cm4io_64bit_uboot.txt  | 23 +++++++++++
>   board/raspberrypi/readme.txt                  |  4 ++
>   configs/raspberrypicm4io_64_uboot_defconfig   | 40 +++++++++++++++++++
>   4 files changed, 85 insertions(+)
>   create mode 100644 board/raspberrypi/boot.scr.in
>   create mode 100644 board/raspberrypi/config_cm4io_64bit_uboot.txt
>   create mode 100644 configs/raspberrypicm4io_64_uboot_defconfig
> 
> diff --git a/board/raspberrypi/boot.scr.in b/board/raspberrypi/boot.scr.in
> new file mode 100644
> index 0000000000..1ba733ceaa
> --- /dev/null
> +++ b/board/raspberrypi/boot.scr.in
> @@ -0,0 +1,18 @@
> +# Please note that this is only a sample, we recommend you to change
> +# it to fit your needs. You should override this file using
> +# BR2_PACKAGE_HOST_UBOOT_TOOLS_BOOT_SCRIPT_SOURCE.
> +
> +# On most Raspberry Pi boards UART0 is ttyAMA0, Raspberry Pi 5 is
> +# different.
> +if test "$board_name" = "5 Model B"; then
> +    env set serial_uart "ttyAMA10,115200"
> +else
> +    env set serial_uart "ttyAMA0,115200"
> +fi
> +env set bootargs "root=/dev/mmcblk0p2 rootwait console=tty1 console=${serial_uart}"
> +
> +# load kernel from the root partition
> +load mmc 0:2 ${kernel_addr_r} boot/Image
> +
> +# boot using the FDT provided by firmware
> +booti ${kernel_addr_r} - ${fdt_addr}
> diff --git a/board/raspberrypi/config_cm4io_64bit_uboot.txt b/board/raspberrypi/config_cm4io_64bit_uboot.txt
> new file mode 100644
> index 0000000000..eef929186c
> --- /dev/null
> +++ b/board/raspberrypi/config_cm4io_64bit_uboot.txt
> @@ -0,0 +1,23 @@
> +# Please note that this is only a sample, we recommend you to change it to fit
> +# your needs.
> +# You should override this file using BR2_PACKAGE_RPI_FIRMWARE_CONFIG_FILE.
> +# See http://buildroot.org/manual.html#rootfs-custom
> +# and http://elinux.org/RPiconfig for a description of config.txt syntax
> +
> +start_file=start4.elf
> +fixup_file=fixup4.dat
> +
> +kernel=u-boot.bin
> +
> +# Enable UART0 for serial console on ttyAMA0
> +dtoverlay=miniuart-bt
> +
> +# enable RTC
> +dtparam=i2c_vc=on
> +dtoverlay=i2c-rtc,pcf85063a,i2c_csi_dsi
> +
> +# enable dwc2 USB controller (USB 2.0)
> +dtoverlay=dwc2,dr_mode=host
> +
> +# enable 64bits support
> +arm_64bit=1
> diff --git a/board/raspberrypi/readme.txt b/board/raspberrypi/readme.txt
> index 64f0e2a26f..6bf76df2ef 100644
> --- a/board/raspberrypi/readme.txt
> +++ b/board/raspberrypi/readme.txt
> @@ -69,6 +69,10 @@ or for CM4 (on IO Board - 64 bit):
>   
>     $ make raspberrypicm4io_64_defconfig
>   
> +or to boot CM4 (on IO Board - 64 bit) using U-Boot:
> +
> +  $ make raspberrypicm4io_64_uboot_defconfig
> +
>   For model 5 B:
>   
>     $ make raspberrypi5_defconfig
> diff --git a/configs/raspberrypicm4io_64_uboot_defconfig b/configs/raspberrypicm4io_64_uboot_defconfig
> new file mode 100644
> index 0000000000..056c9051b6
> --- /dev/null
> +++ b/configs/raspberrypicm4io_64_uboot_defconfig
> @@ -0,0 +1,40 @@
> +BR2_aarch64=y
> +BR2_cortex_a72=y
> +BR2_ARM_FPU_VFPV4=y
> +BR2_TOOLCHAIN_EXTERNAL=y
> +BR2_TOOLCHAIN_EXTERNAL_BOOTLIN=y
> +BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_AARCH64_GLIBC_STABLE=y
> +BR2_GLOBAL_PATCH_DIR="board/raspberrypi/patches"
> +BR2_DOWNLOAD_FORCE_CHECK_HASHES=y
> +BR2_SYSTEM_DHCP="eth0"
> +BR2_ROOTFS_POST_BUILD_SCRIPT="board/raspberrypicm4io-64/post-build.sh"
> +BR2_ROOTFS_POST_IMAGE_SCRIPT="board/raspberrypicm4io-64/post-image.sh"
> +BR2_LINUX_KERNEL=y
> +BR2_LINUX_KERNEL_CUSTOM_TARBALL=y
> +BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION="$(call github,raspberrypi,linux,576cc10e1ed50a9eacffc7a05c796051d7343ea4)/linux-576cc10e1ed50a9eacffc7a05c796051d7343ea4.tar.gz"
> +BR2_LINUX_KERNEL_DEFCONFIG="bcm2711"
> +BR2_LINUX_KERNEL_DTS_SUPPORT=y
> +BR2_LINUX_KERNEL_INTREE_DTS_NAME="broadcom/bcm2711-rpi-cm4"
> +BR2_LINUX_KERNEL_INSTALL_TARGET=y
> +BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y
> +BR2_PACKAGE_BUSYBOX_SHOW_OTHERS=y
> +BR2_PACKAGE_XZ=y
> +BR2_PACKAGE_RPI_FIRMWARE=y
> +BR2_PACKAGE_RPI_FIRMWARE_VARIANT_PI4=y
> +BR2_PACKAGE_RPI_FIRMWARE_CONFIG_FILE="board/raspberrypicm4io-64/config_cm4io_64bit_uboot.txt"
> +BR2_PACKAGE_KMOD=y
> +BR2_PACKAGE_KMOD_TOOLS=y
> +BR2_TARGET_ROOTFS_EXT2=y
> +BR2_TARGET_ROOTFS_EXT2_4=y
> +BR2_TARGET_ROOTFS_EXT2_SIZE="120M"
> +# BR2_TARGET_ROOTFS_TAR is not set
> +BR2_TARGET_UBOOT=y
> +BR2_TARGET_UBOOT_BOARD_DEFCONFIG="rpi_arm64"
> +BR2_PACKAGE_HOST_DOSFSTOOLS=y
> +BR2_PACKAGE_HOST_GENIMAGE=y
> +BR2_PACKAGE_HOST_KMOD_XZ=y
> +BR2_PACKAGE_HOST_MTOOLS=y
> +BR2_PACKAGE_HOST_RASPBERRYPI_USBBOOT=y
> +BR2_PACKAGE_HOST_UBOOT_TOOLS=y
> +BR2_PACKAGE_HOST_UBOOT_TOOLS_BOOT_SCRIPT=y
> +BR2_PACKAGE_HOST_UBOOT_TOOLS_BOOT_SCRIPT_SOURCE="board/raspberrypicm4io-64/boot.scr.in"

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v3 3/3] configs/raspberrypicm4io_64_uboot_defconfig: new defconfig

[bryce.schober]

[-- Attachment #1.1: Type: text/plain, Size: 763 bytes --]

Hi Arnout,

On Fri, Feb 7, 2025 at 1:37 PM Arnout Vandecappelle via buildroot <
buildroot@buildroot.org> wrote:

>   Looks good at first sight. I'm thinking though: wouldn't it be easier if
> we
> convert all RPi configs (gradually) to U-Boot, and mention in the readme
> (and
> config.txt comments) how to boot without U-Boot?
>

FYI, U-Boot doesn't support the RPi PCI/NVMe interface because of a current
lack of support in the upstream kernel. So we are actually moving away from
U-Boot in a previous project toward using the rpi firmware support for
integrating with A/B update systems. I'm not saying that it has to be easy
for people like us, I'm just chiming in with the fact that U-Boot isn't
always the best answer for all use cases.

[-- Attachment #1.2: Type: text/html, Size: 1241 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v3 3/3] configs/raspberrypicm4io_64_uboot_defconfig: new defconfig

[Arnout Vandecappelle via buildroot]

On 07/02/2025 23:36, bryce.schober@gmail.com wrote:
> 
> Hi Arnout,
> 
> On Fri, Feb 7, 2025 at 1:37 PM Arnout Vandecappelle via buildroot 
> <buildroot@buildroot.org <mailto:buildroot@buildroot.org>> wrote:
> 
>        Looks good at first sight. I'm thinking though: wouldn't it be easier if we
>     convert all RPi configs (gradually) to U-Boot, and mention in the readme (and
>     config.txt comments) how to boot without U-Boot?
> 
> 
> FYI, U-Boot doesn't support the RPi PCI/NVMe interface because of a current lack 
> of support in the upstream kernel. So we are actually moving away from U-Boot in 
> a previous project toward using the rpi firmware support for integrating with A/ 
> B update systems. I'm not saying that it has to be easy for people like us, I'm 
> just chiming in with the fact that U-Boot isn't always the best answer for all 
> use cases.

  What I had in mind is: _removing_ U-Boot is actually quite easy, you just need 
to change two lines in the config.txt (AFAIU). Thus, it makes sense to me that 
our defconfigs should all have U-Boot, and the readme.txt can explain how to 
build without U-Boot.

  Regards,
  Arnout

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v3 3/3] configs/raspberrypicm4io_64_uboot_defconfig: new defconfig

[Fiona Klute via buildroot]

Am 10.02.25 um 08:44 schrieb Arnout Vandecappelle:
>
>
> On 07/02/2025 23:36, bryce.schober@gmail.com wrote:
>>
>> Hi Arnout,
>>
>> On Fri, Feb 7, 2025 at 1:37 PM Arnout Vandecappelle via buildroot
>> <buildroot@buildroot.org <mailto:buildroot@buildroot.org>> wrote:
>>
>>        Looks good at first sight. I'm thinking though: wouldn't it be
>> easier if we
>>     convert all RPi configs (gradually) to U-Boot, and mention in the
>> readme (and
>>     config.txt comments) how to boot without U-Boot?
>>
>>
>> FYI, U-Boot doesn't support the RPi PCI/NVMe interface because of a
>> current lack of support in the upstream kernel. So we are actually
>> moving away from U-Boot in a previous project toward using the rpi
>> firmware support for integrating with A/ B update systems. I'm not
>> saying that it has to be easy for people like us, I'm just chiming in
>> with the fact that U-Boot isn't always the best answer for all use cases.
>
>   What I had in mind is: _removing_ U-Boot is actually quite easy, you
> just need to change two lines in the config.txt (AFAIU). Thus, it makes
> sense to me that our defconfigs should all have U-Boot, and the
> readme.txt can explain how to build without U-Boot.
That makes sense to me, maintaining defconfigs for a full matrix of
board type/mainline or downstream kernel/u-boot or not doesn't seem
practical. Maybe it'd make sense to have a standard, and one example for
each of the possible deviations?

And maybe mention possible pitfalls in the readme as far as known, e.g.
I recently bumped into different kernel config options to make the
microSD slot on Pi Zero 2W work (result: kernel can't find rootfs if you
switch between downstream and mainline and reuse the config).

Best regards,
Fiona

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH v3 3/3] configs/raspberrypicm4io_64_uboot_defconfig: new defconfig

[Arnout Vandecappelle via buildroot]

On 13/02/2025 20:25, Fiona Klute wrote:
> Am 10.02.25 um 08:44 schrieb Arnout Vandecappelle:
>>
>>
>> On 07/02/2025 23:36, bryce.schober@gmail.com wrote:
>>>
>>> Hi Arnout,
>>>
>>> On Fri, Feb 7, 2025 at 1:37 PM Arnout Vandecappelle via buildroot
>>> <buildroot@buildroot.org <mailto:buildroot@buildroot.org>> wrote:
>>>
>>>        Looks good at first sight. I'm thinking though: wouldn't it be
>>> easier if we
>>>     convert all RPi configs (gradually) to U-Boot, and mention in the
>>> readme (and
>>>     config.txt comments) how to boot without U-Boot?
>>>
>>>
>>> FYI, U-Boot doesn't support the RPi PCI/NVMe interface because of a
>>> current lack of support in the upstream kernel. So we are actually
>>> moving away from U-Boot in a previous project toward using the rpi
>>> firmware support for integrating with A/ B update systems. I'm not
>>> saying that it has to be easy for people like us, I'm just chiming in
>>> with the fact that U-Boot isn't always the best answer for all use cases.
>>
>>   What I had in mind is: _removing_ U-Boot is actually quite easy, you
>> just need to change two lines in the config.txt (AFAIU). Thus, it makes
>> sense to me that our defconfigs should all have U-Boot, and the
>> readme.txt can explain how to build without U-Boot.
> That makes sense to me, maintaining defconfigs for a full matrix of
> board type/mainline or downstream kernel/u-boot or not doesn't seem
> practical. Maybe it'd make sense to have a standard, and one example for
> each of the possible deviations?
> 
> And maybe mention possible pitfalls in the readme as far as known, e.g.
> I recently bumped into different kernel config options to make the
> microSD slot on Pi Zero 2W work (result: kernel can't find rootfs if you
> switch between downstream and mainline and reuse the config).

  Indeed, switching between mainline and vendor kernel is typically more 
complicated, so it makes sense to have a separate defconfig. That's also what we 
decided in the Developer Meeting in September [1].

  However, switching between U-Boot and no u-boot is AFAIU just a matter of 
changing two lines in the config.txt.

  Regards,
  Arnout

[1] https://elinux.org/Buildroot:DeveloperDaysELCE2024#Rules_for_defconfigs


_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot