[PATCH] Newly erased page read workaround
Ivan Djelic
ivan.djelic at parrot.com
Thu Feb 24 06:10:21 EST 2011
On Thu, Feb 24, 2011 at 10:20:59AM +0000, Vipin Kumar wrote:
> On 2/24/2011 3:08 PM, Ivan Djelic wrote:
(...)
> > Just a suggestion: maybe you could mention in your comments the fact that you
> > cannot workaround the problem using a mask to get a valid ECC on erased pages,
> > because your controller does not allow it ?
> >
> > If you plan to use your workaround on recent NAND devices with UBIFS, you may
> > still experience problems because of uncorrected bitflips on erased pages, and
> > get errors such as:
> >
>
> Let me explain the problem again.
>
> The problem is that the BCH algorithm (used by this controller to generate ecc
> and correct bitflips) generates an ecc which is not 0xffff for an erased 512
> bytes.
>
> Since erasing a page results in all data including the spare area of the page
> resetting to 0xffff, and the ecc written in the spare area is incorrect.
> This ecc is not useful to correct bitflips
>
> One way to solve this problem is to write the correct ecc in the erased pages
> spare area. The other is to ensure that the page is erased and not run the
> correction algorithm.
There is a third option: add (before writing oob/after reading oob) a fixed
polynomial to your HW-generated BCH ECC codeword. This polynomial is chosen such
that your ECC code on an erased page now becomes a sequence of 0xff bytes.
That way, erased pages can be read with ECC check enabled. That was my point.
I assume you cannot alter oob contents as described above, because your controller
performs error detection "on-the-fly" as you transfer data to/from NAND device (?).
> We are using the second option but there would not be
> any unwanted bitflips in any of the cases.
On recent NAND devices, bitflips _do_ appear on erased pages, sometimes immediately
after a block erase.
Regards,
Ivan
More information about the linux-mtd
mailing list