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

[Buildroot] [PATCH next v2 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                 |  9 +++
 .../raspberrypi/config_cm4io_64bit_uboot.txt  | 23 +++++++
 board/raspberrypi/post-image.sh               |  8 +++
 board/raspberrypi/readme.txt                  |  4 ++
 configs/raspberrypicm4io_64_uboot_defconfig   | 60 +++++++++++++++++++
 5 files changed, 104 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.45.2

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

[Buildroot] [PATCH next v2 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>
---
 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.45.2

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

[Buildroot] [PATCH next v2 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>
---
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.45.2

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

[Buildroot] [PATCH next v2 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.

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.

 board/raspberrypi/boot.scr.in                 |  9 +++
 .../raspberrypi/config_cm4io_64bit_uboot.txt  | 23 +++++++
 board/raspberrypi/readme.txt                  |  4 ++
 configs/raspberrypicm4io_64_uboot_defconfig   | 60 +++++++++++++++++++
 4 files changed, 96 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..a5c986ef99
--- /dev/null
+++ b/board/raspberrypi/boot.scr.in
@@ -0,0 +1,9 @@
+# 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.
+
+# load kernel from the root partition
+load mmc 0:2 ${kernel_addr_r} boot/Image
+env set bootargs "root=/dev/mmcblk0p2 rootwait console=tty1 console=ttyAMA0,115200"
+# 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 81cd81a7f3..dc5216b088 100644
--- a/board/raspberrypi/readme.txt
+++ b/board/raspberrypi/readme.txt
@@ -65,6 +65,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..b3b35479d3
--- /dev/null
+++ b/configs/raspberrypicm4io_64_uboot_defconfig
@@ -0,0 +1,60 @@
+BR2_aarch64=y
+BR2_cortex_a72=y
+BR2_ARM_FPU_VFPV4=y
+
+# patches
+BR2_GLOBAL_PATCH_DIR="board/raspberrypi/patches"
+BR2_DOWNLOAD_FORCE_CHECK_HASHES=y
+
+BR2_SYSTEM_DHCP="eth0"
+
+# Linux headers same as kernel, a 6.6 series
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_6=y
+
+BR2_TOOLCHAIN_BUILDROOT_CXX=y
+
+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"
+
+# Install kernel to rootfs so U-Boot can load it from there, only
+# U-Boot gets included in the /boot partition.
+BR2_LINUX_KERNEL_INSTALL_TARGET=y
+BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=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"
+
+# Required tools to create the SD image
+BR2_PACKAGE_HOST_DOSFSTOOLS=y
+BR2_PACKAGE_HOST_GENIMAGE=y
+BR2_PACKAGE_HOST_MTOOLS=y
+
+# Required tool to flash CM4 eMMC memory
+BR2_PACKAGE_HOST_RASPBERRYPI_USBBOOT=y
+
+# Filesystem / image
+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_ROOTFS_POST_BUILD_SCRIPT="board/raspberrypicm4io-64/post-build.sh"
+BR2_ROOTFS_POST_IMAGE_SCRIPT="board/raspberrypicm4io-64/post-image.sh"
+
+# Enable compressed kernel module support
+BR2_PACKAGE_BUSYBOX_SHOW_OTHERS=y
+BR2_PACKAGE_KMOD_TOOLS=y
+BR2_PACKAGE_XZ=y
+BR2_PACKAGE_KMOD=y
+BR2_PACKAGE_HOST_KMOD_XZ=y
+
+# U-Boot and tools to build its config script
+BR2_TARGET_UBOOT=y
+BR2_TARGET_UBOOT_BOARD_DEFCONFIG="rpi_arm64"
+BR2_PACKAGE_HOST_UBOOT_TOOLS=y
+BR2_PACKAGE_HOST_UBOOT_TOOLS_BOOT_SCRIPT=y
+BR2_PACKAGE_HOST_UBOOT_TOOLS_BOOT_SCRIPT_SOURCE="board/raspberrypi/boot.scr.in"
--
2.45.2

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

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

[Niklas Cassel via buildroot]

On Sat, Aug 31, 2024 at 09:01:26PM +0200, 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.
> 
> 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.
> 
>  board/raspberrypi/boot.scr.in                 |  9 +++
>  .../raspberrypi/config_cm4io_64bit_uboot.txt  | 23 +++++++
>  board/raspberrypi/readme.txt                  |  4 ++
>  configs/raspberrypicm4io_64_uboot_defconfig   | 60 +++++++++++++++++++
>  4 files changed, 96 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..a5c986ef99
> --- /dev/null
> +++ b/board/raspberrypi/boot.scr.in
> @@ -0,0 +1,9 @@
> +# 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.
> +
> +# load kernel from the root partition
> +load mmc 0:2 ${kernel_addr_r} boot/Image
> +env set bootargs "root=/dev/mmcblk0p2 rootwait console=tty1 console=ttyAMA0,115200"
> +# boot using the FDT provided by firmware
> +booti ${kernel_addr_r} - ${fdt_addr}

Hello Fiona,

While I'm not a u-boot expert, I am slightly surprised to see a new
buildroot defconfig use boot.scr instead of extlinux.conf.

extlinux.conf is the default configuration format in u-boot:
https://github.com/u-boot/u-boot/blob/v2024.10-rc4/doc/develop/distro.rst?plain=1#L69-L71

Even though boot.scr still seems to be supported for backwards-compatibility:
https://github.com/u-boot/u-boot/blob/v2024.10-rc4/doc/develop/distro.rst?plain=1#L367-L368

See e.g. this buildroot commit that converted rock5b from boot.scr to
extlinux.conf:
https://github.com/buildroot/buildroot/commit/b7dbdd3d775b8e94664c6f37b11afc8a6a352e35

I don't see anthing exotic in your boot.scr that wouldn't work with
extlinux.conf.


Although I am I but confused why you set:
BR2_LINUX_KERNEL_INTREE_DTS_NAME="broadcom/bcm2711-rpi-cm4"
but then you do not use this device tree, but rather some
device tree provided by firmware.

What is the point of setting BR2_LINUX_KERNEL_INTREE_DTS_NAME if you
are not using this device tree?

I would strongly suggest to use the device tree that comes with the
kernel version that you are using, as the changes to the device tree
(to enable support for additional hardware in an existing SoC) might
often look different once upstreamed (compared to the downstream device
tree).


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

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

[Fiona Klute via buildroot]

Am 03.09.24 um 13:08 schrieb Niklas Cassel:
> On Sat, Aug 31, 2024 at 09:01:26PM +0200, 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.
>>
>> 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.
>>
>>   board/raspberrypi/boot.scr.in                 |  9 +++
>>   .../raspberrypi/config_cm4io_64bit_uboot.txt  | 23 +++++++
>>   board/raspberrypi/readme.txt                  |  4 ++
>>   configs/raspberrypicm4io_64_uboot_defconfig   | 60 +++++++++++++++++++
>>   4 files changed, 96 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..a5c986ef99
>> --- /dev/null
>> +++ b/board/raspberrypi/boot.scr.in
>> @@ -0,0 +1,9 @@
>> +# 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.
>> +
>> +# load kernel from the root partition
>> +load mmc 0:2 ${kernel_addr_r} boot/Image
>> +env set bootargs "root=/dev/mmcblk0p2 rootwait console=tty1 console=ttyAMA0,115200"
>> +# boot using the FDT provided by firmware
>> +booti ${kernel_addr_r} - ${fdt_addr}
>
> Hello Fiona,
>
> While I'm not a u-boot expert, I am slightly surprised to see a new
> buildroot defconfig use boot.scr instead of extlinux.conf.
>
> extlinux.conf is the default configuration format in u-boot:
> https://github.com/u-boot/u-boot/blob/v2024.10-rc4/doc/develop/distro.rst?plain=1#L69-L71
>
> Even though boot.scr still seems to be supported for backwards-compatibility:
> https://github.com/u-boot/u-boot/blob/v2024.10-rc4/doc/develop/distro.rst?plain=1#L367-L368
>
> See e.g. this buildroot commit that converted rock5b from boot.scr to
> extlinux.conf:
> https://github.com/buildroot/buildroot/commit/b7dbdd3d775b8e94664c6f37b11afc8a6a352e35
>
> I don't see anthing exotic in your boot.scr that wouldn't work with
> extlinux.conf.

Hi Niklas!

Someone who just wants to load a certain kernel will probably stick with
the non-U-Boot variant (raspberrypicm4io_64_defconfig) anyway. ;-) The
point of this defconfig is to be a minimal example that shows the moving
parts for booting an RPi aarch64 device with U-Boot (including a boot
script), so someone who needs the additional flexibility can use it as a
starting point to implement whatever it is they need.

AFAIK things like configuring watchdogs and handling A/B boot slot
selection (with RAUC integration) aren't possible with extlinux.conf,
and a menu isn't going to be much help in a headless system. If there is
a better way than boot.scr to handle those I'd very much like to read
about it.

If there is a way to combine a boot script with extlinux.conf (e.g. set
up a watchdog in the script and set the kernel in extlinux.conf) that
might be interesting and a good addition to this defconfig, too, but I
haven't looked into whether that's possible, and if yes, how.

> Although I am I but confused why you set:
> BR2_LINUX_KERNEL_INTREE_DTS_NAME="broadcom/bcm2711-rpi-cm4"
> but then you do not use this device tree, but rather some
> device tree provided by firmware.
>
> What is the point of setting BR2_LINUX_KERNEL_INTREE_DTS_NAME if you
> are not using this device tree?
>
> I would strongly suggest to use the device tree that comes with the
> kernel version that you are using, as the changes to the device tree
> (to enable support for additional hardware in an existing SoC) might
> often look different once upstreamed (compared to the downstream device
> tree).

That's an oddity of the RPi boot process: The firmware bootloader
expects to find a DTB in the boot partition. By default it'll try
certain names based on the device type, though you can override it in
config.txt. That's why the DTB needs to be built and installed to the
boot partition, but doesn't show up in the U-Boot config.

So what happens with the DT on boot with this defconfig:

1. Firmware loads bcm2711-rpi-cm4.dtb and sets per-device values (e.g.
serial number)
2. Firmware adds overlays if configured to do so (in config.txt)
3. Firmware starts U-Boot, and provides it with the prepared FDT
(flattened device tree)
4. U-Boot uses the FDT for its own setup, this makes it possible to have
a U-Boot build that works on all aarch64 RPi devices, including those
which don't have a dedicated defconfig (like CM4) [1]
5. U-Boot runs the boot script, which tells it to load and boot the
kernel, and provide it with the same FDT U-Boot uses

So the kernel actually gets the DT that was built with it (possibly with
overlays added), just via the firmware. :-)

Sure, you might want to be able to update the DT used for U-Boot
separately from that for the kernel, or separately for different kernel
versions. U-Boot will fill in the per-device values from the FDT
provided by the firmware if you have it load a different DTB.

There's an RPi-specific catch though: The RPi bootloader supports
overlay *parameters*, U-Boot and Linux [2] do not, and overlays with
parameters (like most of those provided by rpi-firmware) will fail to
load. If you need overlays with parameters, you have to load the DT via
the firmware. Or you can rewrite them with the parameter values folded
in, and add them to your build (I've actually done that).

I think that's a bit beyond a simple example, though. If the maintainers
disagree I could add another snippet from my setup to create a FIT image
that includes a DTB to be used by the kernel. Or maybe a comment/readme
section that points out the options a bit more explicitly than just "we
recommend you to change it to fit your needs".

Best regards,
Fiona

[1] https://docs.u-boot.org/en/latest/board/broadcom/raspberrypi.html
[2] I haven't checked if that may be patched in RPi kernels, I mostly
work with mainline, I just use an RPi kernel here to stay close to the
existing RPi defconfigs.

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

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

[Niklas Cassel via buildroot]

On Tue, Sep 03, 2024 at 03:10:19PM +0200, Fiona Klute wrote:
> Am 03.09.24 um 13:08 schrieb Niklas Cassel:
> > On Sat, Aug 31, 2024 at 09:01:26PM +0200, 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.
> > > 
> > > 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.
> > > 
> > >   board/raspberrypi/boot.scr.in                 |  9 +++
> > >   .../raspberrypi/config_cm4io_64bit_uboot.txt  | 23 +++++++
> > >   board/raspberrypi/readme.txt                  |  4 ++
> > >   configs/raspberrypicm4io_64_uboot_defconfig   | 60 +++++++++++++++++++
> > >   4 files changed, 96 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..a5c986ef99
> > > --- /dev/null
> > > +++ b/board/raspberrypi/boot.scr.in
> > > @@ -0,0 +1,9 @@
> > > +# 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.
> > > +
> > > +# load kernel from the root partition
> > > +load mmc 0:2 ${kernel_addr_r} boot/Image
> > > +env set bootargs "root=/dev/mmcblk0p2 rootwait console=tty1 console=ttyAMA0,115200"
> > > +# boot using the FDT provided by firmware
> > > +booti ${kernel_addr_r} - ${fdt_addr}
> > 
> > Hello Fiona,
> > 
> > While I'm not a u-boot expert, I am slightly surprised to see a new
> > buildroot defconfig use boot.scr instead of extlinux.conf.
> > 
> > extlinux.conf is the default configuration format in u-boot:
> > https://github.com/u-boot/u-boot/blob/v2024.10-rc4/doc/develop/distro.rst?plain=1#L69-L71
> > 
> > Even though boot.scr still seems to be supported for backwards-compatibility:
> > https://github.com/u-boot/u-boot/blob/v2024.10-rc4/doc/develop/distro.rst?plain=1#L367-L368
> > 
> > See e.g. this buildroot commit that converted rock5b from boot.scr to
> > extlinux.conf:
> > https://github.com/buildroot/buildroot/commit/b7dbdd3d775b8e94664c6f37b11afc8a6a352e35
> > 
> > I don't see anthing exotic in your boot.scr that wouldn't work with
> > extlinux.conf.
> 
> AFAIK things like configuring watchdogs and handling A/B boot slot
> selection (with RAUC integration) aren't possible with extlinux.conf,
> and a menu isn't going to be much help in a headless system. If there is
> a better way than boot.scr to handle those I'd very much like to read
> about it.

My point was just that the boot.scr.in that you have above could easily be
replaced by a extlinux.conf instead.

I hear your argument that certain features (like watchdog an A/B boot slot)
is not possible with extlinux.conf.

But if you want your example to be minimal... isn't extlinux.conf enough/
exactly what you want? (extlinux.conf is definitely simpler for a beginner
to understand, compared to a boot.scr or a .its file.)

Your comment in boot.scr.in itself says that if you want something more fancy,
you should provide your own config.

Anyway, I'm just providing a suggestion. Feel free to ignore :)

Another suggestion is for your new defconfig to use the upstream kernel
instead of the downstream kernel. A person running u-boot has already taken
the step to use the "upstream" way of booting. It is far more likely that
such a person also wants to use the upstream kernel (rather than the
downstream kernel).


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

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

[Fiona Klute via buildroot]

Am 03.09.24 um 15:29 schrieb Niklas Cassel:
> On Tue, Sep 03, 2024 at 03:10:19PM +0200, Fiona Klute wrote:
>> Am 03.09.24 um 13:08 schrieb Niklas Cassel:
>>> On Sat, Aug 31, 2024 at 09:01:26PM +0200, 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.
>>>>
>>>> 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.
>>>>
>>>>    board/raspberrypi/boot.scr.in                 |  9 +++
>>>>    .../raspberrypi/config_cm4io_64bit_uboot.txt  | 23 +++++++
>>>>    board/raspberrypi/readme.txt                  |  4 ++
>>>>    configs/raspberrypicm4io_64_uboot_defconfig   | 60 +++++++++++++++++++
>>>>    4 files changed, 96 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..a5c986ef99
>>>> --- /dev/null
>>>> +++ b/board/raspberrypi/boot.scr.in
>>>> @@ -0,0 +1,9 @@
>>>> +# 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.
>>>> +
>>>> +# load kernel from the root partition
>>>> +load mmc 0:2 ${kernel_addr_r} boot/Image
>>>> +env set bootargs "root=/dev/mmcblk0p2 rootwait console=tty1 console=ttyAMA0,115200"
>>>> +# boot using the FDT provided by firmware
>>>> +booti ${kernel_addr_r} - ${fdt_addr}
>>>
>>> Hello Fiona,
>>>
>>> While I'm not a u-boot expert, I am slightly surprised to see a new
>>> buildroot defconfig use boot.scr instead of extlinux.conf.
>>>
>>> extlinux.conf is the default configuration format in u-boot:
>>> https://github.com/u-boot/u-boot/blob/v2024.10-rc4/doc/develop/distro.rst?plain=1#L69-L71
>>>
>>> Even though boot.scr still seems to be supported for backwards-compatibility:
>>> https://github.com/u-boot/u-boot/blob/v2024.10-rc4/doc/develop/distro.rst?plain=1#L367-L368
>>>
>>> See e.g. this buildroot commit that converted rock5b from boot.scr to
>>> extlinux.conf:
>>> https://github.com/buildroot/buildroot/commit/b7dbdd3d775b8e94664c6f37b11afc8a6a352e35
>>>
>>> I don't see anthing exotic in your boot.scr that wouldn't work with
>>> extlinux.conf.
>>
>> AFAIK things like configuring watchdogs and handling A/B boot slot
>> selection (with RAUC integration) aren't possible with extlinux.conf,
>> and a menu isn't going to be much help in a headless system. If there is
>> a better way than boot.scr to handle those I'd very much like to read
>> about it.
>
> My point was just that the boot.scr.in that you have above could easily be
> replaced by a extlinux.conf instead.

I checked the extlinux.conf docs since, and it actually can't be,
because the kernel isn't loaded from the boot partition.

> I hear your argument that certain features (like watchdog an A/B boot slot)
> is not possible with extlinux.conf.
>
> But if you want your example to be minimal... isn't extlinux.conf enough/
> exactly what you want? (extlinux.conf is definitely simpler for a beginner
> to understand, compared to a boot.scr or a .its file.)
>
> Your comment in boot.scr.in itself says that if you want something more fancy,
> you should provide your own config.

My primary goal is to make it easy to find the starting point for that. ;-)

> Anyway, I'm just providing a suggestion. Feel free to ignore :)
>
> Another suggestion is for your new defconfig to use the upstream kernel
> instead of the downstream kernel. A person running u-boot has already taken
> the step to use the "upstream" way of booting. It is far more likely that
> such a person also wants to use the upstream kernel (rather than the
> downstream kernel).
I agree, there are two reasons I didn't try that here:

a) This way it's almost the same as the other RPi defconfigs, makes it
easier to see what needs to be changed for U-Boot.

b) I don't have a working setup with U-Boot using DTBs from an
unmodified mainline kernel.

