[U-Boot-Users] Field upgrade

[U-Boot-Users] Field upgrade

[Chris Simmonds]

Hi,

One of my requirements is that the firmware be field upgradeable. The 
problem at the moment is that if something goes wrong while erasing and 
programming a new u-boot there is no recovery without a jtag/bdm 
debugger. Does anyone have a solution, or is it not a problem in 
practice? I was playing with the idea of having a backup u-boot and some 
method of falling back to it if the primary copy is corrupt.

Chris.


-- 
Chris Simmonds                        2net Limited
chris at 2net.co.uk                      http://www.2net.co.uk/
Tel:   +44 (0)1962 869003             Fax:   +44 (0)870 056 7556
"If it's not connected, it's not effective"(tm)

[U-Boot-Users] Field upgrade

[Wolfgang Denk]

In message <3FCCA417.9020500@2net.co.uk> you wrote:
> 
> One of my requirements is that the firmware be field upgradeable. The 
> problem at the moment is that if something goes wrong while erasing and 
> programming a new u-boot there is no recovery without a jtag/bdm 
> debugger. Does anyone have a solution, or is it not a problem in 

There is no solution in software alone. If you have hardware  support
which for example detects a failing boot (by waiting with timeout for
a signal to be set by a successfully booting system) and then toggles
for example boot devices you can do something like that.

But there is no simple way to do this in software alone.

> practice? I was playing with the idea of having a backup u-boot and some 
> method of falling back to it if the primary copy is corrupt.

You can create a backup copy of U-Boot - but how will  you  boot  it?
U-Boot  is  linked for a fix address so you cannot easily shift it in
memory. And even if you could - your board will still  start  from  a
fix reset vector - if it does not find valifd code there you may have
a working image somewhere else but it will not help you.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
This is an unauthorized cybernetic announcement.

[U-Boot-Users] Field upgrade

[Callebaut, Benoit]

Hi,
We use a fail back mecanism for Linux but no such mechanism fo u-boot. 
During the upgrade, we do also a CRC check to be sure that the updgrade was
done correctly.
And with a flag written in a custom config sector of the flash, we can tell
to ppcboot if the upgraded kernel was running correctly.
But for our safety we won't never upgrade ppcboot.


> -----Original Message-----
> From: Chris Simmonds [mailto:chris at 2net.co.uk]
> Sent: Tuesday, December 02, 2003 3:39 PM
> To: u-boot-users at lists.sourceforge.net
> Subject: [U-Boot-Users] Field upgrade
> 
> 
> Hi,
> 
> One of my requirements is that the firmware be field upgradeable. The 
> problem at the moment is that if something goes wrong while 
> erasing and 
> programming a new u-boot there is no recovery without a jtag/bdm 
> debugger. Does anyone have a solution, or is it not a problem in 
> practice? I was playing with the idea of having a backup 
> u-boot and some 
> method of falling back to it if the primary copy is corrupt.
> 
> Chris.
> 
> 
> -- 
> Chris Simmonds                        2net Limited
> chris at 2net.co.uk                      http://www.2net.co.uk/
> Tel:   +44 (0)1962 869003             Fax:   +44 (0)870 056 7556
> "If it's not connected, it's not effective"(tm)
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20031202/02b13e18/attachment.htm 

[U-Boot-Users] Field upgrade

[Thomas Lange]

Sure there is a sw solution! We have been using it for
2 years now. Check out board "gth".

We use a pre loader called miniboot, which boots the first
image with correct crc it finds in flash.

See http://www.opensource.se/

This allows us to upgrade u-boot in field. Even if we loose
power during upgrade, we will always have a valid u-boot
image to boot.

/Thomas

Wolfgang Denk wrote:
> In message <3FCCA417.9020500@2net.co.uk> you wrote:
> 
>>One of my requirements is that the firmware be field upgradeable. The 
>>problem at the moment is that if something goes wrong while erasing and 
>>programming a new u-boot there is no recovery without a jtag/bdm 
>>debugger. Does anyone have a solution, or is it not a problem in 
> 
> 
> There is no solution in software alone. If you have hardware  support
> which for example detects a failing boot (by waiting with timeout for
> a signal to be set by a successfully booting system) and then toggles
> for example boot devices you can do something like that.
> 
> But there is no simple way to do this in software alone.
> 
> 
>>practice? I was playing with the idea of having a backup u-boot and some 
>>method of falling back to it if the primary copy is corrupt.
> 
> 
> You can create a backup copy of U-Boot - but how will  you  boot  it?
> U-Boot  is  linked for a fix address so you cannot easily shift it in
> memory. And even if you could - your board will still  start  from  a
> fix reset vector - if it does not find valifd code there you may have
> a working image somewhere else but it will not help you.
> 
> Best regards,
> 
> Wolfgang Denk
> 

