Programming ubinized images

[Matthew L. Creech]

Hi,

I'm curious about the implications of these notes in the UBI documentation:

http://www.linux-mtd.infradead.org/faq/ubi.html#L_ecc_error
http://www.linux-mtd.infradead.org/faq/ubifs.html#L_why_ubiformat
http://www.linux-mtd.infradead.org/faq/ubifs.html#L_mkfubifs
http://www.linux-mtd.infradead.org/doc/ubi.html#L_flasher_algo

which seem to be saying that:

1. A ubinized image can contain empty (all-0xff) pages at the end
2. At run-time, it will assume that these pages are completely erased
(including corresponding OOB areas)
3. Standard NAND flashing utilities will view the 0xff pages as normal
data and program their OOB areas
4. This will cause errors when UBIFS tries to use these areas, because
it double-programs OOB/ECC (presumably resulting in some sort of
ANDing of bits)

Does this mean that an off-the-shelf NAND programmer can't be used to
program UBIFS images onto a flash device?  Or perhaps that I need to
be post-processing the ubinized images to strip out empty pages from
the end of the image before giving it to the production line?

We encountered one case in which we were re-flashing a device for
testing using U-Boot's "nand erase", and got the "ubi_io_read: error
-74" error from the FAQ.  That's no big deal, since we never do this
in the field, and clearly "nand erase" isn't something we'd want to do
even without this problem since it loses erase-counter info.

However, I'm wondering if some of the persistent UBIFS problems we've
been experiencing since last year:

http://lists.infradead.org/pipermail/linux-mtd/2010-July/031069.html

could be occurring simply because we're not stripping empty pages from
the end of the ubinized image before programming.  Does this seem like
a possibility, or do I need to keep looking elsewhere?  Any tips are
appreciated, thanks!

-- 
Matthew L. Creech