Data integrity check after UBIFORMAT? Bad image sequence number error.

[Richard Weinberger]

On Tue, Jun 9, 2015 at 10:02 AM, t kevin <kevint324 at gmail.com> wrote:
> Hi,
>
> We are using kernel 2.6.36 and mtd-util-1.5.1 on our box.
> During system upgrade, very very occasionally ( 1 in 100, maybe? ) I
> get this error at ubiattach after ubiformat.
>
> [ 1632.520000] UBI: attaching mtd8 to ubi0
> [ 1632.520000] UBI: physical eraseblock size: 131072 bytes (128 KiB)
> [ 1632.530000] UBI: logical eraseblock size: 126976 bytes
> [ 1632.530000] UBI: smallest flash I/O unit: 2048
> [ 1632.540000] UBI: sub-page size: 512
> [ 1632.540000] UBI: VID header offset: 2048 (aligned 2048)
> [ 1632.550000] UBI: data offset: 4096
> [ 1633.190000] UBI error: process_eb: bad image sequence number
> 559476870 in PEB 635, expected 139654706
>
> I understand ubiformat generate a random sequence number and write the
> sequence number to all PEB. So it seems an expected sequence number
> somehow is not written into nand flash correctly.

Are you sure about that?
Can it be that 559476870 is the seq number of the old image and the
new one is too small?
This is one of the main reasons why we have that number, such that
UBI can detect a partial written image.

> So I changed my upgrade sequence like below
>
> ubiformat ubi.img /dev/mtdx
> ubiattach /dev/mtdx
>
> if [ "$?" != "0" ]
>     #do ubiformat again
>     ubiformat ubi.img /dev/mtdx

You format it while it is attached?

> My question are,
> 1. What could possibly be wrong that caused the ubiformat fail?

It can be a faulty MTD driver, a usage error, everything.

> 2. Is there a way to verify the data integrity after a UBIFORMAT
> process? Something like "mtd verify" function.

I fear the answer is "no".

Thanks,
//richard