All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@bootlin.com>
To: Schrempf Frieder <frieder.schrempf@kontron.de>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Miquel Raynal <miquel.raynal@bootlin.com>
Subject: Re: Raw NAND bad block marker positions
Date: Wed, 12 Dec 2018 11:36:49 +0100	[thread overview]
Message-ID: <20181212113649.3202f758@bbrezillon> (raw)
In-Reply-To: <e937e18d-5099-5969-3b17-1f2d9ffa3a44@kontron.de>

On Wed, 12 Dec 2018 10:32:04 +0000
Schrempf Frieder <frieder.schrempf@kontron.de> wrote:

> Hi,
> 
> the current implementation for checking/setting the bad block markers in 
> raw NAND flash devices supports three setups for the position of the 
> markers within the bad block:
> 
> * BBM in first page only
> * BBM in last page only
> * BBM in first or second page
> 
> This is controlled by the flags NAND_BBT_SCANLASTPAGE and 
> NAND_BBT_SCAN2NDPAGE. It is not supported to set both flags to check 
> first, second and last page.
> 
> Though some devices seem to require this kind of setup. We know of some 
> ESMT SLC NANDs, that were accidentally shipped with BBM in the first or 
> last page, instead of first or second page as claimed in the datasheet.
> 
> Also the documents for Cypress/Spansion/AMD NANDs claim that the 
> software needs to check first, second and last page for BBMs (e.g. [1]).
> 
> It doesn't look like it would be difficult to make NAND_BBT_SCANLASTPAGE 
> and NAND_BBT_SCAN2NDPAGE work together, but I wanted to ask if someone 
> already stumbled upon this problem or if someone has any comments or 
> suggestions, before trying to patch this?

Your suggestion sounds reasonable.

  reply	other threads:[~2018-12-12 10:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-12 10:32 Raw NAND bad block marker positions Schrempf Frieder
2018-12-12 10:36 ` Boris Brezillon [this message]
2018-12-12 10:38 ` Miquel Raynal

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=20181212113649.3202f758@bbrezillon \
    --to=boris.brezillon@bootlin.com \
    --cc=frieder.schrempf@kontron.de \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.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 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.