public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Scott Wood <scottwood@freescale.com>, linux-mtd@lists.infradead.org
Subject: [PATCH] MTD: NAND: fsl_elbc_nand: fix OOB workability for large page NAND chips
Date: Thu, 26 Jun 2008 22:41:56 +0400	[thread overview]
Message-ID: <20080626184156.GA2356@polina.dev.rtsoft.ru> (raw)

For large page chips, nand_bbt is looking into OOB area, and checking
for "0xff 0xff" pattern at OOB offset 0. That is, two bytes should be
reserved for bbt means.

But ELBC driver is specifying ecclayout so that oobfree area starts at
offset 1, so only one byte left for the bbt purposes.

This causes problems with any OOB users, namely JFFS2: after first mount
JFFS2 will fill all OOBs with "erased marker", so OOBs will contain:

  OOB Data: ff 19 85 20 03 00 ff ff ff 00 00 08 ff ff ff ff
  OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
  OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

And on the next boot, NAND core will rescan for bad blocks, then will
see "0xff 0x19" pattern, and will mark all blocks as bad ones.

To fix the issue we should implement our own bad block pattern: just one
byte at OOB start.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---

The patch that fixes oobfree will follow, but you have to choice which
you'll want to apply (if any), not both.

 drivers/mtd/nand/fsl_elbc_nand.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 1b06d29..69609cc 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -116,6 +116,20 @@ static struct nand_ecclayout fsl_elbc_oob_lp_eccm1 = {
 	.oobavail = 48,
 };
 
+/*
+ * fsl_elbc_oob_lp_eccm* specify for LP NANDs that OOB starts at offset 1, so
+ * we have to adjust bad block pattern (this is for compatiblitywith already
+ * reflashed devices, otherwise we could fix ecclayout.oobfree instead).
+ */
+static u8 scan_ff_pattern[] = { 0xff, };
+
+static struct nand_bbt_descr largepage_memorybased = {
+	.options = 0,
+	.offs = 0,
+	.len = 1,
+	.pattern = scan_ff_pattern,
+};
+
 /*=================================*/
 
 /*
@@ -687,6 +701,7 @@ static int fsl_elbc_chip_init_tail(struct mtd_info *mtd)
 			chip->ecc.layout = (priv->fmr & FMR_ECCM) ?
 			                   &fsl_elbc_oob_lp_eccm1 :
 			                   &fsl_elbc_oob_lp_eccm0;
+			chip->badblock_pattern = &largepage_memorybased;
 			mtd->ecclayout = chip->ecc.layout;
 			mtd->oobavail = chip->ecc.layout->oobavail;
 		}
-- 
1.5.5.4

             reply	other threads:[~2008-06-26 18:41 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-26 18:41 Anton Vorontsov [this message]
2008-06-26 18:59 ` [PATCH] MTD: NAND: fsl_elbc_nand: fix OOB workability for large page NAND chips Scott Wood
2008-06-26 23:06   ` Anton Vorontsov
2008-06-27 14:43     ` Scott Wood
2008-06-27 15:04       ` Anton Vorontsov
2008-06-27  6:19 ` Iwo Mergler
2008-06-27 14:55   ` [PATCH] MTD: NAND: fsl_elbc_nand: implement support for flash-based BBT Anton Vorontsov
2008-06-27 15:30     ` Scott Wood
2008-06-27 16:00       ` Anton Vorontsov
2008-06-27 16:29         ` Scott Wood
2008-06-27 19:02           ` Anton Vorontsov
2008-06-27 19:04             ` [PATCH 1/3] MTD: NAND: fsl_elbc_nand: fix OOB workability for large page NAND chips Anton Vorontsov
2008-06-27 19:04             ` [PATCH 2/3] MTD: NAND: fsl_elbc_nand: implement support for flash-based BBT Anton Vorontsov
2008-06-27 19:04             ` [PATCH 3/3] MTD: NAND: fsl_elbc_nand: ecclayout cleanups Anton Vorontsov
2008-06-30 21:09               ` Scott Wood

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=20080626184156.GA2356@polina.dev.rtsoft.ru \
    --to=avorontsov@ru.mvista.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=scottwood@freescale.com \
    /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