public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
* Replicating One NAND Partition to Another
@ 2008-08-13 15:57 Grant Erickson
  0 siblings, 0 replies; only message in thread
From: Grant Erickson @ 2008-08-13 15:57 UTC (permalink / raw)
  To: "linux-mtd@lists.infradead.org"

What is the most effective or the recommended way to replicate one like NAND
partition to another?

Ideally, I would anticipate doing something to the effect of:

    flash_eraseall -q <device-out>
    nanddump -o -b -s <offset> -l <size> <device-in> | nandwrite -q -p -s
<offset> <device-out>

However, because nandwrite does not read from standard input, something akin
to the following might the practical solution:

    mktemp nanddump.XXXXXX
    nanddump -o -b -s <offset> -l <size> -f /tmp/nanddump.XXXXXXX
<device-in>
    flash_eraseall -q <device-out>
    nandwrite -q -p -s <offset> <device-out> /tmp/nanddump.XXXXXXX

However, this practical realization appears to have two downsides:

    1) The creation of a potentially large intermediate file in tmpfs.
    2) Digest of the original input image and dumps do not match.

Regarding (1), is there any practical reason that nandwrite could not be
modified to read from standard input or a new utility created (e.g. 'nandcp
[options] <device-in> <device-out>')?

Regarding (2), page padding bytes and a lack of deblocking said page padding
when the '-l' (length) option is used seems to be the case:

    # ls -la boot.itb
    -rw-r--r--    1 root     root      1297520 Aug  9  2008 boot.itb

    # md5sum boot.itb
    a8e2abd075f6e6f818452c89b7c87660  boot.itb

    # flash_eraseall -q /dev/mtd8
    # nandwrite -q -p -s 0 /dev/mtd8 boot.itb
    # nanddump -o -b -s 0 -l 1297520 /dev/mtd8 | md5sum
    ...
    615ba64c881eee61eb73ad1f7c79f673  -
    # nanddump -o -b -s 0 -l 1297520 -f /tmp/nanddump.vhCgSM /dev/mtd8
    ...
    # md5sum /tmp/nanddump.vhCgSM
    615ba64c881eee61eb73ad1f7c79f673  /tmp/nanddump.vhCgSM
    # flash_eraseall -q /dev/mtd10
    # nandwrite -q -p -s 0 /dev/mtd10 /tmp/nanddump.vhCgSM

    # nanddump -o -b -s 0 -l 1297520 /dev/mtd10 | md5sum
    ...
    615ba64c881eee61eb73ad1f7c79f673  -
    # mktemp -t nanddump.XXXXXX
    /tmp/nanddump.ir7EKh
    # nanddump -o -b -s 0 -l 1297520 /dev/mtd10 -f /tmp/nanddump.ir7EKh
    ...
    # md5sum /tmp/nanddump.ir7EKh
    615ba64c881eee61eb73ad1f7c79f673  /tmp/nanddump.ir7EKh
    # ls -la /tmp/nanddump.ir7EKh
    -rw-r--r--    1 root     root      1297920 Jan  1 00:08
/tmp/nanddump.ir7EKh

I would have expected usage of the '-l' (length) option to have deblocked
such page padding. Is this lack of deblocking when the '-l' option is
present intentional?

Regards,

Grant Erickson

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2008-08-13 15:57 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-08-13 15:57 Replicating One NAND Partition to Another Grant Erickson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox