Re: U-boot script for RPI with boot partition of ext4 type
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.jankowski@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:03bcm2711-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 jjvazha@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.jankowski@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
participants (1)
-
Antoni Jankowski