"Hot" updating root-mounted mtd partitions

"Hot" updating root-mounted mtd partitions

[Felix Domke]

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

"Hot" updating root-mounted mtd partitions

[Henrik Nordstrom]

On Wednesday 26 February 2003 00.51, Felix Domke wrote:

> 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?

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.

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

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

"Hot" updating root-mounted mtd partitions

[Jasmine Strong]

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.