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

[Martin Egholm Nielsen <martin@egholm-nielsen.dk>]

Hi Wolfgang,

>>>You're not the first to implement this. See the existing code.
>>Can you please guide me to where?
> I already mentioned board/trab/auto_update.c in my message; see  also
> board/esd/common/auto_update.c
Ok - so you suggestion is to borrow some code from there and put into my 
board's init-board functions?
That's a way to do it, yes...

>>>Why a hardcoded address instead of the usual, configurable mechanism?
>>Because there is no keyboard, nor any display attached to the board.
> You can (and should) still store the  IP  address  in  a  envrionment
> variable  so  ir  remains  changeable  -  either through a netconsole
> interface, or by a Linux application.
Ohh, of course - that's the way I'll do it. That is, saving it in an 
environment-variable.
In order to change it from Linux, access to the NOR-flash is required, 
right?! I'm not quite sure I have that?
Or do I recall correctly, if there was something about having 
environment in nand, as well?
But that would require the nand to be split into several "partitions", 
so that my Linux-root-fs does not consume all.

>>That's right! But in case there is no tftpserver responding within x 
>>seconds, the commands should abandon.
> Define "responding". There are many failure modes, some temporary and
> recoverable.
Dooh! I forgot that tftp use UDP. Then "responding" means one correct 
response from the tftp-server within x seconds. I guess there is a 
"timeout" feature in u-boot today, as well:

=> tftp 100000 blah
ENET Speed is 100 Mbps - FULL duplex connection
TFTP from server 192.168.0.1; our IP address is 192.168.0.2
Filename 'blah'.
Load address: 0x100000
Loading: T T T T T T T T T T
Retry count exceeded; starting again
=== 8< 8< ===

The printing of T's must depend on correct data within a time-frame...
Hence, what I want is perhaps (?) environment variables controlling how 
how many retries, the interval between each "T"-try, and the amount of 
tries before abondoning...
And then a way to check if tftp exited successfully...

>>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.
> You can do that easily - just not by timeout only.
How?

>>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).
> Yes, of course. This is what I'm talking about, too. Depending on the
> complexity this can be done as  script,  or  you  may  find  it  more
> efficient to code it in C.
Is there a document describing these scripting possibilities?
DULG seems to be the only one...

>>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?
> It can be done in a general way now, but requirements differ, and  so
> you will end up seeing many different implementations. Of course what
> you  can  actually _see_ is only what ends up as C code in the U-Boot
> tree. So far none of the customers I know of  decided  to  put  their
> scripts into CVS.
That's a shame...

>>Of course, the boards' hardware configurations are different, but they 
>>often have a common denominator - namely serial- and ethernet-connections.
> Sure. And/or USB memory sticks, or CompactFlash cards, or ...
Well, yes. But ethernet and serial commands for downloading data is 
included in as u-boot runtime commands, whereas the others are not (?).

BR,
  Martin Egholm