I’ve figured out how I can create a service using systemd to automatically start my application when the unit boots up by manually executing a systemctl command to set it up to do so. While this is ok in a development environment, doing this manually on units that have already been shipped to customers won’t work for us.
Here’s a quick overview of our architecture. The imx6 is being used for a Local Operator Interface for an instrument. The only connection this module has with the “outside world” is a private TCP/IP connection with the instrument. When we need to upgrade the firmware, whether the bootloader, kernel, file system, Qt libraries, or our application, our PC software sends the file(s) to the instrument, which in turn will FTP them to the imx6. On the imx6, we’ll be running a separate upgrade task that looks for and processes these updates.
It looks like everything should work well enough for upgrading our application and/or the Qt libraries. However, my concern is when we have to upgrade things like the kernel and/or file system. I’m guessing that when one or both of the above are replaced with new versions, the service we initially set up using systemctl in the factory will no longer be recognized, maintained, saved, or whatever the appropriate verbiage would be. In other words, after such an upgrade, the imx6 would start up WITHOUT running our application. Assuming this is correct, how can I get around it? Having the customer disassemble the LOI, hook up additional hardware, and manually go in and try to run systemctl is obviously not an acceptable answer. It’s equally unacceptable to send out a field service tech to do it or to replace the SoM. Is there some way to reconfigure systemd such that this would be integrated into it? Or would I need to make modifications to the kernel itself in order to facilitate this?
Thanks in advance to anyone who can point me in the right direction.