Yeasah Pell wrote:
> Bill Gatliff <bgat@billgatliff.com> wrote:
>>
>> Guys:
>>
>>
>> For some reason, I have ended up with a NAND flash that's marked about 
>> 98% "bad".  Is there a way to clear the bits that tell yaffs2 that a 
>> block is bad?
>>
>> I did ask Google first, honest.  :)
>>
>>
>> b.g.
>>
>>   
> 
> Hi, Bill.
> 
> Here's my understanding of this situation, which I have encountered a 
> couple times in the past.
> 
> 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". Unfortunately it is 
> difficult to unmark blocks from Linux; normally MTD will not allow the 
> erasure of a bad block, which is what you would need to do in order to 
> restore it. It isn't usually difficult to hack up the MTD drivers to 
> allow this and then just doing a flash_eraseall on the device will 
> restore it to a usable state. It cannot be done from userspace alone 
> unless the particular NAND driver that you are using allows this (I know 
> of at least one NAND driver that has an optional parameter to disable 
> the bad block table at boot time)
> 
> Preferably, if you use u-boot as a bootloader, there is a "nand scrub" 
> command that will do something similar, without the need to make 
> temporary modifications to the kernel.
> 
> HOWEVER!
> 
> There is a reason that MTD does not normally allow the erasure of blocks 
> marked as bad. Some of the blocks on your device that are marked as bad 
> were likely factory marked blocks, and re-erasing all the blocks will 
> cause these blocks to become marked good (along with every other block). 
> It is true that blocks that fail during the erase will be re-marked as 
> bad, but this will not account for 100% of the factory marked blocks 
> 100% of the time, because the procedures used to mark blocks bad at the 
> factory are generally much more sensitive, involving analysis that is 
> not available during normal usage of the chip.
> 
> Basically the situation is that you may end up with marginal blocks that 
> are expected to fail at some point that end up being used for data 
> storage, and data corruption is thus statistically more likely on this 
> device after the scrub. Of course it's still better than a device with 
> all its blocks marked bad, which is completely unusable. And it's not a 
> guarantee that reliability will be impacted at all -- I've seen NAND 
> devices that come with zero factory bad blocks for example, and it's 
> also possible that all the factory marked blocks are faulty enough that 
> they will be properly re-marked during the erase/scrub. But unless you 
> have a log of the original list of bad blocks somewhere (maybe an old 
> boot log showing the bad block list for example), you'll never be able 
> to know for sure.
> 
> -Yeasah
> 
> 

Thanks for that very clear and comprehensive overview of the subject.

I wasted a large amount of time a month ago looking into this and did 
not get as much understanding at your post provides.

Thanks very much.