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