Hello, I work to maintain an OMAP3 system with the standard POP NAND/RAM package as is used on the EVMs. It works ok in general, but we've had a series of NAND corruption issues that have prompted digging into the driver stack to convince ourselves that we're as robust as we can be. One big unknown we haven't been able to get our arms around yet is the bad block table(BBT). A few questions: 1. In drivers/mtd/nand/omap2.c the BBT scanning seems to be disabled completely(NAND_SKIP_BBTSCAN). Is the BBT always empty because of this, or will it get filled in at a later point? -- Does anyone know the origin of this line? It seems to have been there since the creation of the omap2 nand driver at least 2. In ubinfo output I see that it believes there are no bad physical erase blocks. Running the nandtest command confirms this on several boards. Is this normal? Has anyone observed a bad physical erase block on their NANDs with this configuration? 3. Where would be a good place to get an overview of how the BBT handling is done on the OMAP3 kernels? Is there a wiki page or past discussion on this mailing list that might explain the decisions made and expected behavior of the drivers? Thanks, David -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
