Re: Firmware upgrade technique

From: Ken Lee (postmaster_at_noname.com)
Date: 01/21/04


Date: Wed, 21 Jan 2004 02:38:22 GMT

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



Relevant Pages

  • Re: Field Updates of Windows CE
    ... I'd say, if you have the space on the card, yes, 1) rename old nk.bin ... that Windows Mobile actually does nk.bin replacements via the bootloader, ... many, if not all, of the Windows CE integration companies have bootloaders ... and flash copy, which is a BIG job, to my way of thinking. ...
    (microsoft.public.windowsce.embedded)
  • Re: Field Updates of Windows CE
    ... because you need both the SD card driver and the FATFS support. ... Interesting recommendation on not using eboot, but a different bootloader ... many, if not all, of the Windows CE integration companies have bootloaders ... and flash copy, which is a BIG job, to my way of thinking. ...
    (microsoft.public.windowsce.embedded)
  • Re: Nand Flash Data Lost
    ... While you mentioned not only registry but also the files are lost after reboot and the bootloader did not repartition your flash, it is believe the OS wipes the Flash. ... Have you tried to build a Image only mount the NAND as an ordinal external storage but not for storing Hive nor mounting as root file-system and to see if files still lost after rebooting? ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Field Updates of Windows CE
    ... I'm facing the same update problem on a WinCE 6.0 based device. ... I've also seen mentioned the Image Update capability that is in Windows ... FATFS into the bootloader. ... and flash copy, which is a BIG job, to my way of thinking. ...
    (microsoft.public.windowsce.embedded)
  • Re: Bootloader Placement
    ... which, firstly copies all code and data from flash to RAM and then checks data on an MMC card to see whether an update of the flash is necessary and, if so, copies new program data into the flash. ... At the moment I have two projects - the bootloader as a stand-alone loader and the full application, which has the bootloader code as part of it. ... What I'd like to do is seperate the bootloader code from the application code and have the boot loader pass control to the application once it has done its checks and, if necessary, reprogramming. ... My thoughts were to define the first flash sector as a seperate linker section and locate all the bootloader functions and data in there but as part of the application software. ...
    (comp.arch.embedded)