mtd nand erase and bad block

[Angus CLARK]

I have to do this regularly for testing new NAND drivers.  After getting fed up
with doing temporary hacks all the time, I ended up adding a
'nand_erasebadblock' entry to debugfs, which overrides the check in
nand_erase_nand():
...
	if (!nand_erasebadblock &&
	    nand_block_checkbad(mtd, ((loff_t) page) <<
				chip->page_shift, 0, allowbbt)) {
...

The sequence in userspace would then be something like:

	target% echo 1 > /sys/kernel/debug/nand_erasebadblock
	target% flash_erase -N /dev/mtd6 0x00200000 1
	target% echo 0 > /sys/kernel/debug/nand_erasebadblock

You need to be careful to only erase marked bad blocks that you know are
actually good, or else you risk loosing the factory-programmed bad block markers.

This method is also useful for erasing the BBTs, which will then force the
driver to re-scan for OOB markers on the next boot.  Again care needs to be
taken, as you may loose information about blocks that have gone bad through
wear.  (The recent patch "mtd: nand: write BBM to OOB even with flash-based BBT"
partly overcomes this issue.)

Typically, debugfs is only enabled in development environments, and even then it
requires explicit user action, so this method of enabling erasing bad blocks is
safe enough for our needs.

Happy to do a patch if others are interested...

Cheers,

Angus

On 06/01/2012 07:37 AM, Ricard Wanderlof wrote:
> 
> On Fri, 1 Jun 2012, Adrian Hunter wrote:
> 
>>> What's the way for recheck bad blocks and refresh the BBT from userspace
>>> application?
>>
>> I always just temporarily hack the kernel driver to allow the erase of
>> the
>> bad block in question.
> 
> I agree. Having that capability available at all times would be scary.
> 
> /Ricard