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

Scott Wood
2009-06-17T22:34:11Z

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