[U-Boot-Users] Re: Using u-boot as application-firmware upgrader / Performing logical operations?

[Martin Egholm Nielsen]

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:
>>1) 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.

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

>>3) 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