[SOLVED] Questions about firmware upgrade

Hi everyone,

I'm currently trying to figure out the best way to implement a complete firmware upgrade of my device.
Here is the system's layout :

Bootloader : U-Boot
Linux kernel 2.6-27
ROOTFS : CRAMFS for RO data and JFFS2 for RW data
The User application is running inside Linux.

These filesystems are stored into a 64 MBytes NAND flash memory and run on a 16MBytes SDRAM.

By complete firmware upgrade, I mean : Linux kernel, the ROOTFS and the user application.

I am already able to download the new firmware through Bluetooth communication, but I am wondering what could be the best way to perform the upgrade : my main difficulty is to store the new firmware somewhere and to pass its address to U-Boot.
(I already perform the "user application" upgrade, but it just consists in copying files with linux)

Two solutions came up :
1- to create a RAMDISK just when I have to perform an upgrade
Pros : quick and easy to do
Cons : will have to reboot the system in order to free as much RAM as possible before creating the RAMDISK)

2- to create a new filesystem (JFFS2) dedicated to firmware upgrade (this filesystem would not be upgraded during this process) :
Pros :
The firmware is still stored even if the power supply is lost

Cons : I will have to verify that the stored file is not fragmented
I will have to retrieve the file address in flash memory and set U-boot environment variables
I will have to pay attention to bad blocks (linux is already configured to share the bad blocks table with U-boot).
I will have to be sure that the stored file is not fragmented.


I am not looking here for a complete solution. All I want to know is if you have already done that type of development and if you have some tips and tricks to give me.

Thanks a lot for your advises

Best regards,

François

I've handled some of the worst applications of this nature. Hows about:
Bafore you package your upgrade, run 'touch /upgrade' Then use your option

2. The new jffs filesystem which you can then point the bootloader to? Then add in a step to check if this is an upgrade in the rc scripts
if ( -f /upgrade ) ; do

If it's an upgrade, you clear filesystem 1, copy filesystem 2 over filesystem 1, fix the bootloader, and as a last step remove /upgrade & clear filesystem 2 & reboot.

At any stage, a power loss is not destructive :-D.

Thanks for the reply !

In fact, after posting this question I found some helpful documentation about installing an U-boot image using linux :
http://www.denx.de/wiki/publish/DULG/DULG-tqm8xxl.html
part 5.4.4. Installation using Linux

It consists in erasing mtd partitions contents and replacing them by new binary files
Here is my mtd organization :
/ # cat /proc/mtd
dev: size erasesize name
mtd0: 00100000 00004000 "Bootstrap"
mtd1: 00500000 00004000 "kernel"
mtd2: 01000000 00004000 "rfs-ro"
mtd3: 02a00000 00004000 "rfs-rw"

Here is what I did to replace the kernel binary by a new one

/ # flash_eraseall /dev/mtd1
/ # dd if=/rw/disk/uImage_of_new_kernel of=/dev/mtd1 bs=16k conv=sync

The only thing I did not figured out yet is how to make my fw_printenv fw_setenv working properly (in order to modify the bootcmd, updating the kernel size).

Right now, when I call these fw_printenv or fw_setenv commands, all I get is :
/ # fw_printenv
/bin/sh: fw_printenv: not found

these commands are in the /usr/sbin directory
my fw_env.config file contains :
# Configuration file for fw_(printenv/saveenv) utility.
# Up to two entries are valid, in this case the redundand
# environment sector is assumed present.
# MTD device name Device offset Env. size Flash sector size
/dev/mtd0 0x0000 0x4000 0x4000


(I also tested this file with the real environment variable offset : 0xa0000 (0x0000 is the address where U-boot is written)

I don't know what I am doing wrong ?

Any idea ?

Thanks a lot !

Best regards,

François

That sounds like it's doing a wipe, and then write, leaving you vulnerable to a well timed power failure. Don't know the tools you mention - I know hardware.

I must admit that The system is vulnerable during a few seconds to a power failure. However I don't see any method to upgrade that is not vulnerable to a power failure at a certain point of the upgrade process.
Do you have any clue about this ?

I am also thinking about another way to upgrade the kernel and filesystems if the first method failed. Using U-boot : downloading and installing a new firmware through USB connection.
At this point (and because it is not the only feature I have to develop), I just saw that it was possible to perform this easily by plugging a USB flash drive but not more.

Look at what I laid out in post #2.
You install a new system side by side, point the bootloader at it. It stays until you have replaced your initial filesystem; the last thing you do is correct the bootloader.

Okay !

Understood !
I will work on that.
Thanks a lot

Best regards,

François