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

[Benoît Thébaudeau]

Hi Philip,

On Monday, April 15, 2013 10:50:06 PM, Philip Paeps wrote:
> I am in the process of upgrading a customer's i.MX35-based design to
> state-of-the-art U-Boot.  The board previously booted from NAND using a
> home-grown SPL.  Since I'm doing some heavy-lifting anyway, I decided to
> try out Benoît's patches and use U-Boot's SPL bits and they work well
> for me (thanks, Benoît!).
> 
> My NAND has 4K pages and speaks ONFI, though I now also have 2K NANDs to
> test with.  I managed to hack mxc_nand.c and mxc_nand_spl.c to the point
> that I can now boot successfully from 2K and 4K ONFI NANDs.  I'd like to
> clean up my changes and contribute them.
> 
> That was the good news. :-)
> 
> 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.
> 
> Using a (mostly) unmodified driver, none of the virgin chips I've looked
> at have any factory bad blocks on them.  I find that hard to believe.
> 
> My NANDs have factory bad block markers in the first spare byte of the
> first or the second page of every bad block.  The "or" in the previous
> sentence suggests to me that I want to set NAND_BBT_SCAN2NDPAGE in
> bbt_{main,mirror}_descr.options.  I probably want to make that bit
> conditional on a board option.
> 
> The i.MX35 reference manual tells me that 2K and 4K NANDs are read 512
> bytes at a time, so that the layout in SRAM will be:
> 
>  | 512 + 16 | 512 + 16 | 512 + 16 | 512 + 16 |
>  |<------------------ 2112 ----------------->|
> 
> or
> 
>  | 512 + 26 | 512 + 26  |  [...]  | 512 + 36 |
>  |<------------------ 4314 ----------------->|
> 
> (the extra spare bytes are appended to the last section)
> 
> That would put the factory bad block marker somewhere in the data
> section, but depending on how you interpret the datasheet, it could be
> at a number of different offsets.  Patches posted to various mailing
> lists suggest that 0x7D0 is a popular assumption, but I've not managed
> to encounter a convincing reasoning for that offset over any of the
> other options.
> 
> To confuse matters further, send_{prog,read}_page() in mxc_nand.c does a
> little dance to allegedly make the spare data contiguous.  Is this
> really spare data in the case of 2K or 4K pages though?  Or is that code
> actually corrupting data?  Given that Linux does the same dance, and
> that it's doing the same dance both reading and programming, it "works",
> but that code makes me a little uneasy.  I feel quite strongly that the
> bytes we access through a pointer named "spare" are actually OOB bytes
> and not secretly in the data area.
> 
> Further down in mxc_nand.c, mxc_nand_read_oob_syndrome() also interprets
> the layout of the SRAM buffer, apparently so that it can get the "real"
> ECC data.
> 
> 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.

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).

With the 2-kiB-paged NANDs that I use, I get some bad blocks detected with the
current code, but not for all parts.

Some light changes are required in the current OOB layout as explained in the
threads above, for both U-Boot and Linux. And those should be synchronized. But
then, there is Freescale's app note above that seems to contradict a few things.

This cleanup is also on my long TODO list, but with a low priority, so if you
come up with a solution, that's perfect.

I hope that helps.

Best regards,
Benoît