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. > 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. 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. > 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. While cleanup for the sake of cleanup isn't very high on my list, reliable operation in the face of bad blocks is near the top. Since it's easier to express confidence in clean code, I might as well clean things up. :-) > I hope that helps. It does. Thank you! - Philip -- Philip Paeps Senior Reality Engineer Ministry of Information _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