[U-Boot-Users] Field upgrade

[Wolfgang Denk]

In message <3FCD0356.30502@corelatus.com> you wrote:
> Sure there is a sw solution! We have been using it for
> 2 years now. Check out board "gth".
> 
> We use a pre loader called miniboot, which boots the first
> image with correct crc it finds in flash.

You are just shifting the  problem  to  a  diferent  level,  actually
adding MORE complexity.

Just one question: How do you reliably field upgrade  the  "miniboot"
image running on your board?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
All he had was nothing, but that was something, and now it  had  been
taken away.                             - Terry Pratchett, _Sourcery_

[U-Boot-Users] Field upgrade

[Thomas Lange]

We dont upgrade miniboot. It is so simple, we never
have to upgrade it. It does not touch any cpu registers,
memory configuration and such stuff.

It only scans the flash for an image with correct crc
and starts it.

During the past two years, we have upgraded ppcboot/u-boot
on live systems several times to add functionality, correct bugs
etc.

But miniboot is the same.

All advanced stuff is done by u-boot. Shipping a system to a customer
without a possibility to upgrade u-boot without risking a dead card
is not an option IMHO.

/Thomas


Wolfgang Denk wrote:
> In message <3FCD0356.30502@corelatus.com> you wrote:
> 
>>Sure there is a sw solution! We have been using it for
>>2 years now. Check out board "gth".
>>
>>We use a pre loader called miniboot, which boots the first
>>image with correct crc it finds in flash.
> 
> 
> You are just shifting the  problem  to  a  diferent  level,  actually
> adding MORE complexity.
> 
> Just one question: How do you reliably field upgrade  the  "miniboot"
> image running on your board?
> 
> Best regards,
> 
> Wolfgang Denk
> 

[U-Boot-Users] Field upgrade

[Wolfgang Denk]

In message <3FCD15CD.4010209@corelatus.com> you wrote:
> We dont upgrade miniboot. It is so simple, we never
> have to upgrade it. It does not touch any cpu registers,

I tend to doubt that. You cannot run any code without using CPU registers ;-)

As mentioned before: you just shift the problem to a different level.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
PROGRAM - n.  A magic spell cast over a computer  allowing it to turn
one's input into error messages.
v. tr. - To engage in a pastime similar to banging one's head against
a wall, but with fewer opportunities for reward.

[U-Boot-Users] Field upgrade

[Thomas Lange]

Wolfgang Denk wrote:
> As mentioned before: you just shift the problem to a different level.

Well, if you want to be able to safely upgrade u-boot in field, you
have two choices.

a) Do it in hardware
    Requires you to have control over card design.

b) Do it in software
    Can be done on "any" card.

Drawbacks for
a)
* If you make an error in your design that you discover
   to late, you are in big trouble.
* Adds complexity to card design.

b)
* If you make an error in your pre u-boot program, you may
   have to upgrade it. If so, card will die if something
   happens while you rewrite that sector.


Which solution is better?
I would say b), even if you have control of card design.
Why?
Because sw is flexible, hw is not. If you make an error in your
card design, you will loose months of lead time.

/Thomas

[U-Boot-Users] Field upgrade

[Wolfgang Denk]

In message <3FCD25F8.4080308@corelatus.com> you wrote:
> 
> Well, if you want to be able to safely upgrade u-boot in field, you
> have two choices.

U-Boot is not special in this respect. Either  you  treat  U-boot  as
boot loader, or as application package.

> a) Do it in hardware
>     Requires you to have control over card design.
> 
> b) Do it in software
>     Can be done on "any" card.

I don't know of a reliable  way  to  field-update  the  boot  loader.
Period.

> * If you make an error in your pre u-boot program, you may
>    have to upgrade it. If so, card will die if something
>    happens while you rewrite that sector.

You just shifted levels.  U-Boot  becomes  an  application,  and  the
problem still exists with your new (smaller, simpler) boot loader.

You added complexity and duplicated code (for example  to  check  the
CRC's). In general that means that your system is more likely to have
errors than a simpler system.

> Which solution is better?

This was not a question. The question was about a reliable way for  a
field upgrade of the boot loader.

There is none, except with special hardware support.


Let's stop this fruitless discussion here, please. You have  a  setup
which  works  fine  for you, no doubt about that. But it does not fix
the problem discussed here.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
To the systems programmer,  users  and  applications  serve  only  to
provide a test load.