Firmware upgrade technique

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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.

Re: Firmware upgrade technique
snipped-for-privacy@tait.co.nz (Dmytro Bablinyuk) wrote in message

Quoted text here. Click to load it


[...]

Quoted text here. Click to load it

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.
We've slightly trimmed the long signature. Click to see the full one.
Re: Firmware upgrade technique
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


snipped-for-privacy@tait.co.nz (Dmytro Bablinyuk) wrote in message
Quoted text here. Click to load it

Re: Firmware upgrade technique
On 18 Jan 2004 22:37:03 -0800, snipped-for-privacy@tait.co.nz (Dmytro

Quoted text here. Click to load it

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

Re: Firmware upgrade technique
Quoted text here. Click to load it



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.



Site Timeline