I'm working on b), though for a specific CM4-based system (RevPi Connect
4 [1]), not the IO-Board. U-Boot doesn't boot with the mainline
broadcom/bcm2711-rpi-cm4-io DTB, and I currently have a custom DTS based
on it (for the different hardware around the CM4), plus a custom overlay
for U-Boot because it fails to boot if the serial console isn't on UART0
(and most rpi-firmware overlays don't work with the upstream DTBs). If
one of the patch series to build extra overlays gets merged I might see
if adding that overlay is enough to switch this defconfig to mainline,
showing how to use a mainline kernel seems useful enough to justify
deviating from the other RPi defconfigs.

Or once I get the DTS I'm working on completed and hopefully upstreamed
I might see if a revpi4connect_uboot_defconfig could get merged. :-)

Best regards,
Fiona

[1] https://revolutionpi.com/en/download/7223/
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Fiona Klute via buildroot]

Hi Gaël!

Am 04.02.25 um 17:57 schrieb Gaël PORTAY:
> Hello Fiona,
>
> On Sat Aug 31, 2024 at 9:01 PM CEST, 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.
>>
>> 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.
>>
>>   board/raspberrypi/boot.scr.in                 |  9 +++
>>   .../raspberrypi/config_cm4io_64bit_uboot.txt  | 23 +++++++
>>   board/raspberrypi/readme.txt                  |  4 ++
>>   configs/raspberrypicm4io_64_uboot_defconfig   | 60 +++++++++++++++++++
>>   4 files changed, 96 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..a5c986ef99
>> --- /dev/null
>> +++ b/board/raspberrypi/boot.scr.in
>> @@ -0,0 +1,9 @@
>> +# 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.
>> +
>> +# load kernel from the root partition
>> +load mmc 0:2 ${kernel_addr_r} boot/Image
>> +env set bootargs "root=/dev/mmcblk0p2 rootwait console=tty1 console=ttyAMA0,115200"
>> +# boot using the FDT provided by firmware
>> +booti ${kernel_addr_r} - ${fdt_addr}
>
> The raspberrypi5 uses a different console (i.e. console=ttyAMA10,11500)
> and thus it requires a different file, right?

