I realised that it's not a good idea to go with an ext4 boot partition with a RPI, apparently it requires the boot partition to be fat.
Following that I managed to prepare an update and flash it onto the mmc, however the struggle at the moment is instructing u-boot to use the updated boot partition - my RPI always boots to the first vfat partition on the image. The `boot.scr` script on my boot partitions is as below, moreover the u-boot environment gets updated adequately, meaning that the BOOT_DEV variable does change to "mmc 0:2" after an update. This seems to be completely ignored by u-boot, even when BOOT_DEV was fixed to "mmc 0:2" RPI booted into the first vfat partition on the image. boot.scr: fdt addr ${fdt_addr} && fdt get value bootargs /chosen bootargs > > test -n "${BOOT_ORDER}" || setenv BOOT_ORDER "A B" > test -n "${BOOT_A_LEFT}" || setenv BOOT_A_LEFT 3 > test -n "${BOOT_B_LEFT}" || setenv BOOT_B_LEFT 3 > test -n "${BOOT_DEV}" || setenv BOOT_DEV "mmc 0:1" > > setenv bootpart > setenv raucslot > > for BOOT_SLOT in "${BOOT_ORDER}"; do > if test "x${bootpart}" != "x"; then > # skip remaining slots > elif test "x${BOOT_SLOT}" = "xA"; then > if itest ${BOOT_A_LEFT} -gt 0; then > setexpr BOOT_A_LEFT ${BOOT_A_LEFT} - 1 > echo "Found valid RAUC slot A" > setenv bootpart "/dev/mmcblk0p3" > setenv raucslot "A" > setenv BOOT_DEV "mmc 0:1" > fi > elif test "x${BOOT_SLOT}" = "xB"; then > if itest ${BOOT_B_LEFT} -gt 0; then > setexpr BOOT_B_LEFT ${BOOT_B_LEFT} - 1 > echo "Found valid RAUC slot B" > setenv bootpart "/dev/mmcblk0p4" > setenv raucslot "B" > setenv BOOT_DEV "mmc 0:2" > fi > fi > done > > if test -n "${bootpart}"; then > setenv bootargs "${bootargs} root=${bootpart} rauc.slot=${raucslot}" > saveenv > else > echo "No valid RAUC slot found. Resetting tries to 3" > setenv BOOT_A_LEFT 3 > setenv BOOT_B_LEFT 3 > saveenv > reset > fi > > fatload ${BOOT_DEV} ${kernel_addr_r} @@KERNEL_IMAGETYPE@@ > if test ! -e ${BOOT_DEV} uboot.env; then saveenv; fi; > @@KERNEL_BOOTCMD@@ ${kernel_addr_r} - ${fdt_addr} > Thanks for all the advice, Antoni On Mon, May 6, 2024 at 4:29 PM Antoni Jankowski < antoni.s.jankow...@gmail.com> wrote: > Hi Jojan, > > I did check the u-boot config, CONFIG_CMD_EXT4 was enabled, > CONFIG_CMD_EXT4_WRITE > disabled. I made sure to enable both, replace `fatload` with `ext4laod` and > recompiled u-boot. > Sadly the effect is that the board still does not boot. I've ditched one > of the boot partitions to make things a bit easier to set up, first > focusing on the boot partition getting recognized by the system. > > I've noticed that the ext4 boot partition contains many more files than > its vfat equivalent. Below I send the *wic ls* output of the /boot > partition in set to ext4: > > debugfs 1.47.0 (5-Feb-2023) >> 2 40755 (2) 0 0 1024 6-May-2024 16:03 . >> 2 40755 (2) 0 0 1024 6-May-2024 16:03 .. >> 11 40700 (2) 0 0 12288 6-May-2024 16:03 lost+found >> 12 100644 (1) 1000 1000 22387200 6-May-2024 16:03 Image >> 13 100644 (1) 1000 1000 52424 6-May-2024 16:03 >> bcm2711-rpi-4-b.dtb >> 14 100644 (1) 1000 1000 52556 6-May-2024 16:03 >> bcm2711-rpi-400.dtb >> 15 100644 (1) 1000 1000 53165 6-May-2024 16:03 >> bcm2711-rpi-cm4.dtb >> 16 100644 (1) 1000 1000 386 6-May-2024 16:03 boot.scr >> 17 100644 (1) 1000 1000 52460 6-May-2024 16:03 bootcode.bin >> 18 100644 (1) 1000 1000 197 6-May-2024 16:03 cmdline.txt >> 19 100644 (1) 1000 1000 2214 6-May-2024 16:03 config.txt >> 20 100644 (1) 1000 1000 7262 6-May-2024 16:03 fixup.dat >> 21 100644 (1) 1000 1000 5399 6-May-2024 16:03 fixup4.dat >> 22 100644 (1) 1000 1000 3170 6-May-2024 16:03 fixup4cd.dat >> 23 100644 (1) 1000 1000 8379 6-May-2024 16:03 fixup4db.dat >> 24 100644 (1) 1000 1000 8379 6-May-2024 16:03 fixup4x.dat >> 25 100644 (1) 1000 1000 3170 6-May-2024 16:03 fixup_cd.dat >> 26 100644 (1) 1000 1000 10228 6-May-2024 16:03 fixup_db.dat >> 27 100644 (1) 1000 1000 10226 6-May-2024 16:03 fixup_x.dat >> 28 100644 (1) 1000 1000 589368 6-May-2024 16:03 kernel8.img >> 29 40755 (2) 1000 1000 3072 6-May-2024 16:03 overlays >> 73 100644 (1) 1000 1000 0 6-May-2024 16:03 >> rpi-bootfiles-20220830.stamp >> 74 100644 (1) 1000 1000 2973536 6-May-2024 16:03 start.elf >> 75 100644 (1) 1000 1000 2249280 6-May-2024 16:03 start4.elf >> 76 100644 (1) 1000 1000 803964 6-May-2024 16:03 start4cd.elf >> 77 100644 (1) 1000 1000 3744808 6-May-2024 16:03 start4db.elf >> 78 100644 (1) 1000 1000 2996680 6-May-2024 16:03 start4x.elf >> 79 100644 (1) 1000 1000 803964 6-May-2024 16:03 start_cd.elf >> 80 100644 (1) 1000 1000 4816712 6-May-2024 16:03 start_db.elf >> 81 100644 (1) 1000 1000 3720360 6-May-2024 16:03 start_x.elf >> > > Meanwhile, the same partition in a vfat form looks completely different, I > suppose the additional files are related to u-boot, but I am not sure why > that is happening. > > Volume in drive : is boot >> Volume Serial Number is 2C31-E8B4 >> Directory for ::/ >> IMAGE 22387200 2011-04-05 23:00 Image >> BCM271~1 DTB 52424 2011-04-05 23:00 bcm2711-rpi-4-b.dtb >> BCM271~2 DTB 52556 2011-04-05 23:00 bcm2711-rpi-400.dtb >> BCM271~3 DTB 53165 2011-04-05 23:00 bcm2711-rpi-cm4.dtb >> boot scr 385 2011-04-05 23:00 >> bootcode bin 52460 2011-04-05 23:00 >> cmdline txt 197 2011-04-05 23:00 >> config txt 2214 2011-04-05 23:00 >> fixup dat 7262 2011-04-05 23:00 >> fixup4 dat 5399 2011-04-05 23:00 >> fixup4cd dat 3170 2011-04-05 23:00 >> fixup4db dat 8379 2011-04-05 23:00 >> fixup4x dat 8379 2011-04-05 23:00 >> fixup_cd dat 3170 2011-04-05 23:00 >> fixup_db dat 10228 2011-04-05 23:00 >> fixup_x dat 10226 2011-04-05 23:00 >> kernel8 img 589368 2011-04-05 23:00 >> overlays <DIR> 2011-04-05 23:00 >> RPI-BO~1 STA 0 2011-04-05 23:00 rpi-bootfiles-20220830.stamp >> start elf 2973536 2011-04-05 23:00 >> start4 elf 2249280 2011-04-05 23:00 >> start4cd elf 803964 2011-04-05 23:00 >> start4db elf 3744808 2011-04-05 23:00 >> start4x elf 2996680 2011-04-05 23:00 >> start_cd elf 803964 2011-04-05 23:00 >> start_db elf 4816712 2011-04-05 23:00 >> start_x elf 3720360 2011-04-05 23:00 >> 27 files 45 355 486 bytes >> 90 558 464 bytes free > > > There is also a difference in the vfat being known as a boot drive with > more information available, agin not sure why. > Anyway, thanks for the tips, if you have more of them, please let me know > :) > > Best regards, > Antoni > > On Thu, May 2, 2024 at 10:42 PM Jojan <jjva...@yahoo.com> wrote: > >> You have to use ext4load mmc 0:1 ${kernel_addr} ${image} >> >> Can you check CONFIG_CMD_EXT4 or CONFIG_CMD_EXT4_WRITE is enabled ? >> >> >> >> On Thursday, May 2, 2024 at 06:19:11 AM PDT, Antoni Jankowski < >> antoni.s.jankow...@gmail.com> wrote: >> >> >> Hi, >> >> I'm working with a Raspberry Pi Compute Module 4 and RAUC update tool for >> embedded linux. >> The problem I'm struggling with is to update both the rootfs and the boot >> partition. The approach I'm trying to apply is based on an architecture of >> two boot partitions and two rootfs partitions. >> The boot and rootfs partitions are supposed to get updated in pairs. >> >> boot_A (/dev/mmcblk0p1) >> boot_B (/dev/mmcblk0p2) >> rootfs_A (/dev/mmcblk0p3) >> rootfs_B (/dev/mmcblk0p4) >> >> For RAUC to be able to write an update to a boot partition it has to be of >> *ext4* type and this is the real problem. What should be the u-boot >> *boot.scr* script to handle this? >> I've read that *fatload* should be replaced with *ext4load* instruction, >> however such a simple swap does not work well, the board does not boot at >> all. >> Are there any other steps I should take to make the board bootable with an >> ext4 boot partition? >> >> Below is the source of my original *boot.scr* script: >> >> fdt addr ${fdt_addr} && fdt get value bootargs /chosen bootargs >> > >> > setenv bootpart "/dev/mmcblk0p3" >> > setenv raucslot "A" >> > setenv bootargs "${bootargs} root=${bootpart} rauc.slot=${raucslot}" >> > fatload mmc 0:1 ${kernel_addr_r} @@KERNEL_IMAGETYPE@@ >> > if test ! -e mmc 0:1 uboot.env; then saveenv; fi; >> > @@KERNEL_BOOTCMD@@ ${kernel_addr_r} - ${fdt_addr} >> > >> >> Best regards, >> Antoni >> >