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
unipi-firmware6 (pool: main/u/unipi-firmware6)
unipi-firmware-tools (pool: main/u/unipi-tools)
unipi-modbus-tools (pool: main/u/unipi-tools)
unipi-os-configurator (pool: main/u/unipi-os-configurator/)
unipi-os-configurator-data (pool: neuron-main/u/unipi-os-configurator-data/)
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
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/i2c-* work on the host and all should be good.
My questions are as follows:
- Is the deviceTree still being used? ie. are the
unipi-os-configurator-data still being used or is the functionality done by the kernel modules?
- I've found that I should load
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.