* [Buildroot] [PATCH next v2 0/3] U-Boot on RPi boards
@ 2024-08-31 19:01 Fiona Klute via buildroot
2024-08-31 19:01 ` [Buildroot] [PATCH next v2 1/3] board/raspberrypi: Support boot.scr for U-Boot Fiona Klute via buildroot
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Fiona Klute via buildroot @ 2024-08-31 19:01 UTC (permalink / raw)
To: buildroot
Cc: Fiona Klute (WIWA), José Mendes, Martin Bark,
Julien Grossholtz, Yann E . MORIN
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
^ permalink raw reply [flat|nested] 11+ messages in thread* [Buildroot] [PATCH next v2 1/3] board/raspberrypi: Support boot.scr for U-Boot 2024-08-31 19:01 [Buildroot] [PATCH next v2 0/3] U-Boot on RPi boards Fiona Klute via buildroot @ 2024-08-31 19:01 ` Fiona Klute via buildroot 2024-08-31 19:01 ` [Buildroot] [PATCH next v2 2/3] board/raspberrypi: allow non-matching globs for DTBs Fiona Klute via buildroot 2024-08-31 19:01 ` [Buildroot] [PATCH next v2 3/3] configs/raspberrypicm4io_64_uboot_defconfig: new defconfig Fiona Klute via buildroot 2 siblings, 0 replies; 11+ messages in thread From: Fiona Klute via buildroot @ 2024-08-31 19:01 UTC (permalink / raw) To: buildroot Cc: Fiona Klute (WIWA), José Mendes, Martin Bark, Julien Grossholtz, Yann E . MORIN 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 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* [Buildroot] [PATCH next v2 2/3] board/raspberrypi: allow non-matching globs for DTBs 2024-08-31 19:01 [Buildroot] [PATCH next v2 0/3] U-Boot on RPi boards Fiona Klute via buildroot 2024-08-31 19:01 ` [Buildroot] [PATCH next v2 1/3] board/raspberrypi: Support boot.scr for U-Boot Fiona Klute via buildroot @ 2024-08-31 19:01 ` Fiona Klute via buildroot 2024-08-31 19:01 ` [Buildroot] [PATCH next v2 3/3] configs/raspberrypicm4io_64_uboot_defconfig: new defconfig Fiona Klute via buildroot 2 siblings, 0 replies; 11+ messages in thread From: Fiona Klute via buildroot @ 2024-08-31 19:01 UTC (permalink / raw) To: buildroot Cc: Fiona Klute (WIWA), José Mendes, Martin Bark, Julien Grossholtz, Yann E . MORIN 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 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* [Buildroot] [PATCH next v2 3/3] configs/raspberrypicm4io_64_uboot_defconfig: new defconfig 2024-08-31 19:01 [Buildroot] [PATCH next v2 0/3] U-Boot on RPi boards Fiona Klute via buildroot 2024-08-31 19:01 ` [Buildroot] [PATCH next v2 1/3] board/raspberrypi: Support boot.scr for U-Boot Fiona Klute via buildroot 2024-08-31 19:01 ` [Buildroot] [PATCH next v2 2/3] board/raspberrypi: allow non-matching globs for DTBs Fiona Klute via buildroot @ 2024-08-31 19:01 ` Fiona Klute via buildroot 2024-09-03 11:08 ` Niklas Cassel via buildroot [not found] ` <D7JTJDZQ286V.32BNGSIJOMVCI@gmail.com> 2 siblings, 2 replies; 11+ messages in thread From: Fiona Klute via buildroot @ 2024-08-31 19:01 UTC (permalink / raw) To: buildroot Cc: Fiona Klute (WIWA), José Mendes, Martin Bark, Julien Grossholtz, Yann E . MORIN 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 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [Buildroot] [PATCH next v2 3/3] configs/raspberrypicm4io_64_uboot_defconfig: new defconfig 2024-08-31 19:01 ` [Buildroot] [PATCH next v2 3/3] configs/raspberrypicm4io_64_uboot_defconfig: new defconfig Fiona Klute via buildroot @ 2024-09-03 11:08 ` Niklas Cassel via buildroot 2024-09-03 13:10 ` Fiona Klute via buildroot [not found] ` <D7JTJDZQ286V.32BNGSIJOMVCI@gmail.com> 1 sibling, 1 reply; 11+ messages in thread From: Niklas Cassel via buildroot @ 2024-09-03 11:08 UTC (permalink / raw) To: Fiona Klute Cc: Yann E . MORIN, José Mendes, Martin Bark, Julien Grossholtz, buildroot@buildroot.org 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Buildroot] [PATCH next v2 3/3] configs/raspberrypicm4io_64_uboot_defconfig: new defconfig 2024-09-03 11:08 ` Niklas Cassel via buildroot @ 2024-09-03 13:10 ` Fiona Klute via buildroot 2024-09-03 13:29 ` Niklas Cassel via buildroot 0 siblings, 1 reply; 11+ messages in thread From: Fiona Klute via buildroot @ 2024-09-03 13:10 UTC (permalink / raw) To: Niklas Cassel Cc: Yann E . MORIN, José Mendes, Martin Bark, Julien Grossholtz, buildroot@buildroot.org 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Buildroot] [PATCH next v2 3/3] configs/raspberrypicm4io_64_uboot_defconfig: new defconfig 2024-09-03 13:10 ` Fiona Klute via buildroot @ 2024-09-03 13:29 ` Niklas Cassel via buildroot 2024-09-04 18:52 ` Fiona Klute via buildroot 0 siblings, 1 reply; 11+ messages in thread From: Niklas Cassel via buildroot @ 2024-09-03 13:29 UTC (permalink / raw) To: Fiona Klute Cc: Yann E . MORIN, José Mendes, Martin Bark, Julien Grossholtz, buildroot@buildroot.org 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Buildroot] [PATCH next v2 3/3] configs/raspberrypicm4io_64_uboot_defconfig: new defconfig 2024-09-03 13:29 ` Niklas Cassel via buildroot @ 2024-09-04 18:52 ` Fiona Klute via buildroot 0 siblings, 0 replies; 11+ messages in thread From: Fiona Klute via buildroot @ 2024-09-04 18:52 UTC (permalink / raw) To: Niklas Cassel Cc: Yann E . MORIN, José Mendes, Martin Bark, Julien Grossholtz, buildroot@buildroot.org 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <D7JTJDZQ286V.32BNGSIJOMVCI@gmail.com>]
* Re: [Buildroot] [PATCH next v2 3/3] configs/raspberrypicm4io_64_uboot_defconfig: new defconfig [not found] ` <D7JTJDZQ286V.32BNGSIJOMVCI@gmail.com> @ 2025-02-05 18:07 ` Fiona Klute via buildroot 2025-02-07 10:14 ` Gaël PORTAY 0 siblings, 1 reply; 11+ messages in thread From: Fiona Klute via buildroot @ 2025-02-05 18:07 UTC (permalink / raw) To: Gaël PORTAY, buildroot Cc: José Mendes, Martin Bark, Julien Grossholtz, Yann E . MORIN 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Buildroot] [PATCH next v2 3/3] configs/raspberrypicm4io_64_uboot_defconfig: new defconfig 2025-02-05 18:07 ` Fiona Klute via buildroot @ 2025-02-07 10:14 ` Gaël PORTAY 2025-02-07 17:23 ` Fiona Klute via buildroot 0 siblings, 1 reply; 11+ messages in thread From: Gaël PORTAY @ 2025-02-07 10:14 UTC (permalink / raw) To: Fiona Klute, Gaël PORTAY, buildroot Cc: José Mendes, Martin Bark, Julien Grossholtz, Yann E . MORIN 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Buildroot] [PATCH next v2 3/3] configs/raspberrypicm4io_64_uboot_defconfig: new defconfig 2025-02-07 10:14 ` Gaël PORTAY @ 2025-02-07 17:23 ` Fiona Klute via buildroot 0 siblings, 0 replies; 11+ messages in thread From: Fiona Klute via buildroot @ 2025-02-07 17:23 UTC (permalink / raw) To: Gaël PORTAY, Gaël PORTAY, buildroot Cc: José Mendes, Martin Bark, Julien Grossholtz, Yann E . MORIN 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2025-02-07 17:24 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-08-31 19:01 [Buildroot] [PATCH next v2 0/3] U-Boot on RPi boards Fiona Klute via buildroot
2024-08-31 19:01 ` [Buildroot] [PATCH next v2 1/3] board/raspberrypi: Support boot.scr for U-Boot Fiona Klute via buildroot
2024-08-31 19:01 ` [Buildroot] [PATCH next v2 2/3] board/raspberrypi: allow non-matching globs for DTBs Fiona Klute via buildroot
2024-08-31 19:01 ` [Buildroot] [PATCH next v2 3/3] configs/raspberrypicm4io_64_uboot_defconfig: new defconfig Fiona Klute via buildroot
2024-09-03 11:08 ` Niklas Cassel via buildroot
2024-09-03 13:10 ` Fiona Klute via buildroot
2024-09-03 13:29 ` Niklas Cassel via buildroot
2024-09-04 18:52 ` Fiona Klute via buildroot
[not found] ` <D7JTJDZQ286V.32BNGSIJOMVCI@gmail.com>
2025-02-05 18:07 ` Fiona Klute via buildroot
2025-02-07 10:14 ` Gaël PORTAY
2025-02-07 17:23 ` Fiona Klute via buildroot
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.