On Thursday 20 January 2005 23:02, Jacob Dall wrote:
> Hello yaffers,
>
> I've a few questions regarding why yaffs' bad block management is designed
> the way it is.
>
> According to Toshiba, NAND failures can be distinguished as "permanent
> failures" or "soft errors"
>
> 1) Permanent failures: this error occurs when programming or erasing, and
> can be detected by reading the status register after operation.
>
> 2) Soft errors: this error occurs during a program, but can only be
> detected by reads. The error is cleared by a block erase.
>
> Now, upon read, if yaffs detects an unfixable ECC error in a page, the
> block holding that page is marked as bad. According to 2) it would be ok to
> just mark the page as discarded and let the garbage collector do its job -
> or have I missed something?

This mechanism was designed before Toshiba shared their wonderful document 
with the world. I have considered changing this, but it has never been a very 
high priority and it does put data at risk.

The "soft errors" are typically  write disturb failures that can (hopefully) 
be fixed by ECC.  My concern is that if a block displays write disturb 
problems then perhaps it is "going bad". ECC can only fix single bit errors. 
I don't want to wait until it has "gone bad" and lost data before I retire 
it. I'd prefer to retire dodgy looking blocks earlier.

>
> In yaffs, a block is marked bad by writing 0 to byte 517 in page 0 / 1 in
> the block. Why wasn't it decided to use another value (for instance, like
> SmartMedia's 0xF0). Then it would have been possible to destinguish initial
> bad blocks from operational bad blocks.

This was considered. However I decided to use 0x00 because this would have 
the most likelihood of programming a block where the bits don't "stick"well. 
A sparse bit pattern  is less likely to program than all 0s.

THis could be changed quite easily.

Generally the factory marked bad blocks are not just marked with this byte. 
Mostly the whole OOB area or even the whole block is marked zero. THis 
generally makes it easy enough to distnguish factor marked from YAFFS-marked 
bad blocks.

>
> I've an issue with some of my devices - bad blocks is increased very
> rapidly. Beyond the fact that it's due to ECC read errors, I'm yet to
> discover the root of the problem.


I've done extensive lifetime testing on some devices. One test I did wrote 
approx 130GB stuff, read and verified it with not one ECC failure or bit 
getting munged.

Some other people doing lifetime testing have expressed concern because they 
lose 1-2% of flash during the lifetime of a device.

What do you mean by  rapidly? I assume it is far worse than either of these!

If you're using Linuxx, then the most likely cuases of the problem are a miss 
match between the ECC strategy you're using in YAFFS and what you have 
configured in mtd.

>
> I'm not blaming yaffs - I'm sure the problem is to be found else where, but
> I'm thinking really hard of making those changes to yaffs, making me able
> to get back to the state when the NAND was first taken into use.
>
> Please let me know your reasons / thoughts...

Being able to change the bad block marker would help you with bench testing 
until you have fixed the real problem.

There are two things you could try:
1) In yaffs_RetireBlock, change the blockstatus to some easy to detect value 
that has at least two zero bits (eg. 0xFC).
2) Or even turn off the writing of bad block markers completely.  This would 
cause problems in the file system state, but that probably does not matter 
for you at the moment.

Of course I'm assuming you just want to do these changes while you find and 
fix the real problem.  I would not suggest shipping product with either of 
these changes.

>
>
> Thanks and regards,
> Jacob Dall
>
> FYI: the 'According to Toshiba' stuff was taken from a document named 'NAND
> Flash Application Design Guide'

Great doc. Should be required reading for anyone working with NAND.

>
>
> _______________________________________________
> yaffs mailing list
> yaffs@stoneboat.aleph1.co.uk
> http://stoneboat.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs