RE: [U-Boot-Users] Safe firmware updates
Thanks for your comments
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.
That's great news, but how?
- '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?
I considered of doing it like this because we have limited flash space and need to re-use a flash partition normally usually for logging data. We haven't got enough space to store 2 copies of the uImage, and 2 copies of the cramfs file system. We could automatically change the mtdparts parameter in bootargs after each update to reflect this, but this would mean a change to u-boot and its getting too complicated again.
Just swap boot addresses...
I understand I could put a second bootm command in bootargs to automatically switch boot address, but how would I swap cramfs file systems in a safe way? The flash partition used for the cramfs is currently specified using 'root=/dev/mtdblock2' in bootargs, but I don't see how to make u-boot change this to say 'root=/dev/mtdblock3 automatically'.
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.
In message 9D8FC3304AA0924E9CD0A211DFEDCBAB0164D90A@bespin.apdcomms.co.uk you wrote:
There is no need to change anything. U-Boot is perfectly capable of supporting such requirements.
That's great news, but how?
For example, use a hush shell script.
Why would you do that if the new image is already in flash?
I considered of doing it like this because we have limited flash space and need to re-use a flash partition normally usually for logging data. We haven't got enough space to store 2 copies of the uImage, and 2
But the procvedure you described sounded like storing two versions of the image, and if you're looking for *SAFE* updates you have no other choice anyway (except for providing an emergency boot mode from external storage (USB stick, CF card, etc.) or over the network.
copies of the cramfs file system. We could automatically change the mtdparts parameter in bootargs after each update to reflect this, but this would mean a change to u-boot and its getting too complicated again.
Why do you think that changing bootargs (or any other environment variable) means "a change to u-boot"? It's just a variable setting, which can be changed any time, no matter if running U-Boot or Linux.
I understand I could put a second bootm command in bootargs to automatically switch boot address, but how would I swap cramfs file systems in a safe way? The flash partition used for the cramfs is currently specified using 'root=/dev/mtdblock2' in bootargs, but I don't see how to make u-boot change this to say 'root=/dev/mtdblock3 automatically'.
Where exactly is the problem? There are *many* ways to solve this; for example, you can start with definitios like these:
setenv kernel_addr 0xDEADBEEF setenv rootpart 2 setenv setroot 'setenv bootargs root=/dev/mtdblock${rootpart}' setenv add_foo 'setenv bootargs ${bootargs} foo' setenv add_bar 'setenv bootargs ${bootargs} bar' ... setenv bootcmd 'run setroot add_foo add_bar ... ; bootm ${kernel_addr}'
Then all you need to do is change the "kernel_addr" variable to boot using a different kernel image; and change "rootpart" to boot from a different partition. Alternatively, you could as well redefine the MTD partition map using the mtdargs mechanism, etc. etc.
See http://www.denx.de/wiki/view/DULG/LinuxBootArgs
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
PLEASE TURN THIS OFF, or post from a different mail address that does not add such stipid disclaimers.
Best regards,
Wolfgang Denk
participants (2)
-
Ian Ridge -
Wolfgang Denk