Hardware mappings on a non-debian distro

tsandrini

Hi everyone!

So the context is that I am trying to run EVOK on an UniPi Neuron S103 device running non-debian based (64bit aarch64 for the rpi4) GNU/Linux distribution and I should disclaim that I am not expecting anyone to solve these issues for me magically since it's a non standard thing, but rather I wanted to ask about some inner workings of the hardware mappings.

The outline of my strategy is that I am relying on the debian repo and its packages (https://repo.unipi.technology/debian/, thanks again <3), extracting them and manually setting/linking the pieces together. So far I've done this for

a. unipi-firmware6 (pool: main/u/unipi-firmware6)
b. unipi-firmware-tools (pool: main/u/unipi-tools)
c. unipi-modbus-tools (pool: main/u/unipi-tools)
d. unipi-os-configurator (pool: main/u/unipi-os-configurator/)
e. unipi-os-configurator-data (pool: neuron-main/u/unipi-os-configurator-data/)
f. unipi-kernel-modules -- for these I couldn't work out some exec format errors (possibly some differences in kernel specs?) so I decided to build them from source (https://github.com/UniPiTechnology/unipi-kernel-modules), modprobing all of them works as expected.

then, of course, the EVOK specifics, however, since I am first trying to just run the hardware mappings (and also for me specifically the application layer is way easier to work with), I have a privileged s6 debian-based docker container running unipi_tcp_server, nginx and evok (I have already tested this on a clean debian installation that this works, so the gist of this is that I just need to make these /dev/unipichannel1, /dev/i2c-* work on the host and all should be good.

My questions are as follows:

Is the deviceTree still being used? ie. are the /boot/overlays/ from unipi-os-configurator-data still being used or is the functionality done by the kernel modules?
I've found that I should load i2c-bcm2835, rtc-unipi, at24, i2c-dev into initramfs, which I've done, but what about other modules? Should I also load other kernel modules, or is this done entirely by the udev rules?
And the most important one, where does the /dev/unipichannel* device socket come from? Running EVOK and the modbus server seems to rely on it, I can't even flash the firmware, ie fwspi -v --auto without it, but loading the kernel modules and udev rules doesn't seem to produce it (or am I missing something?)

That's all and as I said, I don't expect anyone to solve these issues for me but I'd be glad if I could just get some insight into the workings of the hardware mappings and the rest I'll figure out myself.

Thank you all in advance <3.

TS.

martin_triska

Hello @tsandrini ,

first of all, we appreciate your effort which confirms us the open-source approach is the best way :-).

To your question:

Yes, you have to apply the appropriate overlay(s) to the "base" device-tree in order to tell the unipi kernel modules what kind of hardware (I/O boards) is present. Every model of the PLC (e.g. S103, L523, ...) has a separate overlay located in the package unipi-os-configurator-data. In a standard OS Image, this stuff is invoked automatically by unipi-os-configurator based on the identification stored in the internal EEPROM (and accessible via unipi-id module - see /run/unipi-plc/unipi-id, this module should be preset on all our units). Typically, this process needs two reboots - after the first of them only unipi-id is loaded in order to get the PLC model and apply the right overlay. After the next reboot, the previously selected overlay is loaded and all of the peripherals (inc. /dev/unipichannel*) should be available.
Anwer is in the previous text - appropriate driver(s) for Unipi-specific hardware are loaded automatically based on the devicetree (devicetree overlay) nodes.
Yes, the /dev/unipichannel* represents the main communication channel between the Linux and I/O boards (the second one is sysfs). This kind of device is created dynamically by the Unipi kernel modules based on values given in devicetree overlays. It is used by unipitcp as well as by the firmware upgrade tool.

Has this answer got you forward?

tsandrini

@martin_triska Thanks a lot!

I had to do some debugging due to incompatible base source deviceTree (which was ultimately resolved by patching the compatible directives and a bit of merging together), but your response helped a ton!

It works like a charm, so again, thanks! We plan to open source parts of the project in the future as well (along with a stable release) ... so hopefully it will help someone else too :)