From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Fri, 11 Jan 2013 14:21:33 -0600 Subject: [U-Boot] NAND flash - bad blocks In-Reply-To: <002401cdefd8$18f3aed0$2901a8c0@dpn> (from dpn@switchfin.org on Fri Jan 11 02:46:06 2013) Message-ID: <1357935693.5475.11@snotra> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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