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
--
Embedded Software Engineer, eCosCentric Limited.
Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK.
Registered in England no. 4422071. www.ecoscentric.com
(text/plain)