U-boot script for RPI with boot partition of ext4 type

Antoni Jankowski antoni.s.jankowski at gmail.com
Thu May 9 14:52:35 CEST 2024


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 at 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 <jjvazha at 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 at 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
>>
>


More information about the U-Boot mailing list