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.
Signature · 4 lines
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)
Quoted 5 lines · In message <[email protected]> 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.
Quoted 2 lines
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
Signature · 3 lines
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.
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.
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
Quoted 30 lines · Wolfgang Denk
Quoted 4 lines · In message <[email protected]> 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.
Quoted 2 lines
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
Quoted 5 lines · In message <[email protected]> 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
Signature · 4 lines
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_
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
Quoted 19 lines · Wolfgang Denk
Quoted 5 lines · In message <[email protected]> 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
Quoted 2 lines · In message <[email protected]> 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
Signature · 6 lines
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.
Quoted 1 line · Wolfgang Denk
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
Quoted 3 lines · In message <[email protected]> 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.
Quoted 5 lines
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.
Quoted 3 lines
* 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.
Quoted 1 line
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
Signature · 4 lines
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.