From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Egholm Nielsen Date: Wed, 22 Dec 2004 16:57:33 +0100 Subject: [U-Boot-Users] Re: Using u-boot as application-firmware upgrader / Performing logical operations? In-Reply-To: <1Ch7jo-0kHzRg0@fmrl09.sul.t-online.com> References: <41C968B7.6050300@egholm-nielsen.dk> <1Ch7jo-0kHzRg0@fmrl09.sul.t-online.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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