On Fri, Jun 17, 2011 at 5:34 PM, Scott Wood <scottw...@freescale.com> wrote: > > As for the corruption, could it be degradation from repeated reads of that > one page? >
Could be. I think Mike's theory was that the -1 page_addr sort of "wrapped around", and caused us to read in the last block on flash each time NAND_CMD_PAGEPROG was performed. So with a lot of writes happening, we could end up with a BBT that looks like this. That makes sense I guess, since set_addr() in fsl_elbc_nand.c uses page_addr to set FBAR. I don't see anything about it in the manual, but if FBAR wraps beyond the end of the chip, maybe the bits that don't make sense are simply ignored. (In which case we should probably add a check in set_addr() to prevent anything like this in the future) In theory I should be able to prove it out by running 2 devices in parallel - one with that block of code still there, and one with it removed. If the former device sees bit-flips in the BBT and the latter one doesn't, we'll be sure of the culprit. I'll try this and come back with the results. Thanks! -- Matthew L. Creech _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
