Retrieve PLC coprocessor board status programmatically

romainletendart

Hi,

We are currently interested in getting coprocessor board statuses to check that the underlying hardware is still working as expected. For instance, we would like to know if all the coprocessor boards are up and running and/or all their I/Os are also functioning.

Currently, we are relying on:

/sys/devices/platform/unipi_plc/io_group[1-3]

What we successfully checked so far is that unplugging a coprocessor board made its corresponding /sys/devices/platform/unipi_plc/io_group[1-3] vanish from the sysfs tree. However, if we only unplug the relay board from its coprocessor board, the relays still appear in the sysfs tree and can still be read from/written into.

Are there any ways to check that relays (or any other kinds of I/Os) are actually plugged in and physically up and running?
I saw there are logs in dmesg that tell when a given board is not plugged in e.g. "[ 8.312951] UNIPISPI: Probe did not detect a valid UniPi device at CS3". Can we get this information elsewhere (e.g. through sysfs) or do we have to parse dmesg?
What is the meaning of the status we get in /sys/devices/platform/unipi_plc/io_group2/driver/spi0.2/of_node/status? What would "okay" mean exactly?
sysfs-platform-unipi.txt tells us that accessing some files from sysfs "Returns an error if no valid combination corresponding to a UniPi device can be found" in some cases. What kind of error would that be?

In advance, thank you.

martin_triska

Hello @romainletendart ,

as the first point, let me briefly describe the device architecture:

Every Neuron device consists of one, two or three coprocessor boards. In the device-tree overlay, the full three-boards configuration is always supposed.
During the driver-load phase (probe), the driver tries to contact all three boards (messages in the syslog come from this phase). In case of success, the driver creates the sysfs structure for every responding board (called io_groupX).
This routine is invoked at driver load only - ie. at the boot time.

To your questions:

There is no way how to check the presence of a non-coprocessor board. These boards are just simple I/Os without any "intelligence".
In case a co-processor board does not present at the boot time, no sysfs structure is created for this io_group.
This status is a link to the currently loaded device tree. As mentioned above, all three boards are still active there, so you always read the "okay" string.
In case the board is not found during the boot phase, no sysfs structure is created.

Maybe standard Linux SPI subsystem statistics can be useful for you, e.g.:

/sys/devices/platform/unipi_plc/io_group1/driver/spi0.1/statistics

If you provide more details about your application, I can try to give you some more specific tips.