| Message ID | 20240831190126.366600-4-fiona.klute@gmx.de |
|---|---|
| State | New |
| Headers | show |
| Series | U-Boot on RPi boards | expand |
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
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.
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
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/
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"