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.thebaud...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot