"Hot" updating root-mounted mtd partitions

Hi,

i'm using MTD on a Linux Set-Top-Box, and i like to upgrade the (cramfs) root FS, which is on a mtd, while the device is running.

Of course updating it (be it from internet, from satellite or whatever) includes erasing and rewriting the root. This naturally causes troubles. How can i avoid this?

Possibilities are:
- remount rootfs using an in-memory-copy (ramfs), but i don't think
this is possible, since there are many open files in the old fs.
- including ugly hacks in the flash driver, mainly by copying the
partition to RAM and redirect accesses to that backup while flashing the rootfs

both possibilities suck.

I tried the following: (with proper error checking, of course)

p=mmap(0, size, PROT_READ, MAP_SHARED|MAP_LOCKED,
open("/dev/mtdblock/0"), 0);

to map the BLOCK(!)device mtdblock0 in memory. as block accesses are chached, i thought, this should prevent them to go out of cache (=ram).

to enforce them to go into ram, i used

for (i=0; i<size; i+=PAGE_SIZE) (void)p[i];

Well, actually, it did help, but it's still not perfect. Sometimes the application crashes with a busfault after erasing the root.

My question: is it possible to do that this way? If not - why not?

I know that the application might reload data of a.) itself or b.) used fonts (it's a graphical application, based for example on freetype+ttf fonts), so i cannot simple remove the root.

Is such a mmap "strong enough" ?

What else can i do? How is this normally done? Having a 2nd system in flash is no choice.

felix

Have the system load the filesystem into ram at startup, and run from there.. can very easily by done by loading the root as an initrd.. this obviously assumes your root is relatively small.

or have two partitions, and only update the one not currently running and then update the boot loader nvram to load the "other" image after a successful upgrade.

Of these, a devise layer hack sounds most appealing, but you should also consider what happens on partial upgrades etc..

You might actually be able to pivot_root into a ram based rootfs while upgrading, but almost certainly involves a near complete shutdown to terminate all applications before the actual upgrade starts..

Regards
Henrik

On Wednesday, Feb 26, 2003, at 00:31 Europe/London, Henrik Nordstrom wrote:

[trials and tribulations]

The way I have solved this problem in the past is to make the update actually
happen during the reboot.

This is a bit more 'feely' than just replacing the Flash contents with a new
image file but it leaves more wiggle room when things go wrong.

This is what you do:

1) Download the update, a file at a time, so that all the non-conflicting or
non-critical files are already in their final locations. Obviously
all the
non-essential processes are halted before this happens. Checksum all the downloaded files so that you are sure they are good.

2) Download the new kernel. It can replace the old one, unless you do kernel XIP, which would be unlikely in a modern STB (they're mostly NAND based for cost reasons.)

3) Download a system updater binary. Set the bootloader to run the updater binary on init and to use the new kernel. Download the files to replace the open binaries and libraries into a temporary place.

4) Put 'Please wait' on your LCD :-) Garbage collect the flash and sync; sync; reboot the box.

...At this point the box reboots, the bootloader starts the new kernel and
the new kernel runs the updater binary. The updater binary moves the libraries and so forth into place, changes the bootloader configuration to
normal (whatever that is :-) and triggers a second reboot.

If anything goes wrong the updater binary is still running; the flash has
never been completely wiped clean so the box has never been in that 'if you power down you have a beige brick' situation.

Jas.