Ubiupdatevol problem


I’m having trouble using ubiupdatevol command to update freeRTOS firmware.

Using those commands (172.19.xxx.xxx not the right IP adress) :

tftp -g -r Myfile_FreeRTOS_V1_0.elf 172.19.xxx.xxx
ubiupdatevol /dev/ubi0_2 Myfile_FreeRTOS_V1_0.elf

the result is :

[   24.400611] UBI assert failed in ubi_eba_read_leb at 455 (pid 376)                                                                                   
[   24.407007] CPU: 0 PID: 376 Comm: ubiupdatevol Not tainted 4.1.39+gba2f75f #3                                                                        
[   24.414261] Hardware name: Freescale i.MX7 Dual (Device Tree)                                                                                        
[   24.420129] [<8001572c>] (unwind_backtrace) from [<8001279c>] (show_stack+0x10/0x14)                                                                 
[   24.428009] [<8001279c>] (show_stack) from [<80617e24>] (dump_stack+0x84/0x98)                                                                       
[   24.435360] [<80617e24>] (dump_stack) from [<803b0c78>] (ubi_eba_read_leb+0x2cc/0x41c)                                                               
[   24.443416] [<803b0c78>] (ubi_eba_read_leb) from [<803b9c8c>] (ubi_check_volume+0xa0/0xd4)                                                           
[   24.451823] [<803b9c8c>] (ubi_check_volume) from [<803b0150>] (ubi_open_volume.part.0+0x130/0x294)                                                   
[   24.460933] [<803b0150>] (ubi_open_volume.part.0) from [<803ae1a8>] (vol_cdev_open+0x3c/0x54)                                                        
[   24.469604] [<803ae1a8>] (vol_cdev_open) from [<800ec218>] (chrdev_open+0xc4/0x180)                                                                  
[   24.477397] [<800ec218>] (chrdev_open) from [<800e66c0>] (do_dentry_open.constprop.3+0x1f0/0x2f8)                                                    
[   24.486422] [<800e66c0>] (do_dentry_open.constprop.3) from [<800f52b8>] (do_last.constprop.16+0x530/0xc28)                                           
[   24.496236] [<800f52b8>] (do_last.constprop.16) from [<800f5a2c>] (path_openat+0x7c/0x5cc)                                                           
[   24.504639] [<800f5a2c>] (path_openat) from [<800f6abc>] (do_filp_open+0x2c/0x88)                                                                    
[   24.512249] [<800f6abc>] (do_filp_open) from [<800e778c>] (do_sys_open+0x10c/0x1d0)                                                                  
[   24.520037] [<800e778c>] (do_sys_open) from [<8000f280>] (ret_fast_syscall+0x0/0x3c)                                                                 
[   24.535917] ubi0 warning: ubi_eba_read_leb: CRC error: calculated 0xe4c717e8, must be 0x5953ee96                                                     
[   24.544937] ubi0 warning: ubi_open_volume: volume 2 on UBI device 0 is corrupted

If i redo command

ubiupdatevol /dev/ubi0_2 Myfile_FreeRTOS_V1_0.elf

there is no more return info

I don’t understand what is the problem.

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?

You can clear the volume by using ubi erase.part ubi in the U-Boot command prompt and reinstall the image using Toradex Easy Installer or using the legacy update mechanism.

Thanks for your help, stefan!

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}'

For newbie like me, commands below must be done once :

setenv m4boot 'ubi read ${loadaddr} m4firmware && dcache flush && bootaux ${loadaddr}'

I don’t see these command on page :
FreeRTOS on the Cortex-M4 of a Colibri iMX7 : Store a Firmware on Flash and Run it on Boot

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

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


I’ve little update regarding UBI static volumes.

It seems that either

  • 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.


Hi @Edward !

As you are using a Colibri iMX6ULL (and no Colibri iMX7), I would like to ask you to create a new topic about this issue.

You can refer to this topic on your new topic.

On the new topic, please share all the information about your setup (with full module name and version) and the steps to reproduce it as well.

Best regards,

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.