From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michele De Candia (VT) <michele.decandia@valueteam.com>
Date: Fri, 19 Jun 2009 09:01:58 +0200
Subject: [U-Boot] PATCH: bugfix for nand erase failure with bad blocks
In-Reply-To: <4A396F63.8030500@freescale.com>
References: <4A3798C4.8000303@valueteam.com>	<20090616181035.52228832E416@gemini.denx.de>	<4A37F7BF.2090101@valueteam.com>	<20090616200940.DD093832E416@gemini.denx.de>	<4A37FE47.3030203@freescale.com>
	<4A3898B5.8060309@valueteam.com>	<4A389EE9.1000005@valueteam.com>	<20090617155421.GB6333@loki.buserror.net>	<4A391724.2080207@valueteam.com>
	<4A39685F.6030304@freescale.com>
	<20090617221506.759C7832E416@gemini.denx.de>
	<4A396F63.8030500@freescale.com>
Message-ID: <4A3B37E6.2010203@valueteam.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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