Either that, or some logic to detect different boards and adjust the
command line (e.g. "fdt get value" to read the compatible string and
compare, or just the default board_name environment variable). Not sure
what's preferable, do you have an opinion?

> What do you think about adding a suffix so we can make the distinction
> between the whole Raspberry Pi 4 64bit familly and an hypotetical
> Raspberry Pi 5 boot.scr file?
>
> I am thinking about renaming the file boot_4_64bit.scr (or maybe
> boot_cm4io_64bit.scr it the file is specific to the CM4-IO Board) and
> update BR2_PACKAGE_HOST_UBOOT_TOOLS_BOOT_SCRIPT_SOURCE accordingly.

I'd expect it to work with pretty much any 64 bit RPi variant, maybe
with adjustments to the bootargs as you mentioned. It's not like the
script itself has anything board specific, the variables are provided by
U-Boot. If we go with separate scripts, the suffix is fine with me.

>> 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 81cd81a7f3..dc5216b088 100644
>> --- a/board/raspberrypi/readme.txt
>> +++ b/board/raspberrypi/readme.txt
>> @@ -65,6 +65,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..b3b35479d3
>> --- /dev/null
>> +++ b/configs/raspberrypicm4io_64_uboot_defconfig
>> @@ -0,0 +1,60 @@
>> +BR2_aarch64=y
>> +BR2_cortex_a72=y
>> +BR2_ARM_FPU_VFPV4=y
>> +
>> +# patches
>> +BR2_GLOBAL_PATCH_DIR="board/raspberrypi/patches"
>> +BR2_DOWNLOAD_FORCE_CHECK_HASHES=y
>> +
>> +BR2_SYSTEM_DHCP="eth0"
>> +
>> +# Linux headers same as kernel, a 6.6 series
>> +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_6=y
>> +
>> +BR2_TOOLCHAIN_BUILDROOT_CXX=y
>> +
>> +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"
>> +
>> +# Install kernel to rootfs so U-Boot can load it from there, only
>> +# U-Boot gets included in the /boot partition.
>> +BR2_LINUX_KERNEL_INSTALL_TARGET=y
>> +BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=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"
>> +
>> +# Required tools to create the SD image
>> +BR2_PACKAGE_HOST_DOSFSTOOLS=y
>> +BR2_PACKAGE_HOST_GENIMAGE=y
>> +BR2_PACKAGE_HOST_MTOOLS=y
>> +
>> +# Required tool to flash CM4 eMMC memory
>> +BR2_PACKAGE_HOST_RASPBERRYPI_USBBOOT=y
>> +
>> +# Filesystem / image
>> +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_ROOTFS_POST_BUILD_SCRIPT="board/raspberrypicm4io-64/post-build.sh"
>> +BR2_ROOTFS_POST_IMAGE_SCRIPT="board/raspberrypicm4io-64/post-image.sh"
>> +
>> +# Enable compressed kernel module support
>> +BR2_PACKAGE_BUSYBOX_SHOW_OTHERS=y
>> +BR2_PACKAGE_KMOD_TOOLS=y
>> +BR2_PACKAGE_XZ=y
>> +BR2_PACKAGE_KMOD=y
>> +BR2_PACKAGE_HOST_KMOD_XZ=y
>> +
>> +# U-Boot and tools to build its config script
>> +BR2_TARGET_UBOOT=y
>> +BR2_TARGET_UBOOT_BOARD_DEFCONFIG="rpi_arm64"
>> +BR2_PACKAGE_HOST_UBOOT_TOOLS=y
>> +BR2_PACKAGE_HOST_UBOOT_TOOLS_BOOT_SCRIPT=y
>> +BR2_PACKAGE_HOST_UBOOT_TOOLS_BOOT_SCRIPT_SOURCE="board/raspberrypi/boot.scr.in"
>                                                            ^^^^^^^^^^^
> 							  maybe raspberrypicm4io-64?

