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

[Scott Wood <scottwood@freescale.com>]

Wolfgang Denk wrote:
> Dear Scott,
> 
> In message <4A39685F.6030304@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