[PATCH 1/2] mtd: nand: add erased-page bitflip correction

[Brian Norris]

Hi Pekon,

On Thu, Mar 13, 2014 at 05:55:32AM +0000, Pekon Gupta wrote:
> >From: Brian Norris [mailto:computersforpeace at gmail.com]
> >On Wed, Mar 12, 2014 at 01:45:15PM +0100, Elie De Brauwer wrote:
> >> b) "determining you read an erased page". In case of the i.mx (and
> >> thus GPMI) the BCH block can tell you three things:
> >>  1. I read all 0xff's
> >>  2. I read some data and nothing got corrected
> >>  3. I read something but failed to correct it.
> >> The third case can have two causes:
> >>  3.a you read valid data with bitflips exceeding what the BCH could
> >> correct
> >>  3.b you read an erased page with bitflips.
> >>
> >> Obviously case 3.b is what this discussion is all about, and my quest
> >> revolved around a means to quickly identify case '3.b'.
> >
> >Yes, 3.a vs. 3.b is the big problem.
[...]

> I think for OMAP NAND driver there needs to be some help on "1." also.
> There is no hardware support in GPMC (Ti's controller) to find out if the
> (read_data + read_oob) == 0xff. So you have to do this comparison in
> software.

Really? So if you read a blank (all 0xff) page that has no bitflips, you
see an ECC error? I'm sorry, but I didn't realize that's how your
hardware worked. That's the worst hardware ECC design I've seen so far
:(

So currently, omap2.c tries to mitigate the overhead of checking 1 (and
3.b) by using a fixed-offset "programmed" marker, right? But this isn't
workable for all platforms (why, exactly?) so you're trying to remove
this marker in your patch sets, right? (Could you possibly move the
marker somewhere else, depending on the platform? But admittedly, this
is still fragile.)

In any case, if the special marker approach fails, you're falling back
to an approach similar to the Freescale approach (and mine), with a few
extra tweaks.

> And, thus there is performance penalty right at first-step.
> (I'm trying to get the statistics of this soon).

Yes, that would be nice.

Brian