ubiformat and nandwrite

轉載自http://www.linux-mtd.infradead.org/faq/ubifs.html

 

Why do I have to use ubiformat?

The first obvious reason is that ubiformat preserves erase counters, so you do not lose your wear-leveling information when flashing new images.

The other reason is more subtle, and specific to NAND flashes which have ECC calculation algorithm which produces ECC code not equivalent to all 0xFF bytes if the NAND page contains only 0xFF bytes. Consider an example.

• We erase whole flash, so everything is 0xFF'ed now.
• We write an UBI/UBIFS image to flash using nandwrite.
• Some eraseblocks in the UBIFS image may contain several empty NAND pages at the end, and UBIFS will write to them when it is run.
• The nandwrite utility writes whole image, and it explicitly writes 0xFF bytes to those NAND pages.
• The ECC checksums are calculated for these 0xFF'ed NAND pages and are stored in the OOB area. The ECC codes are not 0xFF'ed. This is often the case for HW ECC calculation engines, and it is difficult to fix this. Normally, ECC codes should be 0xFF'ed for such pages.
• When later UBIFS runs, it writes data to these NAND pages, which means that a new ECC code is calculated, and written on top of the existing one (unsuccessfully, of course). This may trigger an error straight away, but usually at this point no error is triggered.
• At some point UBIFS is trying to read from these pages, and gets and an ECC error (-EBADMSG = -74).

In fewer words, ubiformat makes sure that every NAND page is written once and only once after the erasure. If you use nandwrite, some pages are written twice - once bynandwrite, and once by UBIFS.

If you can not use ubiformat, an alternative is to set the "free space fixup" flag when generating the UBIFS image (see here).

What is the the purpose of the -F (--space-fixup) mkfs.ubifs option?

Because of subtle ECC errors that can arise when programming NAND flash (see here), ubiformat is the recommended way of flashing a UBI image which contains a UBIFS file system. However, this is not always possible - for example, some embedded devices are manufactured using an industrial NAND flash programmer which has no knowledge of UBI or UBIFS.

The -F option causes mkfs.ubifs to set a special flag in the superblock, which triggers a "free space fixup" procedure in the kernel the very first time the filesystem is mounted. This fixup procedure involves finding all empty pages in the UBIFS file system and re-erasing them. This ensures that NAND pages which contain all 0xFF data get fully erased, which removes any problematic non-0xFF data from their OOB areas.

Of course it is not possible to re-erase individual NAND pages, and entire PEBs are erased. UBIFS performs this procedure by reading the useful (non 0xFF'ed) contents of LEBs and then invoking the atomic LEB change UBI operation. Obviously, this means that UBIFS has to read and write a lot of LEBs which takes time. But this happens only once, and the "free space fixup" procedure then unsets the "fixup" UBIFS superblock flag.

This option is supported if you are running a kernel version 3.0 or higher, or if you have pulled the changes from a UBIFS back-port tree. Note that ubiformat is still the preferred flashing method if the image is not being flashed for the first time, since it preserves existing erase counters (while using nandwrite or its equivalent does not).