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,
Quoted 4 lines · in message <[email protected]> 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.
Quoted 4 lines
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?
Quoted 1 line
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.
Quoted 2 lines
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
Quoted 4 lines
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
Signature · 3 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de You can observe a lot just by watching. - Yogi Berra
Hi Wolfgang,
Quoted 4 lines
Quoted 3 lines
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?
Quoted 4 lines
Quoted 3 lines
Hence my plans are that U-boot should perform the following on startup:
1) Try fetching new application-image using tftp against some hardcoded addressWhy a hardcoded address instead of the usual, configurable mechanism?
Because there is no keyboard, nor any display attached to the board.
Quoted 6 lines
Quoted 1 line
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.
Quoted 4 lines
Quoted 2 lines
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 exampleboard/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.
Quoted 6 lines
Quoted 3 lines
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,
Quoted 3 lines · in message <[email protected]> you wrote:
Quoted 2 lines
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
Quoted 2 lines
Quoted 1 line
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.
Quoted 2 lines
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.
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 4 lines
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.
Quoted 2 lines
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 ...
Quoted 1 line
Maybe we should gather this information in twiki... Any references?
Sorry, no.
Best regards,
Wolfgang Denk
Signature · 4 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de To get something done, a committee should consist of no more than three men, two of them absent.
Hi Wolfgang,
Quoted 4 lines
Quoted 2 lines
Quoted 1 line
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.cin my message; see alsoboard/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...
Quoted 5 lines
Quoted 2 lines
Quoted 1 line
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.
Quoted 4 lines
Quoted 2 lines
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...
Quoted 3 lines
Quoted 2 lines
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?
Quoted 6 lines
Quoted 3 lines
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...
Quoted 9 lines
Quoted 4 lines
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...
Quoted 3 lines
Quoted 2 lines
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
Quoted 5 lines · In message <[email protected]> you wrote:
Quoted 3 lines
I already mentioned
board/trab/auto_update.cin my message; see alsoboard/esd/common/auto_update.cOk - 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.
Quoted 4 lines
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).
Quoted 2 lines
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.
Quoted 2 lines
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?
Quoted 3 lines
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.
Quoted 1 line
And then a way to check if tftp exited successfully...
You already have that.
Quoted 4 lines
Quoted 3 lines
Quoted 2 lines
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.
Quoted 1 line
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.
Quoted 3 lines
Quoted 2 lines
tree. So far none of the customers I know of decided to put their scripts into CVS.
That's a shame...
Not really.
Quoted 4 lines
Quoted 2 lines
Quoted 1 line
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
Signature · 3 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Don't panic.
Hi,
Quoted 6 lines
Quoted 4 lines
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/envdirectory).
Ok, then I'm sure my board's kernel dosn't detect the NOR. The only mtd-messages I get concerns the NAND.
Quoted 3 lines
Quoted 2 lines
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.
Quoted 4 lines
Quoted 3 lines
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...
Quoted 11 lines
Quoted 4 lines
Quoted 3 lines
Quoted 2 lines
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.
Quoted 1 line
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
Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 5 lines
Quoted 4 lines
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
Signature · 4 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de What the gods would destroy they first submit to an IEEE standards committee.
Dear Wolfgang,
Quoted 10 lines
Quoted 5 lines
Quoted 4 lines
Quoted 3 lines
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 ofbandwidth 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