Ross Younger wrote:
> Yeasah Pell wrote:
>> > Bad blocks are actually managed at the MTD level, not the filesystem;
>> > the exact method used to store the bad block table varies depending on
>> > the exact NAND configuration, but often the NAND pages themselves have a
>> > marker in the header which indicates "badness".
>>     
>
> Every chip has its own concept of factory-bad block markers. Many (most?)
> chip spec sheets then recommend that the driver reads this information and
> uses it to populate a Bad Block Table on the device. You can find the code
> which does this in a recent kernel source tree, in
> drivers/mtd/nand/nand_bbt.c. (Take care - there's a general implementation,
> which some chips deviate from. You might want to read its chip detection
> logic too.)
>
> If your chip has a BBT, then you're probably better off erasing just the
> blocks comprising that table than you are erasing the device completely.
> (That may yet require hacking the driver.) The net result would be to forget
> all the blocks that the driver believes have gone bad in use - which I've
> found can happen during development if you mess up your drivers.
>
>
> Ross
>   

It's an excellent point, some drivers do enable an on-flash BBT. This 
isn't determined by the NAND chip in use though, it's determined by the 
NAND *controller* in use. The option which enables this 
(NAND_USE_FLASH_BBT) is easily grepped for and gives the following list 
of drivers:

autcpu12: SmartMediaCard on autronix autcpu12 board
cs553x_nand: NAND support for CS5535/CS5536 (AMD Geode companion chip)
cafe_nand: NAND support for OLPC CAFÉ chip
diskonchip: DiskOnChip 2000, Millennium and Millennium Plus (NAND 
reimplementation) (EXPERIMENTAL)
fsl_elbc_nand: NAND support for Freescale eLBC controllers
rtc_from4: Renesas Flash ROM 4-slot interface board (FROM_BOARD4)
nand_pasemi: NAND support for PA Semi PWRficient

I'm not sure how many of those controllers are widely used (the OLPC one 
must see significant use at least), but I've never used any of these 
controllers myself. But if you do use one of these controllers, it would 
indeed be best to just try to erase the on-flash table. Of course MTD 
protects these blocks from conventional erasure too (otherwise 
flash_eraseall would clear the bbt), so you'd have to disable that 
protection. Temporarily changing the third parameter of the call to 
nand_erase_nand in nand_base.c to 1 seems like it would trivially 
accomplish this. As long as the bbt isn't rewritten from memory before 
you can reboot, I think that should work fine.

One other thing that occurred to me the first time I encountered this 
(this is specific to drivers which do not use an on-chip bad block 
table) is that there is probably some forensically identifiable 
difference between the OOB in a factory marked bad block versus the OOB 
in a MTD marked bad block, especially for chips where the marker 
specification diverges somewhat from the MTD code (which seems to be 
most of them). I never pursued this very far, as I always had a log of 
the original factory bad block list that I could manually restore from.

-y