[U-Boot-Users] Using u-boot as application-firmware upgrader / Performing logical operations?
Hi there,
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). 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 2) Timeout after 2 secs if no connection (skip to pt 5) (logigs needed) 3) Perform some simple validation of the image - e.g. check that the last bytes of the image is "egholm" (logics needed) 4) If validated, nuke the flash and put the new image on 5) Launch Linux kernel from nor with root-fs in nand
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? Please let me hear your comments...
BR, Martin Egholm
Dear Martin,
in message cqbedv$el6$1@sea.gmane.org you wrote:
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.
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?
- 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.
- 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
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.
Best regards,
Wolfgang Denk
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
Dear Martin,
in message 41C968B7.6050300@egholm-nielsen.dk you wrote:
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
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.
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.
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.
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.
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.
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 ...
Maybe we should gather this information in twiki... Any references?
Sorry, no.
Best regards,
Wolfgang Denk
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
In message cqc5hl$ajn$1@sea.gmane.org you wrote:
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?
No, I suggested to _look_ what already exists, and then decide if it makes sense to use parts or more of the existing code, and.or to combine or replace it by some shell scripts.
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?
Of course yoiu have - through the MTD layer (and the stuff in the tools/env directory).
Or do I recall correctly, if there was something about having environment in nand, as well?
You can do this, too, if you're really adventurous. I don;t think it is a good idea, though.
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
Define "correct" response. What about time outs later?
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...
Perhaps.
And then a way to check if tftp exited successfully...
You already have that.
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?
Use the return code in some conditional, like an "if tftp ... ; then ... ; fi" or some "tftp ... && ..." - whatever you use in other shell scripts, too.
Is there a document describing these scripting possibilities?
man sh? Ok, ok, the hush shell does not provide every bell and whistle the bash has, but it's a pretty complete thing. See the busybox docs for more information.
tree. So far none of the customers I know of decided to put their scripts into CVS.
That's a shame...
Not really.
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 (?).
Yes, of course they are.
Best regards,
Wolfgang Denk
Hi,
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?
Of course yoiu have - through the MTD layer (and the stuff in the tools/env directory).
Ok, then I'm sure my board's kernel dosn't detect the NOR. The only mtd-messages I get concerns the NAND.
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
Define "correct" response. What about time outs later?
That would be ok. What I want is u-boot to try to see if there is a tftp-server connected (meaning that someone is trying to upgrade the firmware). If not: continue rapidly into Linux and launch the application. I don't wanna spend too much time hanging in u-boot if the reboot were, say, due to a powerfailure.
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...
Perhaps.
:-) I know that is exactly what I'm looking for...
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?
Use the return code in some conditional, like an "if tftp ... ; then ... ; fi" or some "tftp ... && ..." - whatever you use in other shell scripts, too.
Is there a document describing these scripting possibilities?
man sh? Ok, ok, the hush shell does not provide every bell and whistle the bash has, but it's a pretty complete thing. See the busybox docs for more information.
Ahaaaaa!!! There we have it! If one does not know the name of it - one (me) will look under "5.11. U-Boot Scripting Capabilities" (which is empty).
and not in the correct (faq-) section: "14.2.10. How the Command Line Parsing Works"
That title is not intuitive to me. I read: "How the 'Old, simple command line parser' works".
IMHO that beautiful section shouldn't be in a FAQ... :o)
Now, I just need to recompile with the enabling parameter (CFG_HUSH_PARSER).
BR, Martin
In message 41C968B7.6050300@egholm-nielsen.dk you wrote:
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?
AAAAARRRRRGHHHH!!!!!
_If_ you send the message both to my address and to the U-Boot mailing list (which is already redundant and just a waste of bandwidth an my time) then _please_ do it at least as a Cc:
Please NEVER send the same text in several unrelated messages. NEVER!
Best regards,
Wolfgang Denk
Dear 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?
AAAAARRRRRGHHHH!!!!! _If_ you send the message both to my address and to the U-Boot mailing list (which is already redundant and just a waste of bandwidth an my time) then _please_ do it at least as a Cc: Please NEVER send the same text in several unrelated messages. NEVER!
I'm sencirely sorry! Again this is due to the gmane-layer. I'm just posting to a newsgroup on news.gmane.org. Hence my additional sending To: you.
Now you have iterated me in to the prober way :-)
BR, Martin
participants (2)
-
Martin Egholm Nielsen -
Wolfgang Denk