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

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

[Martin Egholm Nielsen]

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

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

[Wolfgang Denk]

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:
> 
> 1) Try fetching new application-image using tftp against some hardcoded 
> address

Why a hardcoded address instead of the usual, configurable mechanism?

> 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.

> 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

> 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

-- 
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

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

[Martin Egholm Nielsen]

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:
>>1) 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.

>>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.

>>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
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

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

[Wolfgang Denk]

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

-- 
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.

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

[Wolfgang Denk]

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

-- 
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.

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

[Martin Egholm Nielsen]

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

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

[Martin Egholm Nielsen]

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

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

[Wolfgang Denk]

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

-- 
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.

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

[Martin Egholm Nielsen]

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