I am working on a firmware upgrade/downgrade procedure for our embedded board. The board is running embedded linux, 64Mb ram and 4mb flash. The software will be downloaded via service kit and should be deployed on the board. The roll back mechanism in case of failure should be provided. Basically the board will roll back to the previous software version through the boot loader notification that upgrade was done and restart failed, so the boot loader on next re-start will start an old software. There can be entire filesystem or a set of folders to upgrade. Does somebody know any specific/standard procedures or can suggest me anything about what the best way to do that. Thank you for any suggestions.
Firmware upgrade technique
Started by ●January 19, 2004
Reply by ●January 19, 20042004-01-19
dmytro.bablinyuk@tait.co.nz (Dmytro Bablinyuk) wrote in message news:<77972de4.0401182237.62e34ab3@posting.google.com>...> I am working on a firmware upgrade/downgrade procedure for our > embedded board.> The software will be downloaded via service kit and should be deployed > on the board. The roll back mechanism in case of failure should be > provided.[...]> There can be entire filesystem or a set of folders to upgrade. > > Does somebody know any specific/standard procedures or can suggest me > anything about what the best way to do that.Hi! I've implemented this type of scheme three times, not with Linux however. The avionics software certification standard RTCA D0-178B refers to this as "field loading of software", and one of the implementation was so certified. You may dig the documentation of the ABCD Proto-Kernel(tm) and its source code as a starting point. http://www.connotech.com/abcd_proto_kernel/abcd_proto_kernel_intro.htm However, the roll back mechanism is limited to preventing the system from entering the normal operating state and automatic entry into the embedded loader if the software download fails. Another scheme featured application A/B with a sanity/version indication and automatic A/B selection at startup. This particular scheme was not developed past the beta stage, for a consulting customer. Start by downloading http://www.connotech.com/abcd_proto_kernel/abcd_proto_kernel-1.1.tar.gz These schemes are tricky, and the reliability/predictability expectations are high. Personally, I would not attempt to implement it in Linux with a full fledged file system if I were in any way responsible for the support service organization success or failure. Good luck! -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 e-mail: thierry.moreau@connotech.com
Reply by ●January 19, 20042004-01-19
I assume you will be downloading the image into flash. Then to verify that it was a successful update, you have a checksum and also make sure you can come back up after a reset. You will need another flash bank, so a total of two. Suppose you run off flash bank A. Then you want to upgrade it, so you put a new image in flash bank B. You'll need some kind of bit you set in NVRAM somewhere, so you'll know which flash bank to boot from next time. ~~~~~~~~~~~~~~~~~~~~ I worked on another embedded system, with only one Sandisk flash card, and it wasn't possible to do upgrade or downgrades, or at least we didn't think about it. I just explained how to upgrade and downgrade the boot code, but i don't know how to do it for file systems or folders. -MIke dmytro.bablinyuk@tait.co.nz (Dmytro Bablinyuk) wrote in message news:<77972de4.0401182237.62e34ab3@posting.google.com>...> I am working on a firmware upgrade/downgrade procedure for our > embedded board. > The board is running embedded linux, 64Mb ram and 4mb flash. > The software will be downloaded via service kit and should be deployed > on the board. The roll back mechanism in case of failure should be > provided. Basically the board will roll back to the previous software > version through the boot loader notification that upgrade was done and > restart failed, so the boot loader on next re-start will start an old > software. > There can be entire filesystem or a set of folders to upgrade. > > Does somebody know any specific/standard procedures or can suggest me > anything about what the best way to do that. > > Thank you for any suggestions.
Reply by ●January 20, 20042004-01-20
On 18 Jan 2004 22:37:03 -0800, dmytro.bablinyuk@tait.co.nz (Dmytro Bablinyuk) wrote:>I am working on a firmware upgrade/downgrade procedure for our >embedded board. >The board is running embedded linux, 64Mb ram and 4mb flash. >The software will be downloaded via service kit and should be deployed >on the board. The roll back mechanism in case of failure should be >provided. Basically the board will roll back to the previous software >version through the boot loader notification that upgrade was done and >restart failed, so the boot loader on next re-start will start an old >software. >There can be entire filesystem or a set of folders to upgrade. > >Does somebody know any specific/standard procedures or can suggest me >anything about what the best way to do that. > >Thank you for any suggestions.There's probably oodles of solutions -- just picking the right one for your needs is the task. For us the "software" is partitioned into the bootloader and the application. The bootloader is small enough that it fits into one sector of a flash. The application is loaded into the rest of the Flash. On power-up the bootloader is copied into RAM (as you can't run code and flash at the same time from the same Flash device). The bootloader checks the comms for any commands and then validates the application by checking the CRC (or by other means if CRC is too slow). If the Application is corrupted or missing then the bootloader continually waits for a new application to be uploaded. Currently we upload a Motorola S-Record file but a binary image file could readily be used. The bootloader image (in Flash) itself is never overwritten, so it is always valid. This is to mitigate against a lost of connection (if you're doing it over a serial line or modem) so that recovery is possible with just the bootloader running. Ken. +====================================+ I hate junk email. Please direct any genuine email to: kenlee at hotpop.com
Reply by ●January 21, 20042004-01-21
Dmytro Bablinyuk <dmytro.bablinyuk@tait.co.nz> wrote:> I am working on a firmware upgrade/downgrade procedure for our > embedded board. > The board is running embedded linux, 64Mb ram and 4mb flash. > The software will be downloaded via service kit and should be deployed > on the board. The roll back mechanism in case of failure should be > provided. Basically the board will roll back to the previous software > version through the boot loader notification that upgrade was done and > restart failed, so the boot loader on next re-start will start an old > software. > There can be entire filesystem or a set of folders to upgrade.> Does somebody know any specific/standard procedures or can suggest me > anything about what the best way to do that.> Thank you for any suggestions.How large is the software image you're dealing with? Do you have any mass storage other than the 4mb flash? I devised the following system for an embedded linux system: In flash I have:- Backup Kernel Backup Ramdisk Operational Kernel Operational Ramdisk Bootloader These images are compressed and checksummed. When I load firmware, I buffer the image in RAM, verify the checksum, and then copy over the operational firmware in flash. The Bootloader is never field upgraded. At boot time I set a flag in static RAM and count boot attempts. If a boot fails the watchdog will reset the system. I cycle through each possible combination of Kernel and Ramdisk [starting with the operational copies and trying each combination 3 times if necessary]. When the system has booted, I start a little task that interrogates the flags set by the bootloader, works out which images it booted from, compares the checksum of the images it booted from with the images it didn't boot from, and if they're different the image we booted from is copied over the image we didn't boot from. So far, I have never had a system fail to boot, despite power interruptions during firmware upgrades and other fun things.
