• Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    1. Home
    2. Achilleas Kotsis
    A
    • Profile
    • Following 0
    • Followers 0
    • Topics 5
    • Posts 16
    • Best 1
    • Controversial 0
    • Groups 0

    Achilleas Kotsis

    @Achilleas Kotsis

    1
    Reputation
    111
    Profile views
    16
    Posts
    0
    Followers
    0
    Following
    Joined Last Online

    Achilleas Kotsis Unfollow Follow

    Best posts made by Achilleas Kotsis

    • unipi-kernel-modules-dkms 1.108 breaks the system on kernel 5.10.103-v7+

      Hello,

      I upgraded unipi-kernel-modules-dkms to v 1.108 and my system broke with the latest default raspbian os kernel 5.10.103

      If the package is incompatible with kernels < 5.13 as I am guessing, you should at least add a "Conflicts" or "Requires" version on the package.

      Reverting to 1.106 seems to resolve the issue.

      [Thu Apr  7 15:52:47 2022] UNIPISPI: SPI CRC2 Not Correct: 01c4 COMPUTED: d2ee
      [Thu Apr  7 15:52:47 2022] UNIPISPI: len=68, part1=fa:00:55:0e part2=00:00:00:00:00:00:00:00:00:00:04:04:20:03:00:00
      [Thu Apr  7 15:52:47 2022] UNIPISPI: SPI CRC2 Not Correct: 6803 COMPUTED: d813
      [Thu Apr  7 15:52:47 2022] UNIPISPI: len=6, part1=fa:00:55:0e part2=00:00:00:04:40:00:03:68:00:00:04:04:20:03:00:00
      [Thu Apr  7 15:52:47 2022] UNIPISPI: SPI CRC1 Not Correct (Received: 0000 Calculated: fe62)
      [Thu Apr  7 15:52:47 2022] UNIPISPI: part1 47:d8:00:00
      [Thu Apr  7 15:52:47 2022] UNIPISPI: SPI CRC2 Not Correct: 0000 COMPUTED: fa95
      [Thu Apr  7 15:52:47 2022] UNIPISPI: len=6, part1=fa:00:55:0e part2=00:00:00:01:01:10:00:00:00:00:04:04:20:03:00:00
      [Thu Apr  7 15:52:47 2022] UNIPISPI: SPI CRC1 Not Correct (Received: 0000 Calculated: 2c31)
      [Thu Apr  7 15:52:47 2022] UNIPISPI: part1 da:01:d4:78
      [Thu Apr  7 15:52:47 2022] UNIPISPI: SPI CRC2 Not Correct: 2002 COMPUTED: 8293
      [Thu Apr  7 15:52:47 2022] UNIPISPI: len=6, part1=fa:00:55:0e part2=00:00:00:00:00:02:02:20:11:03:10:00:10:00:63:88
      [Thu Apr  7 15:52:47 2022] UNIPISPI: SPI CRC1 Not Correct (Received: 04cb Calculated: 6980)
      [Thu Apr  7 15:52:47 2022] UNIPISPI: part1 00:0f:00:31
      [Thu Apr  7 15:52:47 2022] UNIPISPI: SPI CRC2 Not Correct: 8000 COMPUTED: 4113
      [Thu Apr  7 15:52:47 2022] UNIPISPI: len=6, part1=fa:00:55:0e part2=00:00:00:00:00:22:00:80:11:03:10:00:10:00:63:88
      [Thu Apr  7 15:52:48 2022] UNIPISPI: SPI CRC2 Not Correct: 00fa COMPUTED: 0d92
      [Thu Apr  7 15:52:48 2022] UNIPISPI: len=6, part1=fa:00:55:0e part2=00:00:00:00:40:41:fa:00:00:00:04:04:20:03:00:00
      [Thu Apr  7 15:52:48 2022] UNIPISPI: SPI CRC1 Not Correct (Received: e8e8 Calculated: 34c2)
      [Thu Apr  7 15:52:48 2022] UNIPISPI: part1 00:02:20:fa
      [Thu Apr  7 15:52:48 2022] UNIPISPI: SPI CRC2 Not Correct: 06d0 COMPUTED: 871f
      [Thu Apr  7 15:52:48 2022] UNIPISPI: len=6, part1=fa:00:55:0e part2=00:00:00:02:02:0f:d0:06:00:00:04:04:20:03:00:00
      [Thu Apr  7 15:52:48 2022] UNIPISPI: SPI CRC2 Not Correct: 0820 COMPUTED: ded2
      [Thu Apr  7 15:52:48 2022] UNIPISPI: len=68, part1=fa:00:55:0e part2=00:00:00:00:00:00:00:00:00:00:20:21:00:18:00:00
      [Thu Apr  7 15:52:48 2022] UNIPISPI: SPI CRC1 Not Correct (Received: 0000 Calculated: 0358)
      [Thu Apr  7 15:52:48 2022] UNIPISPI: part1 0e:00:00:00
      [Thu Apr  7 15:52:48 2022] UNIPISPI: SPI CRC2 Not Correct: 8018 COMPUTED: 51e9
      [Thu Apr  7 15:52:48 2022] UNIPISPI: len=68, part1=fa:00:55:0e part2=00:00:00:00:00:00:00:00:00:00:00:80:84:00:60:00```
      posted in Official EVOK API
      A
      Achilleas Kotsis

    Latest posts made by Achilleas Kotsis

    • RE: unipi-kernel-modules-dkms depends on non-existent package unipi-os-configurator-data

      I see now that these are included in neuron-main tree, but it was never installed on my rpi because the install script failed.

      The following packages have unmet dependencies:
       unipi-kernel-modules : Depends: raspberrypi-kernel (= 1:1.20221104-1) but 1:1.20230106-1 is to be installed
      E: Unable to correct problems, you have held broken packages.
      Cleaning temporary files
      Cleaning temporary files
      

      I am guessing you need a better way of determining the platform, otherwise this is going to break each time a new rpi kernel is released before you have a chance to build the modules package...

      If anyone needs a workaround, install like this:

      wget -qO - https://repo.unipi.technology/debian/raspberry-install.sh | sed s/unipi-kernel-modules/unipi-kernel-modules-dkms/ | bash
      
      posted in Official EVOK API
      A
      Achilleas Kotsis
    • unipi-kernel-modules-dkms depends on non-existent package unipi-os-configurator-data
      Package: unipi-kernel-modules-dkms
      Priority: optional
      Section: kernel
      Installed-Size: 373
      Maintainer: Miroslav Ondra <info@unipi.technology>
      Architecture: all
      Source: unipi-kernel-modules
      Version: 2.20~bullseye
      Replaces: neuron-kernel, unipi-kernel-modules
      Depends: dkms (>= 2.1.0.0), raspberrypi-kernel-headers | unipi-kernel-headers, unipi-os-configurator-data
      Conflicts: neuron-kernel, unipi-kernel-modules
      Breaks: unipi-os-configurator (<= 0.36)
      Filename: pool/main/u/unipi-kernel-modules/unipi-kernel-modules-dkms_2.20~bullseye_all.deb
      Size: 65548
      MD5sum: 58dd0b85c6bb1341e1d29235f68e77b5
      SHA1: 9bc3309cc75ba1e2a62b26032783496be5ce7cb1
      SHA256: cbb4332357f74ffaf0c8eaba3675c188e5985415d73ea4273af1eb69575dbee0
      SHA512: e869e2059f7bf92fe2c31f80890a6a81dd58a822c25b2ad6fc2e361d7960f25a50b0057fd30ca2d2d715353dc5abdfc685e4c45413ece6d43a3449100b1ea289
      Description: UniPi Neuron/Axon kernel modules - DKMS source
       This package contains source code of kernel module for spi protocol
       used by internal boards in the UniPi Neuron/Axon controllers.
       Can be used with DKMS so that local kernel images are automatically
       built and installed every time relevant kernel packages are upgraded.
      Description-md5: baae29c2849964b1e5815cc38b4cc78c
      Homepage: https://www.unipi.technology/
      
      # apt install unipi-kernel-modules-dkms
      Reading package lists... Done
      Building dependency tree... Done
      Reading state information... Done
      Some packages could not be installed. This may mean that you have
      requested an impossible situation or if you are using the unstable
      distribution that some required packages have not yet been created
      or been moved out of Incoming.
      The following information may help to resolve the situation:
      
      The following packages have unmet dependencies:
       unipi-kernel-modules-dkms : Depends: unipi-os-configurator-data but it is not installable
      E: Unable to correct problems, you have held broken packages.
      
      posted in Official EVOK API
      A
      Achilleas Kotsis
    • unipi-kernel-modules-dkms 1.108 breaks the system on kernel 5.10.103-v7+

      Hello,

      I upgraded unipi-kernel-modules-dkms to v 1.108 and my system broke with the latest default raspbian os kernel 5.10.103

      If the package is incompatible with kernels < 5.13 as I am guessing, you should at least add a "Conflicts" or "Requires" version on the package.

      Reverting to 1.106 seems to resolve the issue.

      [Thu Apr  7 15:52:47 2022] UNIPISPI: SPI CRC2 Not Correct: 01c4 COMPUTED: d2ee
      [Thu Apr  7 15:52:47 2022] UNIPISPI: len=68, part1=fa:00:55:0e part2=00:00:00:00:00:00:00:00:00:00:04:04:20:03:00:00
      [Thu Apr  7 15:52:47 2022] UNIPISPI: SPI CRC2 Not Correct: 6803 COMPUTED: d813
      [Thu Apr  7 15:52:47 2022] UNIPISPI: len=6, part1=fa:00:55:0e part2=00:00:00:04:40:00:03:68:00:00:04:04:20:03:00:00
      [Thu Apr  7 15:52:47 2022] UNIPISPI: SPI CRC1 Not Correct (Received: 0000 Calculated: fe62)
      [Thu Apr  7 15:52:47 2022] UNIPISPI: part1 47:d8:00:00
      [Thu Apr  7 15:52:47 2022] UNIPISPI: SPI CRC2 Not Correct: 0000 COMPUTED: fa95
      [Thu Apr  7 15:52:47 2022] UNIPISPI: len=6, part1=fa:00:55:0e part2=00:00:00:01:01:10:00:00:00:00:04:04:20:03:00:00
      [Thu Apr  7 15:52:47 2022] UNIPISPI: SPI CRC1 Not Correct (Received: 0000 Calculated: 2c31)
      [Thu Apr  7 15:52:47 2022] UNIPISPI: part1 da:01:d4:78
      [Thu Apr  7 15:52:47 2022] UNIPISPI: SPI CRC2 Not Correct: 2002 COMPUTED: 8293
      [Thu Apr  7 15:52:47 2022] UNIPISPI: len=6, part1=fa:00:55:0e part2=00:00:00:00:00:02:02:20:11:03:10:00:10:00:63:88
      [Thu Apr  7 15:52:47 2022] UNIPISPI: SPI CRC1 Not Correct (Received: 04cb Calculated: 6980)
      [Thu Apr  7 15:52:47 2022] UNIPISPI: part1 00:0f:00:31
      [Thu Apr  7 15:52:47 2022] UNIPISPI: SPI CRC2 Not Correct: 8000 COMPUTED: 4113
      [Thu Apr  7 15:52:47 2022] UNIPISPI: len=6, part1=fa:00:55:0e part2=00:00:00:00:00:22:00:80:11:03:10:00:10:00:63:88
      [Thu Apr  7 15:52:48 2022] UNIPISPI: SPI CRC2 Not Correct: 00fa COMPUTED: 0d92
      [Thu Apr  7 15:52:48 2022] UNIPISPI: len=6, part1=fa:00:55:0e part2=00:00:00:00:40:41:fa:00:00:00:04:04:20:03:00:00
      [Thu Apr  7 15:52:48 2022] UNIPISPI: SPI CRC1 Not Correct (Received: e8e8 Calculated: 34c2)
      [Thu Apr  7 15:52:48 2022] UNIPISPI: part1 00:02:20:fa
      [Thu Apr  7 15:52:48 2022] UNIPISPI: SPI CRC2 Not Correct: 06d0 COMPUTED: 871f
      [Thu Apr  7 15:52:48 2022] UNIPISPI: len=6, part1=fa:00:55:0e part2=00:00:00:02:02:0f:d0:06:00:00:04:04:20:03:00:00
      [Thu Apr  7 15:52:48 2022] UNIPISPI: SPI CRC2 Not Correct: 0820 COMPUTED: ded2
      [Thu Apr  7 15:52:48 2022] UNIPISPI: len=68, part1=fa:00:55:0e part2=00:00:00:00:00:00:00:00:00:00:20:21:00:18:00:00
      [Thu Apr  7 15:52:48 2022] UNIPISPI: SPI CRC1 Not Correct (Received: 0000 Calculated: 0358)
      [Thu Apr  7 15:52:48 2022] UNIPISPI: part1 0e:00:00:00
      [Thu Apr  7 15:52:48 2022] UNIPISPI: SPI CRC2 Not Correct: 8018 COMPUTED: 51e9
      [Thu Apr  7 15:52:48 2022] UNIPISPI: len=68, part1=fa:00:55:0e part2=00:00:00:00:00:00:00:00:00:00:00:80:84:00:60:00```
      posted in Official EVOK API
      A
      Achilleas Kotsis
    • RE: Modbus CRC errors, rs485 extensions on Neuron

      I used interceptty to create a pty that logs and passes through to the serial port. I don't know the exact version number where it broke, but definitely happened after I last upgraded, previously it was working OK. Currently using a usb->rs485 adaptor and everything works as expected.

      posted in Official EVOK API
      A
      Achilleas Kotsis
    • RE: Modbus CRC errors, rs485 extensions on Neuron

      Seems like 0xff gets duplicated in the response even if it is part of the CRC

      < 0x01 ([SOH])
      < 0x01 ([SOH])
      < 0x00 ([NUL])
      < 0x00 ([NUL])
      < 0x00 ([NUL])
      < 0x0e ([SO])
      < 0xbd (�)
      < 0xce (�)
      > 	0x01 ([SOH])
      > 	0x01 ([SOH])
      > 	0x02 ([STX])
      > 	0xf4 (�)
      > 	0x00 ([NUL])
      > 	0xff (�)
      > 	0xff (�)
      > 	0x3c (<)
      
      posted in Official EVOK API
      A
      Achilleas Kotsis
    • Modbus CRC errors, rs485 extensions on Neuron

      Hello,
      After upgrading to the latest kernel modules and modbus tools, there seems to be an issue with rs485 communication with serial devices.

      Sending a "turn on coil" command through rs485 produces the following communication output on /dev/ttyNS0

      < 0x01 ([SOH])
      < 0x05 ([ENQ])
      < 0x00 ([NUL])
      < 0x00 ([NUL])
      < 0xff (�)
      < 0x00 ([NUL])
      < 0x8c (�)
      < 0x3a (:)
      > 	0x01 ([SOH])
      > 	0x05 ([ENQ])
      > 	0x00 ([NUL])
      > 	0x00 ([NUL])
      > 	0xff (�)
      > 	0xff (�)
      > 	0x00 ([NUL])
      > 	0x8c (�)
      > 	0x3a (:)
      

      In the reply from the serial extension, the byte "0xff" seems to be duplicated. This doesn't happen on the physical layer, attached decoded communication using an oscilloscope. Also, other types of communications don't seem to be affected (turn off coils, read inputs etc).
      dso.png

      Package versions:

      root@basementplc:~# dpkg -l | grep unipi
      hi  unipi-common                          1.2.30                               armhf        Common utilities for Unipi/Neuron/Axon
      hi  unipi-firmware                        5.52                                 all          Firmware files for UniPi Neuron/Axon boards
      hi  unipi-firmware-tools                  1.2.30                               armhf        Firmware utilities for UniPi Neuron/Axon controllers.
      hi  unipi-kernel-modules-dkms             1.62                                 all          UniPi Neuron/Axon kernel modules - DKMS source
      hi  unipi-modbus-tools                    1.2.30                               armhf        Modbus server for UniPi Neuron/Axon controllers.
      root@basementplc:~# uname -a
      Linux basementplc 5.10.11-v7l+ #1399 SMP Thu Jan 28 12:09:48 GMT 2021 armv7l GNU/Linux
      
      posted in Official EVOK API
      A
      Achilleas Kotsis
    • RE: Upgrading unipi-kernel-modules-dkms to 1.54 causes infinite reboot loop

      OK, it seems that the issue was some weird corruption on the filesystem that was impossible to detect even with windows disk scan or linux fsck on the boot partition.
      Your initramfs script was replacing the file config_unipi.inc with the new version not containing unipiee and neuronee, but the change was not visible and the file was remaining as is.

      Even more wierdly, I changed the file by hand using vi, rebooted, the file seemed changed, but the system STILL loaded unipiee and neuronee overlays on boot, causing still an infinite reboot.

      I removed the file completely and recreated it, and now the system seems to be working properly. Thanks for your help on pinpointing the issue.

      posted in Official EVOK API
      A
      Achilleas Kotsis
    • RE: Upgrading unipi-kernel-modules-dkms to 1.54 causes infinite reboot loop
      root@officeplc:~# cat /boot/config.txt | grep -v ^# | grep -v ^$
      include config_initrd.inc
      include config_unipi.inc
      disable_overscan=1
      hdmi_force_hotplug=1
      dtparam=audio=on
      hdmi_ignore_cec_init=1
      gpu_mem=16
      hdmi_audio_config=0x200 
      root@officeplc:~# cat /boot/config_initrd.inc 
      [pi1]
      initramfs initrd.img-5.4.72+ followkernel
      [pi2]
      initramfs initrd.img-5.4.72-v7+ followkernel
      [pi3]
      initramfs initrd.img-5.4.72-v7+ followkernel
      [pi4]
      initramfs initrd.img-5.4.72-v7l+ followkernel
      [all]
      root@officeplc:~# cat /boot/config_unipi.inc 
      dtparam=i2c_arm=on
      dtoverlay=neuronee
      dtoverlay=i2c-rtc,mcp7941x
      dtoverlay=unipiee
      dtoverlay=neuron-spi-new
      root@officeplc:~#
      

      I guess some of those overlays should be disabled and are leftover...

      posted in Official EVOK API
      A
      Achilleas Kotsis
    • Upgrading unipi-kernel-modules-dkms to 1.54 causes infinite reboot loop

      Traced the issue to file /etc/initramfs-tools/scripts/init-bottom/setbootconfig.sh

      + grep -q 'Hardware[[:blank:]]*:[[:blank:]]*BCM' /proc/cpuinfo
      + unset IS_REAL_SYSTEM
      + unset DO_MOUNT
      + '['  '=' --noreboot -o -n  ]
      + IS_REAL_SYSTEM=1
      + DO_MOUNT=1
      + MNTDIR=/tmp/boot
      + '[' 1 '=' 1 ]
      + '[' -d /sys/firmware/devicetree/base/soc/i2c@7e804000/mcp7941x@6f ]
      + RTC=1
      + '[' -d /sys/firmware/devicetree/base/soc/spi@7e204000/neuronspi@0 ]
      + NEURONDRV=1
      + '[' -d /sys/firmware/devicetree/base/soc/i2c@7e804000/24c01@57 ]
      + EEPROM_1=1
      + '[' -d /sys/firmware/devicetree/base/soc/i2c@7e804000/24c02@50 ]
      + EEPROM_2=1
      + '[' -n 1 -a -n 1 ]
      + EE_CONFLICT=1
      + grep -q okay /sys/firmware/devicetree/base/soc/spi@7e204000/status
      + SPI=1
      + grep -q okay /sys/firmware/devicetree/base/soc/i2c@7e804000/status
      + I2C=1
      + '[' -n 1 -a -n 1 -a -z 1 ]
      + '[' 1 '=' 1 ]
      + mkdir -p /tmp/boot
      + mount /dev/mmcblk0p1 /tmp/boot
      + echo 'dtparam=i2c_arm=on'
      + echo 'dtoverlay=i2c-rtc,mcp7941x'
      + '['  '=' 1 ]
      + echo 'dtoverlay=neuron-spi-new'
      + rm -f /tmp/boot/config-unipi.inc
      + sed -i 's/include config-unipi\.inc/include config_unipi.inc/' /tmp/boot/config.txt
      + INCLUDE='include config_unipi.inc'
      + grep -q -e '^[[:blank:]]*include config_unipi.inc' /tmp/boot/config.txt
      + '[' 1 '=' 1 ]
      + umount /tmp/boot
      + rmdir /tmp/boot
      + sync
      + echo REBOOT
      REBOOT
      + exit 0
      done.
      

      There seem to exist both /sys/firmware/devicetree/base/soc/i2c@7e804000/24c02@50 and /sys/firmware/devicetree/base/soc/i2c@7e804000/24c01@57 folders in my systems, setting the EE_CONFLICT flag. If I comment out the line that sets the flag and reconfigure the package, everything seems to be working OK.

      + grep -q 'Hardware[[:blank:]]*:[[:blank:]]*BCM' /proc/cpuinfo
      + unset IS_REAL_SYSTEM
      + unset DO_MOUNT
      + '['  '=' --noreboot -o -n  ]
      + IS_REAL_SYSTEM=1
      + DO_MOUNT=1
      + MNTDIR=/tmp/boot
      + '[' 1 '=' 1 ]
      + '[' -d /sys/firmware/devicetree/base/soc/i2c@7e804000/mcp7941x@6f ]
      + RTC=1
      + '[' -d /sys/firmware/devicetree/base/soc/spi@7e204000/neuronspi@0 ]
      + NEURONDRV=1
      + '[' -d /sys/firmware/devicetree/base/soc/i2c@7e804000/24c01@57 ]
      + EEPROM_1=1
      + '[' -d /sys/firmware/devicetree/base/soc/i2c@7e804000/24c02@50 ]
      + EEPROM_2=1
      + grep -q okay /sys/firmware/devicetree/base/soc/spi@7e204000/status
      + SPI=1
      + grep -q okay /sys/firmware/devicetree/base/soc/i2c@7e804000/status
      + I2C=1
      + '[' -n 1 -a -n 1 -a -z  ]
      + echo 24c02 0x50
      sh: write error: Device or resource busy
      + '[' -f /sys/bus/i2c/devices/1-0050/eeprom ]
      + echo 0x50
      sh: write error: No such file or directory
      + echo 24c01 0x57
      sh: write error: Device or resource busy
      + '[' -f /sys/bus/i2c/devices/1-0057/eeprom ]
      + IS_NEURON=1
      + '[' '(' -n 1 -o -n  ')' -a -n 1 -a -n 1 ]
      + '[' -n  ]
      + '[' -n 1 ]
      + echo OK
      OK
      + exit 0
      done.
      

      Is there a particular reason for this "conflict" test? Also, rebooting after applying the configs seems a bit extreme, since if anything goes wrong and system goes into an infinite reboot loop, it is a pain to debug and fix...

      posted in Official EVOK API
      A
      Achilleas Kotsis
    • RE: unipi-kernel-modules-dkms does not generate modules on upgrade

      Hi @Martin-Kudláček,

      found another issue on latest rpi kernel.

      Building initial module for 4.19.93+
      Error!  Build of unipi.ko failed for: 4.19.93+ (armv7l)
      Consult the make.log in the build directory
      /var/lib/dkms/unipi/1.36/build/ for more information.
      root@vkplc-home:~# cat /var/lib/dkms/unipi/1.36/build/make.log 
      DKMS make.log for unipi-1.36 for kernel 4.19.93+ (armv7l)
      Wed 22 Jan 2020 12:33:22 PM EET
      make: Entering directory '/usr/src/linux-headers-4.19.93+'
        CC [M]  /var/lib/dkms/unipi/1.36/build/unipi/src/unipi_spi.o
        CC [M]  /var/lib/dkms/unipi/1.36/build/unipi/src/unipi_iio.o
        CC [M]  /var/lib/dkms/unipi/1.36/build/unipi/src/unipi_gpio.o
        CC [M]  /var/lib/dkms/unipi/1.36/build/unipi/src/unipi_uart.o
      /var/lib/dkms/unipi/1.36/build/unipi/src/unipi_uart.c: In function ‘neuronspi_uart_handle_rx’:
      /var/lib/dkms/unipi/1.36/build/unipi/src/unipi_uart.c:320:31: error: passing argument 1 of ‘uart_handle_sysrq_char’ from incompatible pointer type [-Werror=incompatible-pointer-types]
          if (uart_handle_sysrq_char(port, ch))
                                     ^~~~
      In file included from /var/lib/dkms/unipi/1.36/build/unipi/src/unipi_common.h:36,
                       from /var/lib/dkms/unipi/1.36/build/unipi/src/unipi_uart.h:22,
                       from /var/lib/dkms/unipi/1.36/build/unipi/src/unipi_uart.c:19:
      ./include/linux/serial_core.h:514:42: note: expected ‘struct uart_port *’ but argument is of type ‘struct neuronspi_port *’
       uart_handle_sysrq_char(struct uart_port *port, unsigned int ch) { return 0; }
                              ~~~~~~~~~~~~~~~~~~^~~~
        CC [M]  /var/lib/dkms/unipi/1.36/build/unipi/src/unipi_sysfs.o
      cc1: some warnings being treated as errors
      make[1]: *** [scripts/Makefile.build:303: /var/lib/dkms/unipi/1.36/build/unipi/src/unipi_uart.o] Error 1
      make[1]: *** Waiting for unfinished jobs....
      make: *** [Makefile:1522: _module_/var/lib/dkms/unipi/1.36/build/unipi] Error 2
      make: Leaving directory '/usr/src/linux-headers-4.19.93+'
      make: Entering directory '/usr/src/linux-headers-4.19.93+'
        CC [M]  /var/lib/dkms/unipi/1.36/build/rtc-unipi/rtc-unipi.o
      /var/lib/dkms/unipi/1.36/build/rtc-unipi/rtc-unipi.c: In function ‘rtc_unipi_probe’:
      /var/lib/dkms/unipi/1.36/build/rtc-unipi/rtc-unipi.c:666:6: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
            struct nvmem_config nvmem_cfg = {
            ^~~~~~
        Building modules, stage 2.
        MODPOST 1 modules
        CC      /var/lib/dkms/unipi/1.36/build/rtc-unipi/rtc-unipi.mod.o
        LD [M]  /var/lib/dkms/unipi/1.36/build/rtc-unipi/rtc-unipi.ko
      make: Leaving directory '/usr/src/linux-headers-4.19.93+'```
      

      Line 320 in unipi_uart.c

      if (uart_handle_sysrq_char(port, ch))
      

      passes "port" as an arqument to uart_handle_sysrq_char, which is of type "struct neuronspi_port", but uart_handle_sysrq_char expects a type of "struct uart_port", which is part of struct neuronspi_port as seen on unipi_common.h.

      Changing line 320 as below seems to fix the issue.

      if (uart_handle_sysrq_char(&port->port, ch))
      
      posted in Official EVOK API
      A
      Achilleas Kotsis