Thanks for the elaborate response.
I will go over your test and see what I can come up with.
I saw there are some built in test in the linux kernel which can be built as
modules and then loaded for testing...
Thanks,
________________________________________
From:
yaffs-bounces@lists.aleph1.co.uk [
yaffs-bounces@lists.aleph1.co.uk] On Behalf Of Ross Younger [
yaffs@impropriety.org.uk]
Sent: Tuesday, December 28, 2010 11:58 PM
To:
yaffs@lists.aleph1.co.uk
Subject: Re: [Yaffs] yaffs2 block retirement issue
* Boaz Ben-David <
boaz.bd@wellsense-tech.com> wrote:
> Could it be that the nand driver is writing some data to the spare area
> and this is why yaffs thinks the block is bad?
YAFFS relies on being able to write to the spare area. If this (or
reading back the spare area) fails in some way that would be entirely
consistent with what you're experiencing.
I see from your trace you've got a few instances of "eccres 3" and "eccr
3". This is mapped (in yaffs_guts.h) to YAFFS_ECC_RESULT_UNFIXED. In
other words, an ECC check failed - but that's not a smoking gun, there
are several potential causes.
If I were you I'd look into putting together some low-level NAND tests.
You need to ensure that you can reliably write arbitrary data to NAND
pages and their spare areas, and read it all back, at full speed (whatever
that means to your application); without that, you're only going to
confuse both YAFFS and yourself.
Hopefully somebody out there will suggest some Linux-based
tests. If not, you might care to look at what I wrote for eCos
some months ago - though you're probably better off using them
only as inspiration and writing your own, rather than adapting,
as they're very specific to that platform. They can be found at
http://hg-pub.ecoscentric.com/nand-ecoscentric/file/a9d12f1a0c5b/packages/io/nand/current/tests
- nand_readwrite.c is probably the most useful.
Ross
_______________________________________________
yaffs mailing list
yaffs@lists.aleph1.co.uk
http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs