public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Iwo Mergler <iwo@call-direct.com.au>
To: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: Scott Wood <scottwood@freescale.com>,
	linux-mtd@lists.infradead.org,
	David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH] MTD: NAND: fsl_elbc_nand: fix OOB workability for large page NAND chips
Date: Fri, 27 Jun 2008 16:19:14 +1000	[thread overview]
Message-ID: <48648662.1050107@call-direct.com.au> (raw)
In-Reply-To: <20080626184156.GA2356@polina.dev.rtsoft.ru>

Anton Vorontsov wrote:
> 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.
>
>   
Anton,

the problem with bad block markers is that if they are set, _nothing_ is 
guaranteed
to work with that block. You cannot assume that it is possible to 
relocate the BB
marker into the first byte, if the second one is set. If you don't 
relocate it, your
new pattern will fail to find the bad block.

Most manufacturers use the first OOB byte in one of the first two pages 
in a block
as the BB marker. Others use, as you noticed, the first two OOB bytes of 
the first and
possibly second page of a block.

The point is that if  the marker is set, nothing can be done with that 
block. You must
not touch it.

To make things worse, some hardware NAND controllers *require* you to place
the ECC immediately after the data area. That's right, straight over the 
BB marker
locations.

The solution to your and other similar problems is to use a Bad Block 
Table (BBT)
at the end of the NAND. When your device comes up for the first time, it 
must
scan the NAND for bad blocks, and then write this information into the BBT.

In all consecutive boots, the device must always use the BBT and not 
scan again.

The algorithm, as implemented e.g. in U-Boot and the Linux kernel is to look
for a valid BBT first and only go scanning if it doesn't exist. After 
the scan,
the BBT is written and available next time.

You just need to set the correct flags in your low-level NAND driver.

Kind regards,

Iwo

  parent reply	other threads:[~2008-06-27  6:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-26 18:41 [PATCH] MTD: NAND: fsl_elbc_nand: fix OOB workability for large page NAND chips Anton Vorontsov
2008-06-26 18:59 ` 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 [this message]
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=48648662.1050107@call-direct.com.au \
    --to=iwo@call-direct.com.au \
    --cc=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