online updates of flash card images

The system will already be running a complete image to start with. I'll have to download a new image and store it in a different area of flash, then reboot and have the system run the new image. At least that's how I envision things at the moment. I'm looking for any ideas to fill in the specifics, or problems with my approach.

You will need support in the bootloader for that! Otherwise there is no guarantee that the new image is not corrupted and if you reboot into it the system may become completely unusable. The approach I've used is to modify the bootloader to use two partitions (or sets of partitions) - one for the active (working) image and one for the update. When update is triggered a flag for the bootloader is set saying that an update is made. On the nex boot the bootloader checksums the new partition set and if it's correct sets it to be active and boots. Otherwise it clear the update flag (or sets it to an error code) and boots the old image. When an image is booted it chechs the bootloader flag for errors and sends a message to the backend (that initiates the updates) that the update falied (if the flag is set to an error)

regards, Alexander Popov

I've been having discussions with the bootloader mailing list (syslinux) and I seem to be coming to the same conclusion. There are a number of approaches that have been suggested.

Use 2 partitions on your CF (1: active rootfs, 2: download area) and switch to a second, small rootfs to do the actual update. The small rootfs only has to contain the neccessary tools to do the update (mkfs, tar, gz or nandwrite in case of internal flash) and may reside in RAM. You can keep a tar.gz for the small rootfs or build it from things available on the old rootfs.

Download image to 2 Shutdown services, change runlevel Construct a rootfs in RAM, chroot Unmount/clear old rootfs, copy image to rootfs Sync, reboot

Vitus

That's similar to what I'm considering, but I'm thinking along the lines of keeping the bootloader in a separate partition, and then keeping the current and updated copies of the flash image in separate paritions. The bootloader config file can be modified to tell it where to boot from when the new image is received and validated.

Lee

Ah, you want to fall back to the old version if the new one isn't working correctly? Do you have means to define "working correctly"? One way to do it is to let the new version connect to some host after startup and let the host do the permanent switching. This way you can be pretty sure that you will always have a working host-device connection.

If your bootloader doesn't support this kind of switching you may involve an initramfs (cpio.gz loaded into a ramfs) and start that first. This would be an all-linux solution.

Vitus

PS: in embedded devices I know about the bootloader is always in a seperate partition.

to

hat

ext -

By correctly I meant the new image checksum and header info has been validated (we'll have our own header layout to assure the data actually comes from us). Once it starts running the bootloader doesn't really have any way to assure it's doing what it's supposed to.

Lee

ux,

d I

. I

ll

fs,

M.

ng

ay to

let

that

ve

text -

Hey. We have been tackling the same challenge and came up with 2 solutions.

1. Use initramfs and link fs, disk driver, etc. statically. When the boot process reaches the rcS level, check for the new fs file root.tar.gz. If the file exists, rm existings fs and copy/extract the new one. Since the initramfs is in RAM, you have not chroot'd to the mounted the rootfs yet. This will not use the bootloader at all. Once the new fs has been written, remove the root.tar.gz file, and reboot.

1. Use kexec. This needs to be investigated more, but it a pretty cool solution.

Ryan

ard

inux,

and I

AM. I

as

nd

mall

mkfs,

RAM.

te

king

way to

d let

re that

olve

his

ed text -

I suppose I could check if there's a new image and copy it over the old image. I'm not sure what that would get me besides not having to check what partition to use on boot. My image isn't going to be tar's, so there's no extraction process. I'm still leaning towards having the bootloader make the decision. It will give the option of reverting back to the original image if it's needed.

Lee