From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Frysinger Date: Tue, 13 Mar 2012 16:11:29 -0400 Subject: [U-Boot] SPI flash writing In-Reply-To: <4F5F9103.1030807@keymile.com> References: <4F5F9103.1030807@keymile.com> Message-ID: <201203131611.31287.vapier@gentoo.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tuesday 13 March 2012 14:25:07 Gerlando Falauto wrote: > As it turned out, our update procedure: > > sf probe 0;sf erase 0 50000;sf write ${load_addr_r} 0 ${filesize} > > mistakenly expects a maximum size of 0x50000 (327680) bytes for > u-boot.kwb. Sadly, the latest u-boot trunk results in a binary size for > that board which is dangerously close to that limit. Hence, after adding > some innocent lines of code, the update procedure could brick the board > (for no evident reason and with no error message whatsoever) if the > binary size crosses that boundary. sounds like you should define CONFIG_BOARD_SIZE_LIMIT. this will turn it from a runtime failure into a build time failure as u-boot will do size checking on the image for you. > From what I can understand, writing into a sector which has not been > erased first is an acceptable behaviour of the flash interface, it will > just set to zero whatever bits are not zero already, without reporting > any error whatsoever. correct > 1) a "+" syntax to the "sf update" command so it can be used with > ${filesize} as a parameter, and/or some "read,replace,erase,overwrite" > block mechanism for the last (incomplete) block "+len" is already in there for erase, so it'd be trivial to add to the update command. feel free to post a patch and i'd be happy to review/merge. > 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. > 3) a command line option ("sf write -v" and/or to "sf update -v"), or an > entirely new command (like "sf writeverify", "sf updateverify") to read > back after writing so to double-check what really ended up being written > to the flash before it's too late. i don't think our other flash interfaces have a verify command, so this would be a general question -- the spi flash interface shouldn't diverge if we don't want this in general. then again, this too would be a fairly simple thing to write in a hush script. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: