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

Michele De Candia
2009-06-19T07:01:58Z

Scott Wood wrote:
> 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
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