A bit off topic, but I'll jump in. (The comments are based on experience designing items for myself, and also information from looking at commercial product designs. i.e. hacking things like my TiVo.)
Sam Ravnborg wrote: > Hi all. > > We are developing an application for an embedded target that will be > located in some rural areas. We foresee a need to update the target > with a new version of the application or a new kernel from time to time. > First thing, make sure you have some mechanism for checksuming and possibly signing updates. The first assumption is the update made it over properly if that stuff passes.. (and your company did QA it..) ;) > A few of the added requirements on top of that are: > 1) The target shall boot up in the old kernel, if a bogus kernel is loaded This will require a watchdog timer, and modification to a bootloader to do counting and other items to instruct it to go to the backup kernel. > 2) The target shall boot up in the old application, if a bogus > application is loaded A simple application daemon (init?) can do similar. > 3) On the management side an update shall be handled as a single file, > the target may decide to 'unpack' it when received. > cpio, tar, even RPM have been used for this. These are standard field-upgrade techniques.. the key is that every product is unique. What _I_ personally would do is have two sets of "partitions" (memory, disk doesn't matter) one set for two kernels, current and "updates" and one set for userspace current and "updates". Then you have magic values that tell the bootloader what matches with what. On an initial update, you make this magic value "temporary" until the boot (application run) has succeeded and then you make it perminant. But all in all this will require you to make changes to an existing bootloader or write your own. --Mark ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
