> This would mean that when an > update is done you end up with one partition that has the latest > software and one partition that has the previous version of the > software.
Exactly. You always have one partition that is guaranteed to work. > Only issue is the space required for the additional partition. Since your rootfs is read-only, you can use cramfs or squashfs, so your firmware fits on a postage stamp. You don't need to store an uncompressed version of your rootfs, ever. (Except in RAM cache, of course, but that's totally transparent.) > From you response to Micheal's query, i understand that the platform > should allow to specify which partition to boot from. In other words > we should > 1. be able to update the the kernel boot arguments > 2. platform should probably have the ability to accept some sort of > argument that tells it to boot using another set of boot args in case > the main one fails. Yes, updating bootloader information is required, but you only need to store two bits of information: - what partition you should be booting on - whether you are testing an update Your bootloader code should get this information from your nvram, and do its thing accordingly. > Is that correct. In my system i can update the kernel boot args. But i > believe that if the mounting of the root partition fails then the > kernel will panic. You can do some basic tests before rebooting, including whether the mounting works (mount /dev/something /mnt/test) and whether the new firmware looks like something you actually made (chroot /mnt/test /bin/true && /bin/verify /mnt/test/somepublickey) If all else fails, you should have a hardware watchdog that reboots the device when the kernel's gone fishing, and your bootloader will then fall back on the old rootfs. -- Laurent _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
