Re: Firmware upgrade technique
From: Ken Lee (postmaster_at_noname.com)
Date: Wed, 21 Jan 2004 02:38:22 GMT
On 18 Jan 2004 22:37:03 -0800, firstname.lastname@example.org (Dmytro
>I am working on a firmware upgrade/downgrade procedure for our
>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
>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
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.
I hate junk email. Please direct any
genuine email to: kenlee at hotpop.com