mtd nand erase and bad block

[Artem Bityutskiy]

On Fri, 2012-06-01 at 09:29 +0100, Angus CLARK wrote:
> 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.

Sounds ok to me, especially if you send the patch together with a piece
of doc for the mtd web-site. I just think it is important to document
this feature. Is this doable?

-- 
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20120601/5c16dc4f/attachment.sig>