Posts made by tsandrini

@cleve Hi, thanks for the reply. Can you elaborate further on your answer? I don't really understand how I am mixing the versions. As I stated, this is a custom OS and we cannot really directly use your images and debian packages, instead we are repackaging them using your debian pkgs repository, which has worked very well. I am just confused about some configuration details (those are highlited in my previous message) regarding your new EVOK (that is the bookworm versions based on the dev-bookworm git branch) version, since you've migrated to a completely new configuration style and EVOK API.

Aside from that everything works perfectly fine as I've stated in my previous message.

Thanks again for the reply.

Hi again!

Context: We've been successfully running UniPi software on a custom OS on UniPi S130 rpi4 thanks to https://repo.unipi.technology/ and the help provided in https://forum.unipi.technology/topic/1541/hardware-mappings-on-a-non-debian-distro . However, partly due to maintenance and partly due to some other DTOs, we've recently decided to upgrade to the new major kernel version, which unfortunately brought some differences in iio/iio_opaque structs in the linux kernel, which made the unipi-kernel-modules unable to work with the new kernel, which then spiraled into additional incompatibilities. We've managed to resolve most of them using your bookworm package versions (thanks again!) and a bit of patching on the side of the kernel-modules, the os-configurator and evok. iio, spidev, /dev/unipichannel1, unipi_tcp_server is all working without any issues, however, the old version of EVOK (that is, master branch) unfortunately didn't work with the new package versions so we switched to the dev-bookworm branch, which looks like a superb, way cleaner (+tests?) rewrite of the old python2 version and is working mostly okay aside from AI,AO,DOs and some minor configurations.

Regarding those:

1. Both the repository and the evok_3.0.1-beta package are missing hw_definitions. The definitions are however inside evok-data_0.0.1-test, but a lof of them are missing. Q: Is this intentional? The old hw_definitions/BuiltIn/S103.yaml works for the ULED outputs, however, the rest is mostly missing. I tried patching the modes (according to the new config scheme) of AI,DI but haven't had any success.
2. We've put together the following /etc/evok/config.yaml (omitting the trivial apis). The model refers to the old hw_definitions/S103.yaml. Q: Is this an appropriate config.yaml for a Neuron S103 rpi4?

comm_channels:
  EXT_TCP:
    hostname: 127.0.0.1
    port: 502
    type: MODBUSTCP
    device_info:
      family: Neuron
      model: S103
      board_count: 1
    devices:
      1:
        slave-id: 1
        model: S103
  OWFS:
    type: OWBUS
    interval: 3
    scan_interval: 60
    owpower: 1

Any help would be greatly appreciated and also thanks for the great work that you are doing on EVOK. <3.

TS.

@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 :)

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:

1. 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?
2. 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?
3. 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.