Re: MTD utils v1.5.0: MEMERASE64 ioctl failed error

[Mike Dunn <mikedunn@newsguy.com>]

On 10/15/2013 01:32 AM, Shah, Minal wrote:
> Hi Brian,
> Thanks a lot for the explanation; I understood the reason for failure.
> 
>> So why do you want to erase bad blocks?
> The reason why I want to erase bad blocks is because they actually don't seem to be bad. 
> Block0 itself is shown as bad.
> I have few partitions (like MLO and u-boot env) of size equal to 1 erase block. The block is marked as bad and hence I cannot write anything to this partition. 
> One of the solutions is to increase that partition size to 2 blocks so even if 1 block is bad then it will atleast be able to write to the other block of the same partition. But I don't think I should do this while the block is not really bad (what if all the blocks for some reason are marked as bad while they are actually not).
> 
> This question came in my mind from the fact that "nand scrub" command is allowed from u-boot which allows to also completely erase all the bad blocks; so why not from the kernel level.
> 
> Regards,
> Minal
> 
> -----Original Message-----
> From: Brian Norris [mailto:computersforpeace@gmail.com] 
> Sent: Saturday, October 12, 2013 3:55 AM
> To: Shah, Minal
> Cc: Mike Frysinger; Mukherjee, Somnath; linux-mtd@lists.infradead.org; Gupta, Pekon; Parikh, Urmil
> Subject: Re: MTD utils v1.5.0: MEMERASE64 ioctl failed error
> 
> Hi Minal,
> 
> On Wed, Oct 09, 2013 at 05:05:11AM +0000, Shah, Minal wrote:
>> I am using MTD utils version 1.5.0 for DRA7 (Vayu) platform.
>>
>> I have bad blocks in some of my NAND partitions which I am not able to erase from linux kernel.
> 
> MTD does not allow erasing bad blocks. This is prohibited by NAND
> datasheets. There are occasions where, for debugging purposes, one might
> need to erase a "bad" block that is not actually bad, but MTD does not
> provide an interface for doing this. An interface for doing so was
> discussed a while back, but nothing was merged.


Yes, this is a shortcoming in mtd, I think.  Blocks can be marked as bad, but
never "un-marked".  This is the reason I needed a module parameter
"ignore_badblocks" in the docg4 driver.

But any solution is complicated by the diversity of methods for marking bad
blocks (fixed or relocatable flash table, oob marker), and various reasons why
it is so marked (factory, user).  This is why u-boot says that 'nand scrub' is
potentially "unsafe".  You have to know the internals of your device.

Mike