[U-Boot] PATCH: bugfix for nand erase failure with bad blocks

[Michele De Candia (VT)]

Scott Wood wrote:
> Wolfgang Denk wrote:
>> Dear Scott,
>>
>> In message <4A39685F.6030304 at freescale.com> you wrote:
>>> Hmm... perhaps check the alignment?  If "end" is supposed to be the 
>>> last to-be-erased byte, not the first not-to-be-erased byte, then if 
>>> the low bits are 0 it's a size (and gets a warning) and if they're 1 
>>> it's an end?
>>
>> Stop here. Don't add fancy stuf that nobody expects.
>
> Nobody expects the semantics to silently change...
>
> I'm not particularly advocating this approach, just throwing out 
> alternatives.  Leaving it alone is probably best.
>
>> Ask yourself what the end user expects - we all think of "erase"
>> preparing the grounds for "write", right?
>
> Sometimes.  Other times, it could be preparing for use by a filesystem 
> (which may not use the same bad block handling scheme), to reset the 
> environment, for testing, etc.
>
> We have the plus syntax specifically for the use case of erase+write 
> of a specific number of bytes; IMO that's the place for this kind of 
> interpretation.
>
>> So both should work oin the
>> same NAND flash region when given the same arguments (offset and seze,
>
> So then there would be no reliable way of erasing a specific range of 
> flash.  To properly use the block-skipping approach, the user needs to 
> have in mind a range of actual blocks that the data can take up (i.e. 
> a maximum number of bad blocks to expect), so that they can avoid 
> locating the next partition within that range.  I don't think it makes 
> sense to try to completely hide this.
>
> Perhaps "write" should accept an optional limit argument, returning an 
> error if enough bad blocks were encountered to bust the limit.
>
> > no matter how these are specified).
>
> If the syntax were changed to start/end, but the erase could go beyond 
> end anyway, that would be extremely confusing.
>
> -Scott
Summarizing, there are two alternatives:

- change 'erase' command aligning it with 'write' and 'read' command 
(what the patch does);

- add a third field to the 'erase' command, maybe called 'limit', over 
which erasing can't be done:

    'nand erase start offset limit'

  In this case, I think that 'write' command may be aligned with this 
new syntax too.

It's up to you.

Regards,
Michele