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: Thu, 4 Jul 2013 15:07:10 +0200 [thread overview]
Message-ID: <2596872.0DU6ch1YoB@laclwks004> (raw)
In-Reply-To: <CACwUX0PaXg+hAqjeB2AK+7FEzr506RTNfNSHQAW+BJ-AnAQxKA@mail.gmail.com>
On Thursday 04-July-2013 05:37:23 David Mosberger-Tang wrote:
> BBT markers don't assume ECC correction (there are multiple copies).
At least in v2.6.36, that is misleading albeit not
incorrect. There _is_ a duplicate BBT block (called
the “mirror”), but neither it nor the primary BBT block
have multiple copies of the BBT marker (or the version).
(And, as it happens, the markers differ between the two
blocks (I'm not too sure why?).)
So, unless both BBT blocks fail, you _should_ always
be able to find and use one. What happens if both
happen to fail (in v2.6.36) is not-clear (to me).
I have not checked to see what the situation is in the
latest kernel.
> However, I certainly agree that it'd be better to check all bits
> covered by ECC. It just didn't even cross my mind when we wrote
> the code in question. Had much bigger fish to fry at the time,
> like do we need to recall all the devices in the field...
I quite understand! Fortunately for us, there's no reason
to recall any of our devices, since they are reference
boards that come with the full source, which can be updated
from our GIT servers. Hence, the users/developers can do
what they like. What it does mean is I have to be a bit
careful not to break the existing (“legacy”) situation!
cheers!
-blf-
--
Brian Foster
Principal MTS, Software | La Ciotat, France
Maxim Integrated | http://www.maximintegrated.com/
prev parent reply other threads:[~2013-07-04 13:07 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
[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 [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=2596872.0DU6ch1YoB@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