Makes sense. :-)

>> --
>> 2.45.2
>>
>> _______________________________________________
>> buildroot mailing list
>> buildroot@buildroot.org
>> https://lists.buildroot.org/mailman/listinfo/buildroot
>
> The guidness about the defconfig has changes since you posted your
> patches.
>
> May I ask to regenerate the defconfig with make defconfig[0][1], and
> switch to use an external toolchain (Bootlin stable glibc) as per[2]?
>
> 	The defconfig should use a Bootlin toolchain (stable, glibc) if that is available and works.

Sure, will do that.

Best regards,
Fiona

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

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

[Gaël PORTAY]

On Wed Feb 5, 2025 at 7:07 PM CET, Fiona Klute wrote:
>>> diff --git a/board/raspberrypi/boot.scr.in b/board/raspberrypi/boot.scr.in
>>> new file mode 100644
>>> index 0000000000..a5c986ef99
>>> --- /dev/null
>>> +++ b/board/raspberrypi/boot.scr.in
>>> @@ -0,0 +1,9 @@
>>> +# 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.
>>> +
>>> +# load kernel from the root partition
>>> +load mmc 0:2 ${kernel_addr_r} boot/Image
>>> +env set bootargs "root=/dev/mmcblk0p2 rootwait console=tty1 console=ttyAMA0,115200"
>>> +# boot using the FDT provided by firmware
>>> +booti ${kernel_addr_r} - ${fdt_addr}
>>
>> The raspberrypi5 uses a different console (i.e. console=ttyAMA10,11500)
>> and thus it requires a different file, right?
>
> Either that, or some logic to detect different boards and adjust the
> command line (e.g. "fdt get value" to read the compatible string and
> compare, or just the default board_name environment variable). Not sure
> what's preferable, do you have an opinion?
>

Oh I got it...

>> What do you think about adding a suffix so we can make the distinction
>> between the whole Raspberry Pi 4 64bit familly and an hypotetical
>> Raspberry Pi 5 boot.scr file?
>>
>> I am thinking about renaming the file boot_4_64bit.scr (or maybe
>> boot_cm4io_64bit.scr it the file is specific to the CM4-IO Board) and
>> update BR2_PACKAGE_HOST_UBOOT_TOOLS_BOOT_SCRIPT_SOURCE accordingly.
>
> I'd expect it to work with pretty much any 64 bit RPi variant, maybe
> with adjustments to the bootargs as you mentioned. It's not like the
> script itself has anything board specific, the variables are provided by
> U-Boot. If we go with separate scripts, the suffix is fine with me.
>

.... You are right, since this is all about scripting, this can be done
at runtime. Thus, we can have a single boot.scr compatible with every pi
(1-4-32bit, pi1-4-64bit, and pi5), and avoid another hassle of files
with prefixes.

So, IIUC, adding the raspberrypi5 is just about updating boot.scr this
way:

	# load kernel from the root partition
	load mmc 0:2 ${kernel_addr_r} boot/Image
	-env set bootargs "root=/dev/mmcblk0p2 rootwait console=tty1 console=ttyAMA0,115200"
	+if test "$board_name" = "5 Model B"; then
	+  env set bootargs "root=/dev/mmcblk0p2 rootwait console=tty1 console=ttyAMA10,115200"
	+else
	+ env set bootargs "root=/dev/mmcblk0p2 rootwait console=tty1 console=ttyAMA00,115200"
	+fi
	# boot using the FDT provided by firmware
	booti ${kernel_addr_r} - ${fdt_addr}

