From: Lukasz Majewski <lukma@denx.de>
To: Richard Weinberger <richard.weinberger@gmail.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: SW ECC - double bit flip detection on old NAND devices
Date: Sun, 7 May 2017 22:24:04 +0200 [thread overview]
Message-ID: <20170507222404.241e7281@jawa> (raw)
In-Reply-To: <CAFLxGvzQ-OMhskGZ8V3EbG4GTR-6bLboZmNifoQ_3=VBstpM9g@mail.gmail.com>
Hi Richard,
Thanks for your support.
> Lukasz,
>
> On Fri, May 5, 2017 at 3:14 PM, Lukasz Majewski <lukma@denx.de> wrote:
> > Dear All,
> >
> > I've a problem with pretty old Flash NAND memory (Samsung 128Mx8)
> > [1]
> >
> > It doesn't support On-Chip ECC - one needs to calculate ECC
> > manually.
> >
> > The Yaffs2 FS (for this version) uses "1bit correction
> > ECC" (yaffs_ecc.c). It calculates ECC for 256 bytes -> we have got
> > 22 bits for ECC (rounded up to 3 bytes).
> >
> > For 2048 bytes page we do have 8 such ECC blocks -> 24 ECC bytes in
> > total in OOB.
> >
> > This code (as noted in yaffs_ecc.* header) is able to correct one
> > single bit flip.
> >
> > I've also looked into Linux kernel code for SW ECC calculation:
> >
> > http://elixir.free-electrons.com/linux/latest/source/drivers/mtd/nand/nand_ecc.c#L523
>
> This is for ecc->algo == NAND_ECC_HAMMING.
In my current 2.6.27 kernel it is called:
NAND_ECC_SOFT -> But this is the same.
the
ecc.correct = nand_correct_data()
, which has following statement in the function description:
*
* Detect and correct a 1 bit error for 256 byte block
*/
So now it is clear that two+ bit flips happening in the 256 B chunk
cannot be detected.
>
> > And here it is also explicitly said that we can correct one bit in
> > such chunk.
> >
> > Please correct me if I'm wrong but when we have two bit-flips in
> > such 256 bytes chunk, the ECC will be still correct and such
> > obviously broken page will not be "retired".
> >
> > What one can do to prevent such situation?
> >
> > My idea, if the above holds, would be to implement better ECC
> > scheme as proposed in "Error Correction Code (ECC) in Micron" doc
> > [2].
> >
> > Maybe somebody knows better/simpler solution?
>
> I'd suggest to use BCH instead of Hamming.
> Please see NAND_ECC_BCH.
Thanks for your tip. I will try to backport this feature ...
>
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
prev parent reply other threads:[~2017-05-07 20:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-05 13:14 SW ECC - double bit flip detection on old NAND devices Lukasz Majewski
2017-05-07 13:53 ` Richard Weinberger
2017-05-07 20:24 ` Lukasz Majewski [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170507222404.241e7281@jawa \
--to=lukma@denx.de \
--cc=linux-mtd@lists.infradead.org \
--cc=richard.weinberger@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.