Re: online updates of flash card images

On Apr 17, 7:17 am, Vitus Jensen <vi...@xxxxxxxxxxxxxxxx> wrote:
On Fri, 16 Apr 2010, Lee Thalblum wrote:
On Apr 16, 1:17 am, Vitus Jensen <vi...@xxxxxxxxxxxxxxxx> wrote:

On Tue, 13 Apr 2010, Lee Thalblum wrote:
Does anyone have any suggestions for a method of updating flash card
images over a network? I'm using a non-standard distribution of linux,
which uses the syslinux boot. My code image will be about 2 Gig, and I
only have 512M of RAM, so that eliminates running things out of RAM. I
can use a larger CF card, so I'd be able to store a second image as
it's recieved. Any ideas? Thanks.

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

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.

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.


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

Vitus Jensen, Hannover, Germany, Earth, Universe (current)- Hide quoted text -

- Show quoted text -

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