online updates of flash card images

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

Translate This Thread From English to

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

Re: online updates of flash card images
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/13/2010 10:42 PM, Lee Thalblum wrote:
Quoted text here. Click to load it
I think you can build a "backup image" which your device can boot in, and this
image is only responsible for connecting to the network, downloading and
flashing the new "main image" and rebooting into the main image. The tricky part
is to set some flags in your bootloader so that it boots into the correct image.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org /

iEYEARECAAYFAkvFbnQACgkQyjWa9oynuqAFCACgivR6e7d1FsCts0b4tUa4X0Eb
pSkAoJerEqq9eKsU4bClSUW0p1S+Gcu4
=2LYz
-----END PGP SIGNATURE-----

Re: online updates of flash card images
Quoted text here. Click to load it

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.

Re: online updates of flash card images
Quoted text here. Click to load it

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

Re: online updates of flash card images
Quoted text here. Click to load it

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.

Re: online updates of flash card images
Hej!


Quoted text here. Click to load it

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

--
Vitus Jensen, Hannover, Germany, Earth, Universe (current)

Re: online updates of flash card images
Quoted text here. Click to load it

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

Re: online updates of flash card images

Quoted text here. Click to load it

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.

--
Vitus Jensen, Hannover, Germany, Earth, Universe (current)

Re: online updates of flash card images
Quoted text here. Click to load it

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

Re: online updates of flash card images
Quoted text here. Click to load it

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.

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

Ryan

Re: online updates of flash card images
Quoted text here. Click to load it

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

Site Timeline