CONFIG_MTD_NAND_VERIFY_WRITE with Software ECC

[David Peverley]

Hi All,

> How about changing the MTD interface a little and teach it to:
> 1. Report the bit-flip level (or you name it properly) - the amount of
> bits flipped in this NAND page (or sub-page). If we read more than one
> NAND page at one go, and several pages had bit-flips of different level,
> report the maximum.
This is important to allow the file-system to make an informed
decision based on what happened within MTD. i.e. it would be able to
ascertain whether a read corrected N bit errors and thus be able to
re-program a block as required. I think is the only way to accomplish
handling this at the FS level? However, given that the count comes
from a specific read operation, I think it would need to be
implemented as part of the read call e.g. passing in something like
"unsigned *bit_errors"? This would mean changing something fundamental
or providing a new API to read with this extra parameter so I'm not
sure how this could be accomplished 'nicely'...

Something else to consider - what about bit-flips during writes? These
are currently only spotted if you enable write verify (and also not
dealt with or even notified beyond a generic errcode) and ought to be
handled / notified in a similar manner to the read but it's a lot
harder to decide how to split this functionality between the MTD and
FS layers as they're both closely involved. Not everyone wants to
enable the additional overhead of verifys. Would it be reasonable just
to leave it to the ECC check on the next read to that block instead?

In many ways it would be a lot easier (and involve only a single
implementation) to provide a config option where if a read or write in
MTD fails with a (correctable) bit flip or flips that the MTD itself
takes it on itself to erase the block and re-write the data cleanly. I
like this from the simplicity perspective and the fact it would be
transparent. However its contrary to the concept of this level of
management being performed exclusively by the FS layer. Of course you
still need some sort of stats collecting to help the FS if it wants to
use these stats to assist in deciding when to retire blocks...

~Pev