[PATCH] mtd: nand: add option to erase NAND blocks even if detected as bad.

[Mario Rugiero]

2017-05-12 5:24 GMT-03:00 Boris Brezillon <boris.brezillon at free-electrons.com>:
> On Fri, 12 May 2017 05:16:08 -0300
> Mario Rugiero <mrugiero at gmail.com> wrote:
>
>> 2017-05-12 5:12 GMT-03:00 Richard Weinberger <richard.weinberger at gmail.com>:
>> > Mario,
>> >
>> > On Fri, May 12, 2017 at 7:39 AM, Mario J. Rugiero <mrugiero at gmail.com> wrote:
>> >> Some chips used under a custom vendor driver can get their blocks
>> >> incorrectly detected as bad blocks, out of incompatibilities
>> >> between such drivers and MTD drivers.
>> >> When there are too many misdetected bad blocks, the device becomes
>> >> unusable because a bad block table can't be allocated, aside from
>> >> all the legitimately good blocks which become unusable under these
>> >> conditions.
>> >> This adds a build option to workaround the issue by enabling the
>> >> user to free up space regardless of what the driver thinks about
>> >> the blocks.
>> >
>> > Hmm, this sounds like a gross hack.
>> It is, but I see no other solution. The NAND chips were used in an
>> incompatible way by a hack-n-slash driver made by allwinner, and
>> trying to load them with a proper MTD driver fails miserably if this
>> is not done.
>> If anyone can propose a better solution I'll more than happily implement it.
>> I'm open to suggestions, and of course I'm open to rejection of my
>> patches if needed.
>
> u-boot provides the nand.scrub command, which does exactly what you're
> looking for. And no, I don't think it's a good idea to allow erasing
> bad blocks, at least not by default.
>
> If we really want to support this feature in linux, this should be
> explicitly enabled through debugfs.
If I do this, does it stand a chance at getting upstream?
If so, I'll have it done soon.
Note however that the build option is disabled by default. I get that
there should also be one runtime option, disabled by default, exposed
through debugfs. Does that sound right?
>
>> >
>> >> Example usage: recovering NAND chips on sunxi devices, as explained
>> >> here: http://linux-sunxi.org/Mainline_NAND_Howto#Known_issues
>> >
>> > What this wiki suggests is not wise.
>> > How can you know which blocks are really bad and which not?
>> You don't, at least not without an even grosser hack implementing read
>> support for their incompatible format.
>> Would that be better? I might attempt it if desired.
>
> No, please don't do that, at least not in the kernel. If you really
> want to parse the old format, you should develop a tool that reads NAND
> pages in raw mode, stores the list of bad blocks somewhere and then
> re-use this list to select which blocks should be forcibly erased.
>
> Not sure it's worth the pain :-).
It's worth the pain to me. I'm dealing with a bit rotten 3.4 based
pile of cr*p on production because of this. Whatever I have to do to
get those machines running the mainline kernel is worth it.