All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank Haverkamp <haver@vnet.ibm.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: David Woodhouse <dwmw2@infradead.org>,
	haver@vnet.ibm.com,
	MTD Mailinglist <linux-mtd@lists.infradead.org>
Subject: [PATCH] MTD: NAND: Fix bad-block detection for 8-bit NAND
Date: Wed, 26 Sep 2007 16:10:23 +0200	[thread overview]
Message-ID: <1190815823.21594.30.camel@august> (raw)

[-- Attachment #1: Type: text/plain, Size: 2187 bytes --]

Hi Thomas,

I found the following block in our 128MiB NAND flash:

hexdump vic.img.460 
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0000800 00ff 0000 0000 0000 0000 0000 0000 0000
0000810 0000 0000 0000 0000 0000 0000 0000 0000
*
0001040 00ff 0000 0000 0000 0000 0000 0000 0000
0001050 0000 0000 0000 0000 0000 0000 0000 0000
*
0021000

According to the specification this is a good block, because the bytes
in the 1st two OOB areas at offset 0 are 0xff. Nevertheless it was
detected bad because:

static struct nand_bbt_descr largepage_memorybased = {
	.options = 0,
	.offs = 0,
	.len = 2,                    /* <<<< bytes to check!!! */
	.pattern = scan_ff_pattern
};

used a len of 2 instead of 1, which I consider to be correct. Here a
potential fix for the problem. Please have a look if it matches your
understanding of the specification.

Signed-off-by: Frank Haverkamp <haver@vnet.ibm.com>
---
 drivers/mtd/nand/nand_bbt.c |   20 +++++++++++++++++---
 1 file changed, 17 insertions(+), 3 deletions(-)

--- ubi-2.6.git.orig/drivers/mtd/nand/nand_bbt.c
+++ ubi-2.6.git/drivers/mtd/nand/nand_bbt.c
@@ -1081,7 +1081,14 @@ static struct nand_bbt_descr smallpage_m
 	.pattern = scan_ff_pattern
 };
 
-static struct nand_bbt_descr largepage_memorybased = {
+static struct nand_bbt_descr largepage_memorybased_8bit = {
+	.options = 0,
+	.offs = 0,
+	.len = 1,
+	.pattern = scan_ff_pattern
+};
+
+static struct nand_bbt_descr largepage_memorybased_16bit = {
 	.options = 0,
 	.offs = 0,
 	.len = 2,
@@ -1179,8 +1186,15 @@ int nand_default_bbt(struct mtd_info *mt
 		this->bbt_td = NULL;
 		this->bbt_md = NULL;
 		if (!this->badblock_pattern) {
-			this->badblock_pattern = (mtd->writesize > 512) ?
-			    &largepage_memorybased : &smallpage_memorybased;
+			if (mtd->writesize > 512) {
+				if (this->options & NAND_BUSWIDTH_16)
+					this->badblock_pattern =
+						&largepage_memorybased_16bit;
+				else
+					this->badblock_pattern =
+					       &largepage_memorybased_8bit;
+			} else
+				this->badblock_pattern = &smallpage_memorybased;
 		}
 	}
 	return nand_scan_bbt(mtd, this->badblock_pattern);


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5269 bytes --]

             reply	other threads:[~2007-09-26 14:10 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-26 14:10 Frank Haverkamp [this message]
2007-09-26 15:10 ` [PATCH] MTD: NAND: Fix bad-block detection for 8-bit NAND Thomas Gleixner

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=1190815823.21594.30.camel@august \
    --to=haver@vnet.ibm.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=tglx@linutronix.de \
    /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.