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