'ubi clone' from Live NAND.

[Brian Norris]

As a NAND driver developer and a developer of nanddump / nandwrite, I
have some comments. Note, however, that I have not tried this kind of
UBI clone, so my suggestions are somewhat of educated guesses.

On Thu, Mar 7, 2013 at 4:11 AM, Gupta, Pekon <pekon at ti.com> wrote:
>> If 'rootfs.ubi' is the 'ubinize' image, then I can mount and see the
>> file system on my PC.  However, if the 'rootfs.ubi' is a 'dump' of the
>> NAND flash, I fail with the following 'dmesg',
>
> [pekon]
> I have tried this, using following steps, and it works well
>
> (1) nanddump   -b -s 0x0  -l <size_of_source_partition>  -f  <image_dump.bin>  <source_partition>

FYI, "-b" (or "omitbad") has been dropped from recent nanddump
releases. A similar (but not identical) option is now available as
--bb=skipbad (default). And then, you probably don't want to specify a
-l (length) option, since the length actually refers to the length of
the resulting image, which may vary depending on the number of bad
blocks. So, with recent mtd-utils releases, the equivalent dump would
be:

nanddump --bb=skipbad -s 0x0 -f <image_dump.bin> <source_partition>

or, because many of the provided options are defaults, the following
is also equivalent:

nanddump -f <image_dump.bin> <source_partition>

> (2) flash_erase   <target_partition>  0 0
> (3) nandwrite -n -r   <target_partition>         <image_dump.bin>

This looks likely to cause problems. See my comment below.

> where,
> source_partition= partition on source device from which NAND binary would be dumped. (/dev/mtdX)
> target_partition= partition on another device which NAND dumped image would be flashed (/dev/mtdY)
>
>
> You need to keep few things in mind..
> (1) sizeof(target_partion) > sizeof(source_partition), So as to take care of bad-blocks present on target device.
>
> (2) '-n' option in nandwrite tells NAND driver not to calculate ECC while programming nand, as its is already part of 'raw' binary image

The image dump command above does not contain any ECC information, so
when you write with '-n', you aren't writing *any* ECC information.
This is quite likely to cause your ECC decoder to flag all your data
as uncorrectable. Are you sure this has worked for any length of time?
I would strongly recommend against writing your image in this way.

I'm guessing that your recommendation of '-n' (no ECC) is to solve the
0xFF page problem, documented here?

http://www.linux-mtd.infradead.org/faq/ubifs.html#L_why_ubiformat

Anyway, I don't think you want nandwrite; just use ubiformat.

Brian