From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] NAND Bad Blocks and OOB
Date: Fri, 18 Mar 2011 14:25:41 -0500 [thread overview]
Message-ID: <20110318142541.44f35f71@schlenkerla> (raw)
In-Reply-To: <1988045005.3710687.1300448586258.JavaMail.fmail@mwmweb008>
On Fri, 18 Mar 2011 12:43:06 +0100
<VirtualFight@web.de> wrote:
>
> Hi all,
> I have some questions about the bad block management in the NAND-driver, I hope this is the right place to ask this:
>
> The things I believe to know, please correct me, if its wrong:
> If
> I have a new NAND-Flash, the manufacturer marked the bad block in the
> spare area/OOB (normaly good blocks are marked as 0xFF in the first 2
> bytes?).
> The u-boot scans for these bad blocks and saves the information in the bbt.
>
> What
> happens, if a block gets worn out? Would this block only be markes as
> bad in the bbt, or would this information would be also stored in the
> spare area (the driver write another value, not 0xFF in the firts 2
> bytes?).
As long as you have an in-flash bbt, it only gets marked in the bbt. If you
don't have an in-flash bbt, an OOB bad block marker is written.
> Is it possible to restore the bad block informations, if the
> whole nand-flash would be erased (for example by writing 0 in all block
> and after this by erasing the blocks and check the error status bit of
> the NAND-flash device)?
It's possible to do your own testing and mark blocks bad as a result, but
you're not really restoring the original information. The manufacturer may
have used a more rigorous test.
> If yes, is such a function implemented in u-boot?
No. You should avoid clearing manufacturer-set bad block markers.
-Scott
prev parent reply other threads:[~2011-03-18 19:25 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-18 11:43 [U-Boot] NAND Bad Blocks and OOB VirtualFight at web.de
2011-03-18 19:25 ` Scott Wood [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=20110318142541.44f35f71@schlenkerla \
--to=scottwood@freescale.com \
--cc=u-boot@lists.denx.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