Hi Wolfgang,
I have plans of using u-boot as the last-and-ever-working application-firmware-upgrade (in case my Linux [from NAND] is somehow damged).
You're not the first to implement this. See the existing code.
Can you please guide me to where?
Hence my plans are that U-boot should perform the following on startup:
- Try fetching new application-image using tftp against some hardcoded
address
Why a hardcoded address instead of the usual, configurable mechanism?
Because there is no keyboard, nor any display attached to the board.
- Timeout after 2 secs if no connection (skip to pt 5) (logigs needed)
A timeout is probably not what you want. And how do you define "no connection"? There is many steps for a TFTP download which can produce errors, and you will need to handle them - a simple timeout may as well kill running download, or otherwise stuck downloads may hang your system.
That's right! But in case there is no tftpserver responding within x seconds, the commands should abandon. Hence, what I'd like, was a way to determine if the download was successfull - e.g. by comparing the return value for the command.
- Perform some simple validation of the image - e.g. check that the
last bytes of the image is "egholm" (logics needed)
Why not use the built-in verification (through CRC checksum. timestamp, image name etc.) ? See for example board/trab/auto_update.c
Ok, I see your point. I was hoping to perform the logics using some scripting functionality in u-boot (although http://www.denx.de/twiki/publish/DULG/UBootScripts.html is quite empty).
As you mention, many before me has done (requested) this, but we all run different boards. Hence, wouldn't it be nice if one could use some "standard" u-boot runtime scripting to do this, instead of having to write the "same" update code in each of our boards' init-blocks?
Of course, the boards' hardware configurations are different, but they often have a common denominator - namely serial- and ethernet-connections.
I reckon there is a problem with 2) where the remainder of the script should only run in case the tftp-action went well. And the same goes for 3). Does this idea have a future?
The ide is OK. It has been implemented before. But I disagree with your approach, at least as far as the timeout and image verification are concerned.
Maybe we should gather this information in twiki... Any references?
BR, Martin Egholm