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
next prev parent 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