From: "Ulf Samuelsson" <ulf@atmel.com>
To: "Creech, Matthew" <MattCreech@eaton.com>,
<linux-mtd@lists.infradead.org>, <jffs-dev@axis.com>,
<linux-arm-kernel@lists.arm.linux.org.uk>
Subject: Re: JFFS2 on dataflash problem
Date: Wed, 2 Feb 2005 22:32:27 +0100 [thread overview]
Message-ID: <01c401c50970$3ed65c30$4c7370d5@Glamdring> (raw)
In-Reply-To: F0A064EBC8C91C449244D108367426DC01E4AFEF@ra1ncsmb01.nasa.ad.etn.com
> I have an embedded device based on Atmel's AT91RM9200DK board, which is
> using serial dataflash (AT45DB642). I've allocated a JFFS2 partition to
> store non-volatile data. In testing I stumbled across a particular
> problem that only occurs after heavy hammering on our device, but is
> fairly consistent in how and when it occurs. The pattern has been
> narrowed down so that a script doing something like this:
> while [ 1 ]; do
> cp /mnt/jffs2/$RANDOM_FILE /mnt/jffs2/$BLAH
> # File size has been tested between 8K and 64K
> done
If I wrote this script I would call it:
wear_out_dataflash_quickly.sh
There are some limitations to the number of erase cycles in the dataflash.
(IN any flash to be correct)
You can expect to reprogram it 50,000-100.000 times before the first errors
occur.
The second thing is that you need to do a block erase after the sum
of erases inside an 8 page block exceeds 10,000.
I am not at all sure that the MTD drivers/JFFS2 handle this (did not look at
the code).
I assume that JFFS may be able to detect a bad write and map
the block out from time to time, so this could explain why you can do the
recover.
If you really want to test the dataflash, write a CRC in the extra bytes
available.
(The page is 1024 + 32 bytes) and read back, checking CRC.
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
next prev parent reply other threads:[~2005-02-02 21:43 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-02 15:00 JFFS2 on dataflash problem Creech, Matthew
2005-02-02 21:32 ` Ulf Samuelsson [this message]
2005-02-02 22:22 ` Thomas Gleixner
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='01c401c50970$3ed65c30$4c7370d5@Glamdring' \
--to=ulf@atmel.com \
--cc=MattCreech@eaton.com \
--cc=jffs-dev@axis.com \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--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