From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?= <benoit.thebaudeau@advansee.com>
Date: Tue, 16 Apr 2013 01:16:44 +0200 (CEST)
Subject: [U-Boot] i.MX3 NAND: trying to understand OOB handling
In-Reply-To: <20130415224943.GF27612@twoflower.paeps.cx>
References: <20130415205006.GE27612@twoflower.paeps.cx>
	<1315354495.1766570.1366063096849.JavaMail.root@advansee.com>
	<20130415224943.GF27612@twoflower.paeps.cx>
Message-ID: <1735117181.1766898.1366067804859.JavaMail.root@advansee.com>
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

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