MTD utils v1.5.0: MEMERASE64 ioctl failed error

[Brian Norris]

On Tue, Oct 15, 2013 at 12:26:48PM -0400, Mike Frysinger wrote:
> On Tuesday 15 October 2013 04:32:23 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.
> 
> as mentioned, there was discussion some time ago about adding this 
> functionality.  but the work never finished.  if you're interested, i'd suggest 
> picking up the work there.

Really old work:

  http://lists.infradead.org/pipermail/linux-mtd/2010-October/032577.html

More recent discussion:

  http://thread.gmane.org/gmane.linux.drivers.mtd/41624/

There were several proposals thrown around, and we ended up in a cycle
of over-engineering suggestions. I don't really see why we can't just
implement an ioctl (MEMNUKE? MEMFORCEERASE? MEMSCRUB?) that skips the
"don't erase bad blocks" check in MEMERASE64. There may be other
reasonable alternatives, but I would warn against anything too complex.

Brian