in situ MTD upgrade from userspace (kernel, CRAMFS, YAFFS)

in situ MTD upgrade from userspace (kernel, CRAMFS, YAFFS)

[David Wuertele]

In my embedded system, I have previously been using the boot loader to
upgrade software (linux kernel, CRAMFS partition, YAFFS partition).
Now I want to add the feature of upgrading these partitions from
userspace so that this process can be controlled remotely.

I have two questions:

1.  There are many other processes running at the time of the upgrade.
    They are running out of CRAMFS.  As I overwrite the CRAMFS
    partition, is it possible that my write could get corrupted?
    Perhaps by crashing programs that inadvertently do weird syscalls?

2.  To simplify the write, I created a fourth partition that covers
    the whole MTD device.  That way, my program doesn't have to break
    the upgrade image up into different partitions.  Is there any
    problem with such an overlapping partition?

  static struct mtd_partition partition_info[] = {
          { name: "MTD NAND Boot partition",
            offset: 0,
            size: NAND_KERNEL_FS_SIZE},
          { name: "MTD NAND partition 1 - ROOT FS(cramfs)",
            offset: NAND_KERNEL_FS_SIZE,
            size: NAND_ROOT_FS_SIZE},
          { name: "MTD NAND partition 2 - usr fs (yaffs)",
            offset: NAND_ROOT_FS_SIZE+NAND_KERNEL_FS_SIZE,
            size: NAND_HOME_FS_SIZE },
          { name: "NAND part 3 - all parititions rewrite alias",
            offset: 0,
            size: NAND_TOTAL_SIZE }
  };

Thanks,
Dave

Re: in situ MTD upgrade from userspace (kernel, CRAMFS, YAFFS)

[David Wuertele]

> 1.  There are many other processes running at the time of the upgrade.
>     They are running out of CRAMFS.  As I overwrite the CRAMFS
>     partition, is it possible that my write could get corrupted?
>     Perhaps by crashing programs that inadvertently do weird syscalls?

Corollary question:

  As my own userspace process overwrites the CRAMFS block that
  contains that process's program, how can I ensure that the process
  doesn't get hosed until after it has a chance to reboot the system?

Re: in situ MTD upgrade from userspace (kernel, CRAMFS, YAFFS)

[Josh Boyer]

On Fri, 2004-11-05 at 16:59, David Wuertele wrote:
> > 1.  There are many other processes running at the time of the upgrade.
> >     They are running out of CRAMFS.  As I overwrite the CRAMFS
> >     partition, is it possible that my write could get corrupted?
> >     Perhaps by crashing programs that inadvertently do weird syscalls?
> 
> Corollary question:
> 
>   As my own userspace process overwrites the CRAMFS block that
>   contains that process's program, how can I ensure that the process
>   doesn't get hosed until after it has a chance to reboot the system?

Copy it and all it's needed shared libraries (including libc) into a
tmpfs and start it from there.

If you don't do that, then cramfs gets mighty confused if it needs to
read a text page of your app and thing have changed underneath it.

josh