[U-Boot] i.MX3 NAND: trying to understand OOB handling

["Benoît Thébaudeau" <benoit.thebaudeau@advansee.com>]

Hi Philip,

On Tuesday, April 16, 2013 12:49:44 AM, Philip Paeps
> Subject: Re: [U-Boot] i.MX3 NAND: trying to understand OOB handling
> 
> On 2013-04-15 23:58:16 (+0200), Beno?t Th?baudeau
> <benoit.thebaudeau@advansee.com> wrote:
> > On Monday, April 15, 2013 10:50:06 PM, Philip Paeps wrote:
> > > Unfortunately, the more I look at the code (and the Linux code, and
> > > patches on mailing lists and the datasheet), the more confused I'm
> > > getting about the OOB handling.  In particular: where does the NFC
> > > hide the factory bad block markers.
> > >
> > > [...]
> > > 
> > > Bolting on code to make 4K pages work doesn't make this any prettier, so
> > > I'd like to take the opportunity to refactor this a bit.  Before I hack
> > > myself into a corner though, I'd like to make sure that I understand the
> > > mapping between the SRAM buffer and the actual NAND correctly.
> > > 
> > > I'd be grateful if others who have looked at this code could share their
> > > understanding.
> > 
> > Wow, that's many questions.
> 
> Sorry for the braindump. :-)
> 
> > You might want to have a look at the following threads:
> > http://lists.denx.de/pipermail/u-boot/2012-November/140506.html
> > http://archive.arm.linux.org.uk/lurker/message/20121121.092540.b9b858ad.en.html
> > 
> > There is also an app note by Freescale about NAND Flash bad block handling
> > in
> > their Linux doc bundle (also confusing).
> 
> Thanks for the pointers.  I mentally skipped over i.MX5-related
> discussions when I was digging, but now you mention it, I realise
> there's probably a lot more recent context about the mxc_nand driver in
> those than in the i.MX3-related discussions I've been staring at.

Yes, these OOB topics are not i.MX5-specific.

> > With the 2-kiB-paged NANDs that I use, I get some bad blocks detected with
> > the
> > current code, but not for all parts.
> 
> I've only tested with about five of each 2K and 4K NANDs.  That's
> certainly not a statistically significant number, but I would have at
> least expected a couple of factory bad blocks, especially in the larger
> 4K MLC parts.

It's lottery. ;)

> Another thing I've not tried, is marking some blocks as bad and then
> scanning for bad blocks to see what it finds.  For that experiment to be
> meaningful though, I'd want to be sure the code that marks the blocks as
> bad does the right thing.

For what you want to test, you need to undefine CONFIG_SYS_NAND_USE_FLASH_BBT.
Otherwise, the BBT is updated with the bad block information instead of the bad
lock itself.

Best regards,
Beno?t