From: Brian Foster <brian.foster@maximintegrated.com>
To: David Mosberger-Tang <dmosberger@gmail.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: [Q] Using Micron 4-bit on-die ECC with v2.6.36 kernel?
Date: Wed, 3 Jul 2013 10:49:17 +0200 [thread overview]
Message-ID: <2540574.yn0MEqSsGa@laclwks004> (raw)
In-Reply-To: <CACwUX0O37px3-cDAScXaFdQPahtnTayN0HKD_dz7U6dD69EURw@mail.gmail.com>
On Wednesday 19-June-2013 14:40:45 David Mosberger-Tang wrote:
> Attached is a patch relative to 2.6.27.y. We use it with a 16-bit
> wide Micron part needing 4-bit ECC. It works for us, YMMV. I'm
> pretty sure the raw access is broken badly but we are not using that
> so it's not a problem from us. The patch assumes that on-die ECC is
> enabled in the bootstrap loader.
David,
Thanks! I've been working on getting our kernel and Das U-Boot
up to a common baseline w.r.t. the NAND-handling (including a
on-die compatible BBT layout in the OOB and other details), so
I had not looked too closely at your Patch until now-ish....
In examining it, I may have spotted an oddity: When counting
bit-flips, you only count them in the main-data area and in
the ECC-area (in the OOB). What you do not count are any in
the on-die ECC-protected bits in the OOB (which, in fact,
happens to be all of .oobfree).
Whilst not necessarily wrong, it does mean you may under-count
the true number of ECC-detected bit-flips, under-reporting the
number of corrections, and hence (inadvertently?) fooling the
system into thinking the block is in better health than it
really is.
Or I may mis-understanding something here....
cheers!
-blf-
--
Brian Foster
Principal MTS, Software | La Ciotat, France
Maxim Integrated | http://www.maximintegrated.com/
next prev parent reply other threads:[~2013-07-03 8:49 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-19 14:14 [Q] Using Micron 4-bit on-die ECC with v2.6.36 kernel? Brian Foster
2013-06-19 21:40 ` David Mosberger-Tang
2013-07-03 8:49 ` Brian Foster [this message]
[not found] ` <CACwUX0NXgTC=uQ7CZoY=anBuMhfyN31GFuYAV5EhBUZT9Nm2_w@mail.gmail.com>
2013-07-04 12:05 ` [PATCH] Init ONFI get/set features in a more logical place Brian Foster
2013-08-05 9:39 ` Artem Bityutskiy
2013-07-04 12:35 ` [Q] Using Micron 4-bit on-die ECC with v2.6.36 kernel? Brian Foster
[not found] ` <CACwUX0PaXg+hAqjeB2AK+7FEzr506RTNfNSHQAW+BJ-AnAQxKA@mail.gmail.com>
2013-07-04 13:07 ` Brian Foster
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=2540574.yn0MEqSsGa@laclwks004 \
--to=brian.foster@maximintegrated.com \
--cc=dmosberger@gmail.com \
--cc=linux-mtd@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox