From: "Lothar Waßmann" <LW@KARO-electronics.de>
To: Ricard Wanderlof <ricard.wanderlof@axis.com>
Cc: Huang Shijie <b32955@freescale.com>,
Wolfram Sang <w.sang@pengutronix.de>,
"marek.vasut@gmail.com" <marek.vasut@gmail.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"Bityutskiy, Artem" <artem.bityutskiy@intel.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v3] mtd/gpmi : add BBT support to gpmi nand driver
Date: Thu, 2 Feb 2012 15:43:28 +0100 [thread overview]
Message-ID: <20266.41232.670348.59659@ipc1.ka-ro> (raw)
In-Reply-To: <Pine.LNX.4.64.1202021441330.554@lnxricardw.se.axis.com>
Hi,
Ricard Wanderlof writes:
>
> On Thu, 2 Feb 2012, Lothar Waßmann wrote:
>
> > Hi,
>
> > IMO it's just silly trying to write anything, even a bad block marker,to
> > a known bad block in NAND flash.
> >
> > The bad block markers in particular bytes in the OOB area are providedby
> > the manufacturer to identify "Factory Bad Blocks". That and no more! I
> > don't know why everybody is trying to interpret them as a general bad
> > block indicator.
>
> Why not? It's just another byte within the block.
>
But on a block that is known to have failed erasure or programming you
cannot rely on being able to program anything reliably. Thus it is
vain to try storing the info that the block is bad within that block
itself.
> The Flash chip reports an error on a write or erase operation if the
> operation does not complete successfully within certain time constraints,
> which are grounds for marking a block as unusable, i.e. bad, but usually
> the block is worn out long before the on-chip write/erase algorithms
> report errors. Hence a block should really be marked 'bad' while it still
> is 'good', in a sense.
>
How do you know that a worn out block will still retain the 'This
block is bad' information?
Lothar Waßmann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info@karo-electronics.de
___________________________________________________________
prev parent reply other threads:[~2012-02-02 14:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-31 11:11 [PATCH v3] mtd/gpmi : add BBT support to gpmi nand driver Huang Shijie
2012-01-31 11:34 ` Marek Vasut
2012-01-31 12:10 ` Wolfram Sang
2012-02-02 11:51 ` Bityutskiy, Artem
2012-02-02 13:29 ` Lothar Waßmann
2012-02-02 14:01 ` Ricard Wanderlof
2012-02-02 14:43 ` Lothar Waßmann [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=20266.41232.670348.59659@ipc1.ka-ro \
--to=lw@karo-electronics.de \
--cc=artem.bityutskiy@intel.com \
--cc=b32955@freescale.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=ricard.wanderlof@axis.com \
--cc=w.sang@pengutronix.de \
/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