[U-Boot] SPI flash writing

[Gerlando Falauto <gerlando.falauto@keymile.com>]

On 03/14/2012 03:16 AM, Mike Frysinger wrote:
> On Tuesday 13 March 2012 17:31:02 Falauto, Gerlando wrote:
>> From: Mike Frysinger [mailto:vapier at gentoo.org]
>>> On Tuesday 13 March 2012 16:17:52 Jason Cooper wrote:
>>>> On Tue, Mar 13, 2012 at 04:11:29PM -0400, Mike Frysinger wrote:
>>>>> On Tuesday 13 March 2012 14:25:07 Gerlando Falauto wrote:
>>>>>> 2) an out-of-boundary-check againts the flash size so at least a
>>>>>> warning is issued when you use too big a size value
>>>>>
>>>>> i'm not sure about this.  if you want to do size checking, then enable
>>>>> the hush shell and do it in a script.
>>>>
>>>> Is there a programatic way to get the size of the flash at runtime from
>>>> the hush script?
>>>
>>> no.  question is, do you really need that ?  sounds like you know ahead of
>>> time how big the space is for u-boot, so the size of the flash doesn't
>>> matter.
>>
>> Can't the same command also be used for burning something *other than*
>> u-boot (e.g. a kernel, config section, or something like that)? So the
>> size of the flash *does matter*, doesn't it?
>
> you have to show how it actually does matter.  when you deploy a board and
> programming the flash directly, you don't let the regions grow arbitrarily.
> you know how big the space for u-boot, or the kernel, or dedicated config
> space, or anything else is going to be.  if you want to arbitrarily append
> things, then you're going to use a filesystem.
> -mike

You're right, but I failed to stress enough one point.
The thing is, if you issue e write (or erase) and accidentally cross the 
flash size boundary, you get a wraparound (or aliasing, or whatever you 
want to call it) so that you end up overwriting (e.g. zeroing out bits) 
the initial sectors of the flash. Which is where u-boot normally lies. 
[At least, that's the way I understand things are working right now.] I 
hope you'd agree that this is *a bad thing (TM)*.
My concern is not about the fully aware u-boot developer, who normally 
has some other way to restore a dead board (JTAG, rom monitor, etc...).
My conncern is about mistakes made by the absent-minded user who reads 
an upgrade procedure somewhere, puts an extra zero, and ends up bricking 
their board, whereas it could have been easily avoided.

Thanks,
Gerlando