public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Grant Erickson <gerickson@nuovations.com>
To: "\"linux-mtd@lists.infradead.org\"" <linux-mtd@lists.infradead.org>
Subject: Replicating One NAND Partition to Another
Date: Wed, 13 Aug 2008 08:57:00 -0700	[thread overview]
Message-ID: <C4C8525C.11068%gerickson@nuovations.com> (raw)

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

                 reply	other threads:[~2008-08-13 15:57 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C4C8525C.11068%gerickson@nuovations.com \
    --to=gerickson@nuovations.com \
    --cc=linux-mtd@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox