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: Tue, 04 May 2010 11:28:54 +0200 [thread overview]
Message-ID: <4BDFE8D6.1050704@aimvalley.nl> (raw)
In-Reply-To: <201005031505.18604.muehlfelder@enertex.de>
Thorsten Mühlfelder wrote:
> Hi there,
>
> I'm experiencing some problems with bit-flips on devices using NAND and JFFS2:
> NAND device: Manufacturer ID: 0x2c, Chip ID: 0xdc (Micron NAND 512MiB 3,3V
> 8-bit)
> Creating 2 MTD partitions on "NAND 512MiB 3,3V 8-bit":
> 0x00000000-0x00a00000 : "Bootloader Area"
> 0x00a00000-0x20000000 : "User Area"
>
> In rare cases 1 or 2 bits in the bootloader area (kernel) flip, so that the
> system won't boot anymore (kernel checksum error).
> As the bootloader image is not mounted at all I wonder if this may be caused
> by these read disturbs I've heard of.
>
This may very well be the case.
> I've found some statements from different people about it here on the ML:
>
>> We use JFFS2. As known JFFS2 detects and corrects single bit-flips
>> (per 256 byte subpage) but it doesn't physically correct them
>> on the NAND device itself.
>
> and:
>
>> AFAIK, jffs2 doesn't handle correctly bit flip on read: it won't try to
>> copy the data on another block while the data can still be recovered
>> by ecc.
>
> For me this means that data still is read correctly because of ECC but it
> won't get moved to a new block if a bit-flip happens? And what happens if
> this occours on the kernel partition?
>
True.
ECC is taken care of by the low-level MTD/NAND code
(e.g. drivers/mtd/nand/nand_base.c). These routines do indicate
errors but jffs2 doesn't really handle them (see jffs2_flash_read)
The kernel partition is a bare MTD(BLOCK) partition so the block won't
be moved or handled for sure. This means the same (=nothing) will happen.
> Furthermore:
>>> How about detection of ECC errors in read only partitions?
>> ECC should be done on both rw and read-only partitions. Sometimes NAND gets
>> read disturbs which would impact on read-only partitions. Also, write
>> disturbs from writes to one partition can still corrupt a read-only
>> partition on the same chip.
>
> So writing to my root partition may harm my kernel partition, too?
>
I don't know. Check/ask your hardware supplier. Micron may have some
details/documents about this.
> PS: I could not reproduce the bit-flip problem. It just happens in rare cases.
> Furthermore some of my devices are using Samsung NAND instead of the Micron
> NAND and did not show any problems yet. So perhaps my problem are just some
> bad NAND chip? But still I have to find a solution for the problem.
>
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.
The best solution is of course UBIFS. UBI/UBIFS will handle bad blocks and read/write
disturbs. Include your kernel partition into the (big) flash filesystem partition and
start using UBIFS (i.s.o. JFFS2).
hth,
Norbert van Bolhuis.
next prev parent reply other threads:[~2010-05-04 9:29 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 [this message]
2010-05-04 14:59 ` Thorsten Mühlfelder
2010-05-05 8:34 ` Norbert van Bolhuis
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=4BDFE8D6.1050704@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).