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.
(text/plain)