From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Date: Tue, 19 Mar 2013 18:23:27 -0500
Subject: [U-Boot] freescale i.MX28 mxsboot NAND booting on mx28evk bad
 blocks
In-Reply-To: <5147B63F.4020407@acm.org> (from henson@acm.org on Mon Mar 18
	19:50:07 2013)
References: <5147B63F.4020407@acm.org>
Message-ID: <1363735407.16671.36@snotra>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On 03/18/2013 07:50:07 PM, Paul B. Henson wrote:
> I'm prototyping a project that's going to need to boot linux from  
> NAND on a mx28evk board.
> 
> I was able to successfully use the u-boot mxsboot utility to generate  
> a nand image and burn it, then boot from it. I noticed one anomaly  
> though, when using mxsboot/u-boot to generate and burn the bootstream  
> to NAND, when the linux kernel boots it finds bad blocks:
> 
> [    1.090000] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xf1  
> (Micron MT29F14
> [    1.100000] Scanning device for bad blocks
> [    1.110000] Bad eraseblock 0 at 0x000000000000
> [    1.110000] Bad eraseblock 1 at 0x000000020000
> [    1.120000] Bad eraseblock 2 at 0x000000040000
> [    1.120000] Bad eraseblock 3 at 0x000000060000
> 
> When I burn the exact same bootstream with kobs-ng, linux does not  
> find any bad blocks, so it seems to be a byproduct of either the  
> image generated by mxsboot or the u-boot burning.
> 
> I don't think this is having any functional impact, as the scrub  
> component of burning a new nand image wipes out the bad blocks,

You should not be routinely scrubbing NAND!

The manufacturers put bad block information there for a reason.

-Scott