So forget what I said about the prefix, and stick to boot.scr, you got
the right approach ;)

Here all the environment for the pi5:

	U-Boot> printenv
	arch=arm
	baudrate=115200
	board=rpi
	board_name=5 Model B
	board_rev=0x17
	board_rev_scheme=1
	board_revision=0xD04170
	boot_targets=mmc usb pxe dhcp
	bootcmd=bootflow scan
	bootdelay=2
	cpu=armv8
	dhcpuboot=usb start; dhcp u-boot.uimg; bootm
	fdt_addr=2efec100
	fdt_addr_r=0x02600000
	fdt_high=ffffffffffffffff
	fdtcontroladdr=3f726f80
	fdtfile=broadcom/bcm2712-rpi-5-b.dtb
	initrd_high=ffffffffffffffff
	kernel_addr_r=0x00080000
	loadaddr=0x1000000
	preboot=pci enum; usb start;
	pxefile_addr_r=0x02500000
	ramdisk_addr_r=0x02700000
	scriptaddr=0x02400000
	serial#=xxxxxxxxxxxxxxxx
	soc=bcm283x
	stderr=serial,vidconsole
	stdin=serial,usbkbd
	stdout=serial,vidconsole
	usb_ignorelist=0x1050:*,
	vendor=raspberrypi

