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


On Wed, 2007-09-26 at 16:10 +0200, Frank Haverkamp wrote:
> 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>

Acked-by: Thomas Gleixner <tglx@linutronix.de>

> ---
>  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);
> 

      reply	other threads:[~2007-09-26 15:11 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-26 14:10 [PATCH] MTD: NAND: Fix bad-block detection for 8-bit NAND Frank Haverkamp
2007-09-26 15:10 ` Thomas Gleixner [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=1190819426.23376.26.camel@chaos \
    --to=tglx@linutronix.de \
    --cc=dwmw2@infradead.org \
    --cc=haver@vnet.ibm.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 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.