[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.
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
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
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
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
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
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
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
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
participants (3)
-
Chris Simmonds -
Thomas Lange -
Wolfgang Denk