And I supposed the 32bit support can be added by testing the variable
$cpu.

Regards,
Gaël
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

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

[Fiona Klute via buildroot]

Hi Gaël!

Am 07.02.25 um 11:14 schrieb Gaël PORTAY:
> On Wed Feb 5, 2025 at 7:07 PM CET, Fiona Klute wrote:
>>>> diff --git a/board/raspberrypi/boot.scr.in b/board/raspberrypi/boot.scr.in
>>>> new file mode 100644
>>>> index 0000000000..a5c986ef99
>>>> --- /dev/null
>>>> +++ b/board/raspberrypi/boot.scr.in
>>>> @@ -0,0 +1,9 @@
>>>> +# 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.
>>>> +
>>>> +# load kernel from the root partition
>>>> +load mmc 0:2 ${kernel_addr_r} boot/Image
>>>> +env set bootargs "root=/dev/mmcblk0p2 rootwait console=tty1 console=ttyAMA0,115200"
>>>> +# boot using the FDT provided by firmware
>>>> +booti ${kernel_addr_r} - ${fdt_addr}
>>>
>>> The raspberrypi5 uses a different console (i.e. console=ttyAMA10,11500)
>>> and thus it requires a different file, right?
>>
>> Either that, or some logic to detect different boards and adjust the
>> command line (e.g. "fdt get value" to read the compatible string and
>> compare, or just the default board_name environment variable). Not sure
>> what's preferable, do you have an opinion?
>>
>
> Oh I got it...
>
>>> What do you think about adding a suffix so we can make the distinction
>>> between the whole Raspberry Pi 4 64bit familly and an hypotetical
>>> Raspberry Pi 5 boot.scr file?
>>>
>>> I am thinking about renaming the file boot_4_64bit.scr (or maybe
>>> boot_cm4io_64bit.scr it the file is specific to the CM4-IO Board) and
>>> update BR2_PACKAGE_HOST_UBOOT_TOOLS_BOOT_SCRIPT_SOURCE accordingly.
>>
>> I'd expect it to work with pretty much any 64 bit RPi variant, maybe
>> with adjustments to the bootargs as you mentioned. It's not like the
>> script itself has anything board specific, the variables are provided by
>> U-Boot. If we go with separate scripts, the suffix is fine with me.
>>
>
> .... You are right, since this is all about scripting, this can be done
> at runtime. Thus, we can have a single boot.scr compatible with every pi
> (1-4-32bit, pi1-4-64bit, and pi5), and avoid another hassle of files
> with prefixes.

