I am working on the OTA update for an embedded system project. You can assume my hardware like Raspberry Pi / Beaglebone and the operating system is a Debian 9.
This OTA update mechanism will be A + B Redundancy update. Where there will be 3 total partitions available. Partition A will have a Debian Operating system and Partition B will have a separate Debian operating system. Partition C will be a persistent partition where I'll be storing all my Configuration which I don't want to change or get affected by an OTA update. There will be one Active and another inactive partition. I'm planning to have 2 Types of the update mechanism. One will be a File Level update and another is an OS level update. *File-level Update:* Now at first Instance let's consider Partition A is an active Partition and Partition B is an inactive partition. Partition C will always be a Persistent partition for configuration and will never be affected by an OTA update. A file level update will be deployed by the server and the hardware will be continuously polling for the update. ( Every 24 hrs possibly ) Once the update is downloaded from the network it will be copied to the inactive partition ( Partition B ) and all the files will be placed in proper directories according to the package configuration and requirement. Now Once the OTA update is done the Boot Priority of the hardware will change ( Here Partition B will become Active Partition ) So that once the user reboots the hardware it will be rebooted into an updated Partition ( In this instance Which will be Partition B ). *OS-level Update:* For OS-Level update, I'll be sending a new version of the operating system as an update to the user. In this update, the Same mechanism will be followed like the File level only a minor difference will be that here the inactive partition will be flashed with the new image of the operating system. Here also U-boot bootloader can help in configuring the Boot Priority Same as above. I am using a Rauc Framework for the OTA update mechanism at the client side. I hope the above explanation gave a clear idea about the mechanism. I have a doubt related to the above mechanism as I am a newbie: *Question:* According to my understanding, the above mechanism will provide a fail-safe update ( Offcourse I need to add some more validations for that purpose ) but I have a doubt related to the mechanism. Is this the right way to provide the OTA Update for Embedded Device? Or is there any other mechanism which is more feasible and scalable than the above one? I would like to have feedback on the above implementation and where I might have gone wrong? Thanks -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/351fa167-30e8-4c67-9f80-6a35c3d5748f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
