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:vap...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
