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