This is an issue I’ve already briefly discussed with @dfrey. In essence, the app supervisor fails to grant the
spiService access to the required
/dev/spidev0.0 path. I believe this occurs when the supervisor starts before the required
spidev kernel module is loaded (we load this module at boot by appending
/etc/modules). I’ll post some logs that show this behaviour a little later today when I’m at the office.
Oddly enough, this only seems to occur on one of our 5 units. Additionally, this issue can be “solved” by running the
spiService outside of a sandbox by modifying
spiService.adef in the Legato source and then re-compiling. Obviously this is not ideal as it requires forking from the main Legato releases and compromises some security on the target device.
I’ve seen lots of discussion on here about the
spiService failing to start on boot despite the app definition specifying
start: auto without a conclusive root cause or solution. I believe this is the root cause based on what I’ve seen. In terms of solving this, would it be plausible to ensure all kernel modules are loaded before the supervisor is allowed to start?
If any additional information would be helpful for debugging, please let me know and I’ll provide it.
Any help is greatly appreciated.