[U-Boot-Users] Safe firmware updates

Hi,
Power disconnect during firmware update:
We are implementing facility for automatic firmware upgrades (either the Linux uImage or cramfs) on our embedded device. However there is a requirement that the device is not broken by (the user for example) disconnecting the power supply at any stage during the flash update.
In the absence of a backup battery, I guess the boot loader would have to be modified to cope with this. Has anybody produced a solution already?
If not I'm considering adding a command to u-boot. 'update' could work as follows:
1) Linux application / scripts are responsible for downloading the firmware upgrade, then erasing and copying into an image in free area of the flash with CRC.
2) Linux reboots the device, so u-boot can take over.
3) 'update' command is called early in bootcmd script.
4) 'update' routine checks specified flash location for new upgrade image with valid CRC. If no image found or has bad CRC it returns, control passes to next command in bootcmd, and Linux boots normally.
5) 'update' routine erases target area of flash, and then copies content of upgrade image to target location.
6) 'update' routine erases upgrade image to prevent upgrade attempt on subsequent boots.
Power cut during stage 1 would result in original firmware remaining.
Power cut during stages 2 to 5 would result in firmware upgrade when power is restored.
Power cut during state 6 would result in new firmware remaining. (as partial erase of update image would have bad CRC).
Maybe the upgrade (cramfs, kernel uImage, etc) could be stored in another uImage with a new type.
Any comments?
Ian
DISCLAIMER:
The information contained in this message is for the intended addressee only and may contain confidential and/or privileged information. If you are not the intended addressee, please delete this message and notify the sender; do not copy or distribute this message or disclose its contents to anyone. This email has been scanned by our Anti Virus software before leaving the premises. APD Communications takes no responsibility for any damage or loss caused by any undetected virus being inadvertently transmitted with this message.

...
- ‘update’ command is called early in bootcmd script.
...
Any comments?
IMHO there is a possibility of problems with this early routines, how to upgrade them? What with reset vector? Shouldn't this be two stage bootloader?
Best regards!

In message dt2j7g$8qd$1@sea.gmane.org you wrote:
IMHO there is a possibility of problems with this early routines, how to upgrade them? What with reset vector? Shouldn't this be two stage bootloader?
What are you talking about? either me or you misunderstood something.
Best regards,
Wolfgang Denk

Wolfgang Denk napisał(a):
In message dt2j7g$8qd$1@sea.gmane.org you wrote:
IMHO there is a possibility of problems with this early routines, how to upgrade them? What with reset vector? Shouldn't this be two stage bootloader?
What are you talking about? either me or you misunderstood something.
Best regards,
Wolfgang Denk
Yes of course, my mistake - sorry. But by the way, is there a possibility for safely update u-boot?
Best regards!

In message dt527p$arr$1@sea.gmane.org you wrote:
Yes of course, my mistake - sorry. But by the way, is there a possibility for safely update u-boot?
Yes, if you have hardware to support this (i. e. two flash banks that can be swapped, where the "switch" can be controlled by software, remembers it's state when powered off *and* has some kid of watchdog function to toggle back to the other position in case the system does not come up). Not many systems support this ;-)
Best regards,
Wolfgang Denk

In message 9D8FC3304AA0924E9CD0A211DFEDCBAB0164D7AF@bespin.apdcomms.co.uk you wrote:
We are implementing facility for automatic firmware upgrades (either the Linux uImage or cramfs) on our embedded device. However there is a requirement that the device is not broken by (the user for example) disconnecting the power supply at any stage during the flash update.
This is not new. It's actually a astandrard requirement.
In the absence of a backup battery, I guess the boot loader would have to be modified to cope with this. Has anybody produced a solution already?
There is no need to change anything. U-Boot is perfectly capable of supporting such requirements.
- 'update' routine checks specified flash location for new upgrade
image with valid CRC. If no image found or has bad CRC it returns, control passes to next command in bootcmd, and Linux boots normally.
- 'update' routine erases target area of flash, and then copies content
of upgrade image to target location.
Why would you do that if the new image is already in flash? Just swap boot addresses...
Any comments?
Your design is much too complicated. Keep it simple.
Best regards,
Wolfgang Denk
participants (3)
-
do
-
Ian Ridge
-
Wolfgang Denk