Re: [RFC PATCH 2/2] mtd: nand: use nand_check_erased_ecc_chunk in default ECC read functions

Boris Brezillon
2015-07-31T14:10:58Z

On Fri, 31 Jul 2015 15:40:13 +0200
Andrea Scian <rnd4@dave-tech.it> wrote:

>
> Boris,
>
> Il 31/07/2015 12:32, Boris Brezillon ha scritto:
> > Hi Andrea,
> >
> > Adding Han in Cc.
> >
> > On Fri, 31 Jul 2015 12:07:21 +0200
> > Andrea Scian <rnd4@dave-tech.it> wrote:
> >
> >>
> >> Dear Boris,
> >>
> >>
> >> Il 30/07/2015 19:34, Boris Brezillon ha scritto:
> >>> The default NAND read functions are relying on an underlying controller
> >>> to correct bitflips, but some of those controller cannot properly fix
> >>> bitflips in erased pages.
> >>> In case of ECC failures, check if the page of subpage is empty before
> >>> reporting an ECC failure.
> >>
> >> I'm still wondering if chip->ecc.strength is the right threshold.
> >>
> >> Did you see my comments here [1]? WDYT?
> >
> > Yes I've read it, and decided to go for ecc->strength as a first
> > step (I'm more interested in discussing the approach than the threshold
> > value right now ;-)).
>
> I perfectly understand, that's the reason why I ask if you want to move
> to another thread ;-)
>
> > Anyway, as you pointed out in the thread, writing data on an erased
> > page already containing some bitflips might generate even more
> > bitflips, so using a different threshold for the erased page check
> > makes sense. This threshold should definitely be correlated to the ECC
> > strength, but how, that's the question.
> >
> > How about taking a rather conservative value like 10% of the specified
> > ECC strength, and see how it goes.
>
> Yes, I think that there's no real way to get the right value, other than
> feedbacks from on-field testing with various devices.
>
> I'm also thinking about changing how a NAND page is written on the
> device, now that we know that even erased page may have (too many!)
> bitflips if they has not been so-freshly erased.
>
> Read on NAND device is lot's faster that write, so maybe we can:
>
> a) read the page before write it, check for bitflips on erased area and
> write it only if it fit our threshold
>
> b) read the page after write it and check if the bitflips are lower that
> a give value
>
> In this way:
> - we can use ecc_strength as read threshold, because it fits all the
> other NAND read
>
> - we can use "something a bit lower than" mtd->bitflip_threshold on
> read-before-write or read-after-write. If we don't do so the block will
> be scrubbed next time we read it again (if we are lucky.. if we are
> unlucky the block will have bitflip > ecc_strength!): IOW we did a write
> that will trigger another erase/write cycle.
>
> Am I misunderstanding something?

Nope, but this implies doing an extra read after each write :-/

--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering