It seems that the UBI volume got corrupted. This should not normally happen, have there been direct access to raw NAND or any other operation which might influence the integrity of the UBI volume?
I have understood my mistake.
I tried to flash freeRTOS image via TFTP under linux, but freeRTOS was running.
That’s why the UBI volume got corrupted.
The safe way is to do it via U-Boot using those commands :
ubi part ubi
tftpboot ${loadaddr} 172.19.xxx.xxx:Myfile_FreeRTOS_V1_0.elf
ubi write ${loadaddr} m4firmware ${filesize}
setenv m4boot 'ubi read ${loadaddr} m4firmware && dcache flush && bootaux ${loadaddr}'
saveenv
reset
For newbie like me, commands below must be done once :
Thanks for your comment, I will update the article.
By the way, are you sure that /dev/ubi0_2 was the firmware volume? Depending on what update scripts have been previously run the order of volumes could be different. From within Linux you can use the following command to see the relationsship between volumes and devices. E.g. in this case /dev/ubi0_2 is device major/minor 248:3 and m4firmware:
root@colibri-imx7:~# ubinfo -a
UBI version: 1
Count of UBI devices: 1
UBI control device major/minor: 10:55
Present UBI devices: ubi0
ubi0
Volumes count: 4
Logical eraseblock size: 126976 bytes, 124.0 KiB
Total amount of logical eraseblocks: 4060 (515522560 bytes, 491.6 MiB)
Amount of available logical eraseblocks: 0 (0 bytes)
Maximum count of volumes 128
Count of bad physical eraseblocks: 4
Count of reserved physical eraseblocks: 76
Current maximum erase counter value: 3
Minimum input/output unit size: 2048 bytes
Character device major/minor: 248:0
Present volumes: 0, 1, 2, 3
Volume ID: 0 (on ubi0)
Type: static
Alignment: 1
Size: 67 LEBs (8507392 bytes, 8.1 MiB)
Data bytes: 5114000 bytes (4.9 MiB)
State: OK
Name: kernel
Character device major/minor: 248:1
-----------------------------------
Volume ID: 1 (on ubi0)
Type: static
Alignment: 1
Size: 2 LEBs (253952 bytes, 248.0 KiB)
Data bytes: 43596 bytes (42.6 KiB)
State: OK
Name: dtb
Character device major/minor: 248:2
-----------------------------------
Volume ID: 2 (on ubi0)
Type: static
Alignment: 1
Size: 8 LEBs (1015808 bytes, 992.0 KiB)
Data bytes: 0 bytes
State: OK
Name: m4firmware
Character device major/minor: 248:3
-----------------------------------
Volume ID: 3 (on ubi0)
Type: dynamic
Alignment: 1
Size: 3901 LEBs (495333376 bytes, 472.4 MiB)
State: OK
Name: rootfs
Character device major/minor: 248:4
root@colibri-imx7:~# ls -la /dev/ubi*
crw------- 1 root root 248, 0 Dec 12 08:06 /dev/ubi0
crw------- 1 root root 248, 1 Dec 12 08:06 /dev/ubi0_0
crw------- 1 root root 248, 2 Dec 12 08:06 /dev/ubi0_1
crw------- 1 root root 248, 3 Dec 12 08:06 /dev/ubi0_2
crw------- 1 root root 248, 4 Dec 12 08:06 /dev/ubi0_3
crw------- 1 root root 10, 55 Dec 12 08:06 /dev/ubi_ctrl
ubiupdatevol with -t switch (-t, --truncate - truncate volume (wipe it out))
or ubiupdate without -t switch, but volume update with zero length file
lead on next reboot to above mentioned UBI assert failed in ubi_eba_read_leb at.
Immediately after ubiupdatevol with -t or with zero-length file is executed, ubinfo -a reports expected Data bytes = 0, but after reboot ubinfo -a reverts reporting Data bytes = N of the length of last non-zero length ubiupdatevol.
Looks like there’s a bug either in kernel or in ubiupdatevol. Either never ubiupdatevol -t and always make sure file length is >0, or, if zero static volume is required, then recreate empty static volume with ubirmvol + ubimkvol.
Once above UBI assert occurs, to recover you need to ubiupdatevol twice. Unfortunately, ubiudpatevol seems not detecting this kernel assert and returns 0 return value.
Above is observed on latest Yocto BSP 5.7.1 and Colibri iMX6ULL.
We are using different Colibri flavors. iMX7 as well. Issue is, I believe, the same on iMX7 NAND as well, I just expressed what exact variant I observed it on last time.
Since had doubts about it, i just retested on iMX7D NAND. Steps to reproduce. Having static UBI volume #5.
ubiupdatevol /dev/ubi0_5
ubinfo -a reports Data bytes: 0 bytes
cat /dev/ubi0_5 returns without kernel errors
reboot
ubinfo -a reports Data bytes: N bytes, where N is non zero size of last ubiupdatevol write size.
cat /dev/ubi0_5
[ 37.144028] UBI assert failed in ubi_eba_read_leb at 624 (pid 393)
[ 37.150743] UBI assert failed in ubi_eba_read_leb at 624 (pid 393)
These two lines having quite in kernel command prompt. dmesg shows more, output is similar to start of topic.
So no new topic, just an update for old one. I believe this is what originally happened, zero length write to UBI volume followed by reboot.
