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);
>
prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox