in situ MTD upgrade from userspace (kernel, CRAMFS, YAFFS)
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
Quoted 4 lines
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?
Quoted 10 lines · David Wuertele
Quoted 4 lines
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