From: Norbert van Bolhuis <nvbolhuis@aimvalley.nl>
To: "Thorsten Mühlfelder" <muehlfelder@enertex.de>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Some questions on bit-flips and JFFS2
Date: Wed, 05 May 2010 10:34:14 +0200 [thread overview]
Message-ID: <4BE12D86.2070605@aimvalley.nl> (raw)
In-Reply-To: <201005041659.26262.muehlfelder@enertex.de>
Thorsten Mühlfelder wrote:
.
.
.
>> Maybe, as said check/ask your hardware supplier.
>> Maybe "refreshing" the block helps (that is saving the data, erasing the
>> block(s) and reprogramming all data). You could try this.
>
> I've already thought about something like this:
> 1. After first succesful bootup dump a mtd0 image and calculate a md5sum of
> it:
> nanddump -o -b -f mtd0.img /dev/mtd0
> 2. Before each shutdown dump the image again and check if the md5sum has
> changed.
> 3. If it has changed write the initial dump back:
> flash_eraseall /dev/mtd0
> nandwrite -p /dev/mtd0 mtd0.img
>
> Would this be the right method?
>
yes that's the idea, given that "refreshing" really helps to prevent
(actually delay) future read disturbs.
But this won't work well. nanddump doesn't tell you the single=corrected
bit errors.
Only if there's an uncorrectable error (2 or more bits flip) a change will
be detected and the data will be refreshed. A read disturb tends to be
unstable though, meaning sometimes it's there and sometimes not.
This means you may miss an uncorrectable error (2 bits flip).
Another problem is a sudden reboot (e.g. crash or power-loss). There's no
check then.
It much more easier to let UBI/UBIFS deal with this suff. It's designed for
this.
u-boot support UBIFS (read-only). This means you can put a kernel image
on UBIFS and make u-boot read/boot it.
hth,
Norbert van Bolhuis.
next prev parent reply other threads:[~2010-05-05 8:34 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-03 13:05 Some questions on bit-flips and JFFS2 Thorsten Mühlfelder
2010-05-04 9:28 ` Norbert van Bolhuis
2010-05-04 14:59 ` Thorsten Mühlfelder
2010-05-05 8:34 ` Norbert van Bolhuis [this message]
2010-05-05 8:40 ` Ricard Wanderlof
2010-05-05 8:51 ` Artem Bityutskiy
2010-05-05 9:20 ` Ricard Wanderlof
2010-05-11 7:59 ` Thorsten Mühlfelder
2010-05-11 9:35 ` Ricard Wanderlof
2010-05-12 11:21 ` Thorsten Mühlfelder
2010-05-12 12:22 ` Ricard Wanderlof
2010-05-19 7:45 ` Thorsten Mühlfelder
2010-05-05 9:29 ` Norbert van Bolhuis
2010-05-11 8:09 ` Thorsten Mühlfelder
2010-05-11 14:55 ` Norbert van Bolhuis
2010-05-12 10:48 ` Thorsten Mühlfelder
2010-05-05 6:59 ` Ricard Wanderlof
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=4BE12D86.2070605@aimvalley.nl \
--to=nvbolhuis@aimvalley.nl \
--cc=linux-mtd@lists.infradead.org \
--cc=muehlfelder@enertex.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.