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
- 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.
- 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.
- 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