Navigation

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

    Achilleas Kotsis

    @Achilleas Kotsis

    0
    Reputation
    10
    Posts
    110
    Profile views
    0
    Followers
    0
    Following
    Joined Last Online

    Achilleas Kotsis Follow

    Best posts made by Achilleas Kotsis

    This user hasn't posted anything yet.

    Latest posts made by 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
    • RE: unipi-kernel-modules-dkms does not generate modules on upgrade

      @martin-kudláček said in unipi-kernel-modules-dkms does not generate modules on upgrade:

      1.2.19.test.20191220083937

      I can confirm the package works as intended on my systems.

      Thanks,
      Achilleas

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

      One more patch against the latest version that renames the old file during package configuration, because if it gets upgraded on a live system, the previously inserted code is not executed (script exits early if devices are found)

      --- setbootconfig.sh.orig	2019-12-19 21:39:51.490185707 +0200
      +++ setbootconfig.sh	2019-12-19 22:04:27.094799784 +0200
      @@ -9,6 +9,10 @@
       if [ "$1" = "--noreboot" -o -n "${DESTDIR}" ]; then
           ## called from package install
           MNTDIR=/boot
      +    # Move old file using '-' instead of '_'
      +    [ -f "${MNTDIR}/config-unipi.inc" ] && mv -f "${MNTDIR}/config-unipi.inc" "${MNTDIR}/config_unipi.inc"
      +    # Change include using '-' instead of '_'
      +    sed -i "s/include config-unipi\.inc/include config_unipi.inc/" "${MNTDIR}/config.txt"
           # check if running from "real" Neuron system
           grep -q '^/dev/mmcblk[[:digit:]]p1 /boot ' /proc/mounts && IS_REAL_SYSTEM=1
       else
      

      This cleaned up my system perfectly doing a dpkg-reconfigure unipi-common so I suppose it should be working on the package being upgraded also. I can test one of my systems if you generate a testing package to see if it applies cleanly.

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

      Hi @martin-kudláček,
      thanks for the reward.

      Can't find the testing repository url, can you please send it?

      Thanks,
      Achilleas

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

      Upon further investigation, I have located the issue.
      dkms checks for installed kernels using the presence of files in /boot directory, including config-* files
      As you can see on a normal x64 debian:

      akots@xps:~$ ls -l /boot/config-*
      -rw-r--r-- 1 root root 235827 Nov 12 10:46 /boot/config-5.3.0-23-generic
      -rw-r--r-- 1 root root 235885 Nov 14 00:41 /boot/config-5.3.0-24-generic
      

      On raspbian, package unipi-common installs two scripts

      root@basementplc:# dpkg -S /etc/initramfs-tools/scripts/init-bottom/setbootconfig.sh
      unipi-common: /etc/initramfs-tools/scripts/init-bottom/setbootconfig.sh
      root@basementplc:~# dpkg -S /etc/kernel/postinst.d/initrd-config
      unipi-common: /etc/kernel/postinst.d/initrd-config
      

      These two scripts create two files in /boot matching the config-* expression

      root@basementplc:/etc# ls -l /boot/config-*
      -rwxr-xr-x 1 root root 212 Nov 10 11:01 /boot/config-initrd.inc
      -rwxr-xr-x 1 root root 108 Sep 29 05:38 /boot/config-unipi.inc
      

      These are the culpit. Renaming these to config_initrd.inc and config_unipi.inc, and changing the relevant includes in /boot/config.txt fixes the issue.

      So, you need to patch unipi-common in order to create files that don't match files that dkms mistakes for kernel configs.
      Attached patches for both files.

      --- initrd-config.orig	2019-12-18 16:18:34.483277993 +0200
      +++ initrd-config	2019-12-18 16:19:31.032380354 +0200
      @@ -1,10 +1,15 @@
       #!/bin/bash
       
       CONFIGTXT=/boot/config.txt
      -CONFIGINC=config-initrd.inc
      +CONFIGINC=config_initrd.inc
       PATHINC="/boot/${CONFIGINC}"
       
      -# check or insert include directive  into config.txt  
      +# Remove old file using '-' instead of '_'
      +rm -f "/boot/config-initrd.inc"
      +# Change include using '-' instead of '_'
      +sed -i "s/include config-initrd\.inc/include config_initrd.inc/" "${CONFIGTXT}"
      +
      +# check or insert include directive into config.txt  
       INCLUDE="include ${CONFIGINC}"
       grep -q -e "^[[:blank:]]*${INCLUDE}" "${CONFIGTXT}" || sed "1 i${INCLUDE}" -i "${CONFIGTXT}"
      
      --- setbootconfig.sh.orig	2019-09-20 12:43:10.000000000 +0300
      +++ setbootconfig.sh	2019-12-18 16:34:06.618599153 +0200
      @@ -54,10 +54,15 @@
       	echo "dtoverlay=i2c-rtc,mcp7941x"
       	echo "dtoverlay=unipiee"
       	[ "$IS_UNIPI1" = "1" ] || echo "dtoverlay=neuron-spi-new"
      -) >"${MNTDIR}/config-unipi.inc"
      +) >"${MNTDIR}/config_unipi.inc"
      +
      +# Remove old file using '-' instead of '_'
      +rm -f "${MNTDIR}/config-unipi.inc"
      +# Change include using '-' instead of '_'
      +sed -i "s/include config-unipi\.inc/include config_unipi.inc/" "${MNTDIR}/config.txt"
       
       # check or insert include into config.txt
      -INCLUDE="include config-unipi.inc"
      +INCLUDE="include config_unipi.inc"
       grep -q -e "^[[:blank:]]*${INCLUDE}" "${MNTDIR}/config.txt" || sed "1 i${INCLUDE}" -i "${MNTDIR}/config.txt"
       
       if [ "${DO_MOUNT}" = "1" ]; then
      
      posted in Official EVOK API
      A
      Achilleas Kotsis
    • RE: unipi-kernel-modules-dkms does not generate modules on upgrade

      Hi @martin-kudláček,

      Initial installation of unipi-kernel-modules-dkms or replacing unipi-kernel-modules works. Upgrading unipi-kernel-modules-dkms to a newer version doesn't work.

      Using raspbian and packages from https://repo.unipi.technology/debian. Happens on both stretch and buster.

      posted in Official EVOK API
      A
      Achilleas Kotsis
    • unipi-kernel-modules-dkms does not generate modules on upgrade
      Unpacking unipi-kernel-modules-dkms (1.36) over (1.34) ...
      Setting up unipi-kernel-modules-dkms (1.36) ...
      Loading new unipi-1.36 DKMS files...
      dpkg: warning: version 'initrd.inc-initrd.inc' has bad syntax: version number does 
      not start with digit
      dpkg: warning: version 'unipi.inc-unipi.inc' has bad syntax: version number does no
      t start with digit
      dpkg: warning: version 'initrd.inc-initrd.inc' has bad syntax: version number does 
      not start with digit
      It is likely that 4.19.75-v7+ belongs to a chroot's host
      Building for unipi.inc
      Module build for kernel unipi.inc was skipped since the
      kernel headers for this kernel does not seem to be installed.
      root@basementplc:~# find /lib/modules -iname '*unipi*'
      root@basementplc:~#
      
      posted in Official EVOK API
      A
      Achilleas Kotsis