Re: JFFS2 on dataflash problem
"Ulf Samuelsson" <[email protected]> Wed, 2 Feb 2005 22:32:27 +0100
| Newsgroups | gmane.linux.drivers.mtd,gmane.linux.file-systems.jffs,gmane.linux.ports.arm.kernel |
|---|---|
| Message-ID | <01c401c50970$3ed65c30$4c7370d5@Glamdring> |
> 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 [email protected] ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/