public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
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/

      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