CONFIG_MTD_NAND_VERIFY_WRITE with Software ECC
Ricard Wanderlof
ricard.wanderlof at axis.com
Tue Feb 15 08:02:57 EST 2011
On Tue, 15 Feb 2011, David Peverley wrote:
> I've noticed that some of the problems we see are exacerbated further by
> us having CONFIG_MTD_NAND_VERIFY_WRITE enabled. In the case where blocks
> have occasional 1-bit ECC failures (i.e. normally correctable and not
> enough to warrant marking as bad) the generic verify routine will cause
> nand_write_page() to return failure. I've prototyped a verify routine
> that uses an ECC corrected read in our driver and it seems to do the job
> correctly.
I may be wrong here, but as I understand, normally, bit read errors occur
after a while (often called 'read disturb' in the literature) as the
contents of certain bit cells leak away (either over time, or by
accessing), first causing random data, and then after a while settling
down into a permanently inverted state, until the data is rewritten.
If this is the case, then a verify performed just after a write (which I'm
assuming is when it is performed) should yield correct data, unless a
given bit cell is in a really bad condition, in which case the block
should probably not be used anyway, as there as not been enough time for
the bit to decay for whatever reason.
Of course, if there are bit cells which have other failure modes, your
idea might help, but again, if a bit is in such a bad state as to not
being able to retain data between write and verify, the block should
probably be discarded (marked as bad) anyway.
One rationale would be that if you have one more or less permanently bad
bit, although it can be handled by ECC, as soon the contents of another
bit cell decays, the ECC won't be effective, so in practice, the ECC
strength is severely reduced for the page (or sub-page more likely, as ECC
usually operates over less-than-page sizes in modern flashes) in question.
/Ricard
--
Ricard Wolf Wanderlöf ricardw(at)axis.com
Axis Communications AB, Lund, Sweden www.axis.com
Phone +46 46 272 2016 Fax +46 46 13 61 30
More information about the linux-mtd
mailing list