From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerlando Falauto Date: Wed, 14 Mar 2012 07:44:45 +0100 Subject: [U-Boot] SPI flash writing In-Reply-To: <201203132216.36783.vapier@gentoo.org> References: <4F5F9103.1030807@keymile.com> <201203131635.53765.vapier@gentoo.org> <201203132216.36783.vapier@gentoo.org> Message-ID: <4F603E5D.205@keymile.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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