Nandflash镜像尾部不应填充0xFF

Nandflash镜像文件系统尾部经常被填充0xFF以补齐大小，这样做是错误的，可能会有意想不到的bug。包括JFFS2、UBIFS等。

因此建议丢弃多余的0xFF。

出自：http://www.linux-mtd.infradead.org/doc/ubi.html

If your UBI image contains UBIFS file system, and your flash is NAND, you may have to drop 0xFF bytes the end of input PEB data. This is very important, although not required for all NAND flashes. Sometimes a failure to do this may result in very unpleasant problems which might be difficult to debug later. So we recommend to always do this.

The reason for this is that UBIFS treats NAND pages which contain only 0xFF bytes (let's refer them to as empty NAND pages) as free. For example, suppose the first NAND page of a PEB has some data, the second one is empty, the third one also has some data, the fourth one and the rest of NAND pages are empty as well. In this case UBIFS will treat all NAND pages starting from the fourth one as free, and will write data there. If the flasher program has already written 0xFF's to these pages, then any new UBIFS data will cause a second write. However, many NAND flashes require NAND pages to be written only once, even if the data contains only 0xFF bytes.

To put it differently, writing 0xFF bytes may have side-effects. What the flasher has to do is to drop all empty NAND pages from the end of the PEB buffer before writing it. It is not necessary to drop all empty NAND pages, just the last ones. This means that the flasher does not have to scan whole buffer for 0xFF's. It is enough to scan the buffer from the end and stop on the first non-0xFF byte. This is much faster. Here is the code from UBI which does the right thing.

/**

* calc_data_len - calculate how much real data are stored in a buffer.

* @ubi: UBI device description object

* @buf: a buffer with the contents of the physical eraseblock

* @length: the buffer length

*

* This function calculates how much "real data" is stored in @buf and returns

* the length. Continuous 0xFF bytes at the end of the buffer are not

* considered as "real data".

*/

int ubi_calc_data_len(const struct ubi_device *ubi, const void *buf,

int length)

{

int i;

for (i = length - 1; i >= 0; i--)

if (((const uint8_t *)buf)[i] != 0xFF)

break;

/* The resulting length must be aligned to the minimum flash I/O size */

length = ALIGN(i + 1, ubi->min_io_size);

return length;

}

This function is called before writing the buf buffer to the PEB. The purpose of this function is to drop 0xFF's from the end and prevent the situation described above. The ubi->min_io_size is the minimal input/output unit size which is equivalent to NAND page size.

By the way, we experienced the similar problems with JFFS2. The JFFS2 images generated by the mkfs.jffs2 program were padded to the physical eraseblock size and were later flashed to our NAND. The flasher did not bother skipping empty NAND pages. When JFFS2 was mounted, it wrote to those NAND pages, and the writes did not fail. But later we observed weird ECC errors. It took a while to find out the problem. In other words, this is also relevant to JFFS2 images.

An alternative to this approach is to enable the "free space fixup" option when generating the UBIFS file system using mkfs.ubifs. This will allow your flasher to not have to worry about 0xFF bytes at the end of PEBs, which is particularly useful if you need to use an industrial flash programmer to write a UBI image. More information is available here.