public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] NAND flash - bad blocks
Date: Fri, 11 Jan 2013 14:21:33 -0600	[thread overview]
Message-ID: <1357935693.5475.11@snotra> (raw)
In-Reply-To: <002401cdefd8$18f3aed0$2901a8c0@dpn> (from dpn@switchfin.org on Fri Jan 11 02:46:06 2013)

On 01/11/2013 02:46:06 AM, Dimitar Penev wrote:
> Hi Scott,
> 
>> On 01/10/2013 01:56:30 AM, Dimitar Penev wrote:
>>> Hello,
>>> 
>>> First of all sorry if this question was already answered here.
>>> 
>>> We are sourcing some K9F8G08U0M-PIB0 NAND flash devices.
>>> On the first erase in uboot 2011.09 I got bunch of mostly  
>>> consecutive bad blocks.
>>> According to the datasheet we should get not more then 80 bad  
>>> blocks  for our chip
>>> but I get something like 240 bad blocks for most of the NAND chips.
>>> 
>>> I seems to be able to fix this using the following procedure:
>> 
>> Call your NAND vendor and complain?
>> 
> 
> Well we did but we didn't got something from them which could explain  
> what we observe.
> 
>> After making sure that there's nothing wrong with your NAND driver  
>> or controller that causes the OOB to be read incorrectly.
> 
> We are using nand_plat driver provide by ADI without any  
> customization.

Still, do some investigation to see whether it seems to be working.   
Dump the raw data that you read -- is it mostly 0xff with some bad  
block markers set, or is it returning garbage?  Do any of the blocks  
that are not marked bad have non-0xff data?  If you do a scrub of the  
entire NAND chip, then write to one block, does the write show up  
anywhere else on the NAND chip?

>>> In uboot
>>> uboot>nand scrub.chip
>>> 
>>> In uboot
>>> uboot>nand erase.chip clean
>>> at this point I get usually 1,2 bad blocks which looks normal to me.
>> 
>> You're not fixing anything -- you're wiping out all bad block   
>> information. Those "1,2 bad blocks" are not actually bad blocks,  
>> but  are the bad block table which appears "bad" to reserve it.   
>> These  should be at the end of flash.  Or, possibly, they're blocks  
>> that  happen to be damaged in a way that prevents the bad block  
>> marker from  becoming 0xff.
> 
> Oh Really?
> What about 'nandtest -m' in Linux ? I was hoping it does a check of  
> the erase blocks.

That's no substitute for having the factory bad block markers.   
Nandtest doesn't look very rigorous at all -- and only seems to mark  
bad blocks if the erase or write operations return failure, not if it  
sees an uncorrectable error on readback.

> Thanks Scott.
> Is there any procedure to analyze the nand flash for bad blocks?

Yes, and it's done by the flash manufacturer to produce bad block  
markers. :-P

-Scott

  reply	other threads:[~2013-01-11 20:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-10  7:56 [U-Boot] NAND flash - bad blocks Dimitar Penev
2013-01-10 19:19 ` Scott Wood
2013-01-11  8:46   ` Dimitar Penev
2013-01-11 20:21     ` Scott Wood [this message]
2013-01-15 11:09       ` Dimitar Penev
2013-01-15 17:33         ` 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=1357935693.5475.11@snotra \
    --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