I'd expect the script to work with the 32bit RPis, too, but they'll need
a different U-Boot build defconfig. rpi_arm64_defconfig is generic
(using the firmware DT), but there's no equivalent for 32bit.

> So, IIUC, adding the raspberrypi5 is just about updating boot.scr this
> way:
>
> 	# load kernel from the root partition
> 	load mmc 0:2 ${kernel_addr_r} boot/Image
> 	-env set bootargs "root=/dev/mmcblk0p2 rootwait console=tty1 console=ttyAMA0,115200"
> 	+if test "$board_name" = "5 Model B"; then
> 	+  env set bootargs "root=/dev/mmcblk0p2 rootwait console=tty1 console=ttyAMA10,115200"
> 	+else
> 	+ env set bootargs "root=/dev/mmcblk0p2 rootwait console=tty1 console=ttyAMA00,115200"
> 	+fi
> 	# boot using the FDT provided by firmware
> 	booti ${kernel_addr_r} - ${fdt_addr}
>
> So forget what I said about the prefix, and stick to boot.scr, you got
> the right approach ;)
>
> Here all the environment for the pi5:
>
> 	U-Boot> printenv
> 	arch=arm
> 	baudrate=115200
> 	board=rpi
> 	board_name=5 Model B
> 	board_rev=0x17
> 	board_rev_scheme=1
> 	board_revision=0xD04170
> 	boot_targets=mmc usb pxe dhcp
> 	bootcmd=bootflow scan
> 	bootdelay=2
> 	cpu=armv8
> 	dhcpuboot=usb start; dhcp u-boot.uimg; bootm
> 	fdt_addr=2efec100
> 	fdt_addr_r=0x02600000
> 	fdt_high=ffffffffffffffff
> 	fdtcontroladdr=3f726f80
> 	fdtfile=broadcom/bcm2712-rpi-5-b.dtb
> 	initrd_high=ffffffffffffffff
> 	kernel_addr_r=0x00080000
> 	loadaddr=0x1000000
> 	preboot=pci enum; usb start;
> 	pxefile_addr_r=0x02500000
> 	ramdisk_addr_r=0x02700000
> 	scriptaddr=0x02400000
> 	serial#=xxxxxxxxxxxxxxxx
> 	soc=bcm283x
> 	stderr=serial,vidconsole
> 	stdin=serial,usbkbd
> 	stdout=serial,vidconsole
> 	usb_ignorelist=0x1050:*,
> 	vendor=raspberrypi
>
> And I supposed the 32bit support can be added by testing the variable
> $cpu.

I've just sent v3 using the board_name check you suggested. I don't have
  an RPi 5, so I'd appreciate if you could test it. It does boot on my
CM4 based device.

Best regards,
Fiona

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