From: Antoni Jankowski <antoni.s.jankowski@gmail.com>
To: Jojan <jjvazha@yahoo.com>
Cc: u-boot@lists.denx.de
Subject: Re: U-boot script for RPI with boot partition of ext4 type
Date: Thu, 9 May 2024 15:52:35 +0300 [thread overview]
Message-ID: <CAM4sPk9a7r2AVszB3SMCCHmzEaxAZ2eD_wOKaZXBtBg-G_HOTA@mail.gmail.com> (raw)
In-Reply-To: <CAM4sPk9j9sRJdbbOAUFd=vZnqp3b2pmhtjtjZ=WrdF0_aZZd0Q@mail.gmail.com>
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: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@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
>>
>
prev parent reply other threads:[~2024-05-09 13:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-02 10:35 U-boot script for RPI with boot partition of ext4 type Antoni Jankowski
[not found] ` <2078483561.3986406.1714678928052@mail.yahoo.com>
[not found] ` <CAM4sPk9j9sRJdbbOAUFd=vZnqp3b2pmhtjtjZ=WrdF0_aZZd0Q@mail.gmail.com>
2024-05-09 12:52 ` Antoni Jankowski [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAM4sPk9a7r2AVszB3SMCCHmzEaxAZ2eD_wOKaZXBtBg-G_HOTA@mail.gmail.com \
--to=antoni.s.jankowski@gmail.com \
--cc=jjvazha@yahoo.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).