search

xmos / vocalfusion-rpi-setup

3 stars 13 forks source link

Can't build i2c-gpio-param #13

Closed srchack closed 2 years ago

srchack commented 5 years ago

raspberrypi-kernel 1.20190517-1 not have "linux/i2c-gpio.h". Should I use "include/linux/platform_data/i2c-gpio.h"? raspbian kernel changed based 4.19.42-v7+.

this setup.sh stdout print.

$ ./setup.sh  vocalfusion
Installing Raspberry Pi kernel headers
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  raspberrypi-kernel-headers
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 16.7 MB of archives.
After this operation, 108 MB of additional disk space will be used.
Get:1 http://archive.raspberrypi.org/debian stretch/main armhf raspberrypi-kernel-headers armhf 1.20190517-1 [16.7 MB]
Fetched 16.7 MB in 17s (968 kB/s)
Selecting previously unselected package raspberrypi-kernel-headers.
(Reading database ... 35639 files and directories currently installed.)
Preparing to unpack .../raspberrypi-kernel-headers_1.20190517-1_armhf.deb ...
Unpacking raspberrypi-kernel-headers (1.20190517-1) ...
Setting up raspberrypi-kernel-headers (1.20190517-1) ...
make -C /lib/modules/4.19.42-v7+/build SUBDIRS=/home/pi/vocalfusion-rpi-setup/loader/i2s_slave modules
make[1]: Entering directory '/usr/src/linux-headers-4.19.42-v7+'
  CC [M]  /home/pi/vocalfusion-rpi-setup/loader/i2s_slave/loader.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /home/pi/vocalfusion-rpi-setup/loader/i2s_slave/loader.mod.o
  LD [M]  /home/pi/vocalfusion-rpi-setup/loader/i2s_slave/loader.ko
make[1]: Leaving directory '/usr/src/linux-headers-4.19.42-v7+'
cp: cannot create regular file '/home/pi/.config/lxpanel/LXDE-pi/panels/panel': No such file or directory
grep: /etc/modprobe.d/i2c.conf: No such file or directory
make -C /lib/modules/`uname -r`/build M=/home/pi/vocalfusion-rpi-setup/i2c-gpio-param modules
make[1]: Entering directory '/usr/src/linux-headers-4.19.42-v7+'
  CC [M]  /home/pi/vocalfusion-rpi-setup/i2c-gpio-param/i2c-gpio-param.o
/home/pi/vocalfusion-rpi-setup/i2c-gpio-param/i2c-gpio-param.c:4:28: fatal error: linux/i2c-gpio.h: No such file or directory
 #include <linux/i2c-gpio.h>
                            ^
compilation terminated.
scripts/Makefile.build:309: recipe for target '/home/pi/vocalfusion-rpi-setup/i2c-gpio-param/i2c-gpio-param.o' failed
make[2]: *** [/home/pi/vocalfusion-rpi-setup/i2c-gpio-param/i2c-gpio-param.o] Error 1
Makefile:1524: recipe for target '_module_/home/pi/vocalfusion-rpi-setup/i2c-gpio-param' failed
make[1]: *** [_module_/home/pi/vocalfusion-rpi-setup/i2c-gpio-param] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-4.19.42-v7+'
Makefile:6: recipe for target 'all' failed
make: *** [all] Error 2
larry-xmos commented 5 years ago

Without looking into your report further, can I ask if you have kernel headers installed that match your running kernel?

sudo apt-get install --reinstall raspberrypi-bootloader raspberrypi-kernel (from readme)

srchack commented 5 years ago

Yes it will be the same version.

Yes, there was no problem with the kernel package version 1.201901401 which I used until last week. It seems to be a problem from kernel package version 1.20190517-1. Currently, kernel package version 1.20190517-1 is provided by apt on raspbian.

oscarbailey-xmos commented 5 years ago

I just ran into the same issue, after doing some digging it looks like the header was moved: https://github.com/raspberrypi/linux/commit/1e9d42194e4c8f0ba3f9d4f72b5f54050ddf7a39#diff-e222aaa4de985a739fb97ab9329fd15e

srchack commented 5 years ago

Hi, But can't change to "linux/platform_data/i2c-gpio.h". Member variables "sda_pin" and "scl_pin" have been removed from "i2c_gpio_platform_data". i2c-gpio-param module can not be used.

I'm trying to use i2c-gpio overlay now. Add line on "/boot/config.txt"

dtoverlay=i2c-gpio,bus=3,i2c_gpio_sda=2,i2c_gpio_scl=3,i2c_gpio_delay_us=5,timeout-ms=100

Even if bus no is specified, it does not become 1. I give it to 3 but the operation of XVF3100 looks like no problem. I have tried only Raspberry Pi 3B+.

larry-xmos commented 5 years ago

I just ran into the same issue, after doing some digging it looks like the header was moved: raspberrypi/linux@1e9d421#diff-e222aaa4de985a739fb97ab9329fd15e

@oscarbailey-xmos, thank you. It does indeed look like late Raspbian breaks i2c-gpio-param. What appears to be original source (kadamski/i2c-gpio-param@54191c1) doesn't have a fix, so we have to investigate.

@srchack, are you able work around the issue by scaling back your kernel version?

srchack commented 5 years ago

@larry-xmos I use temporarily the old kernel, but I want to use it in the latest state. Now it looks like there is no problem with dependencies if you pin with "dpkg --set-selections",

Before setup, run under commands. 

$ echo "raspberrypi-kernel hold" | sudo dpkg --set-selections
$ sudo apt-get install raspberrypi-kernel-headers
$ echo "raspberrypi-kernel-headers hold" | sudo dpkg --set-selections

but I think that problems will arise in the future. If a new image of raspbian is provided, you will have to use a new kernel version.

larry-xmos commented 5 years ago

Thank you for the details, and agreed that a fresh install will suffer the issue

johned0 commented 5 years ago

Thanks for adding me, Chris, I saw this problem a couple of days ago and was also looking for a solution. @srchack is correct, the platform_data version of i2c-gpio.h does not replace the original version. I tried @srchack 's suggestion "$ echo "raspberrypi-kernel hold" ..... " but this did not work for me. The only solution I have at the moment is to revert the kernel, see here for further details : https://lb.raspberrypi.org/forums/viewtopic.php?t=224931&start=100. Also related github issues : https://github.com/raspberrypi/linux/issues/2981 https://github.com/raspberrypi/linux/issues/2983

I'll upload a solution if I find one. J

magicfuh commented 5 years ago

To fix build problem:

  1. i2c-gpio-param/i2c-gpio-param.c -#include <linux/i2c-gpio.h> +#include <linux/platform_data/i2c-gpio.h>
  2. /usr/src/linux-headers-4.19.42-v7+/include/linux/platform_data/i2c-gpio.h struct i2c_gpio_platform_data { + unsigned int sda_pin; + unsigned int scl_pin;

BUT, "insmod i2c-gpio-param.ko" cannot create /dev/i2c-7. How to make it working with kernel 4.19?

kevinyeungxmos commented 5 years ago

Please refer to ticket #32225 for an interim solution.

larry-xmos commented 5 years ago

Please refer to ticket #32225 for an interim solution.

Please note that this (deferring to the out-of-box BCM hardware I2C) refers to a newer VocalFusion product that does away with I2C clock stretching, and therefore hides the BCM SoC issue. For XVF3000/3100 that can't do without clock stretching, only a kernel downgrade can be recommended at this point.

jfathman commented 5 years ago

For the XVF3000 use case where the end product does not use the I2C control interface, would it be practical to add a --no-custom-i2c-driver option to setup.sh that skips building the custom I2C driver and skips disabling the built-in I2C driver?

Skipping the custom I2C driver build avoids the dependency on I2C changes to the Linux kernel.

Granted, the custom I2C driver may ultimately be needed for users who want to use the I2C control interface, but for those who don't, it is better to leave the built-in I2C driver in place, undisturbed.

Another way to think about it is that if I am not using the XMOS I2C control interface, I probably don't want to be dependent on the XMOS I2C custom driver for my other I2C peripherals connected to the RPi.

Please further consider that if this suggestion is implemented, we will also need a way to pass --no-custom-i2c-driver to vocalfusion-rpi-setup setup.sh when that script is run indirectly via vocalfusion-avs-setup auto_install.sh, which is the typical situation.

srchack commented 5 years ago

In 4.19.42-v7 +, setting i2c-gpio-overlay confirms that the utility using i2c works.

$ cat /boot/config.txt
#dtparam=i2c_arm=off
dtoverlay=i2c-gpio,bus=3,i2c_gpio_sda=2,i2c_gpio_scl=3,i2c_gpio_delay_us=5,timeout-ms=100

it only changes to the method of directly specifying what has been setup in the /sys filesystem on load_i2c_gpio_driver.sh. The behavior of i2c communication itself is expected to be unchanged in the kernel version 4.19,

I would like why the XVF 3000/3100 is an I2C clock stretching premise. XMOS I2C library? or is it XVF 3000/3100 hardware problem? I have had doubt about that the whole time.;I was wondering about that the whole time. Sorry for lack of knowledge.

larry-xmos commented 5 years ago

Thank you for the suggestion, @jfathman. I suspect this won't be added to the script in the first instance, as it's only intended to run in I2S configuration with I2C control. As you are probably aware, it can be fairly easily modified for USB control, but that isn't supported in the scripts at all. The appropriate channels are on copy to consider this. Alternatively, you are free to submit a pull request to instigate your suggestion on a branch.

@srchack, the overlay driver is worth looking into. Thanks for pointing it out. To answer your question about clock stretching, it is simply due to certain commands taking longer to process in the VocalFusion software than can be handled without clock stretching. One solution would be a protocol that separates request from response with some sort of polling command to find out when the response is ready.

larry-xmos commented 5 years ago

We've done some testing using the hardware I2C and it seems to work fine with XVF3510 at a reduced clock speed of 10kHz. This is slow for compound commands such as plot AEC coefficients, but individual commands run normally.

dtparam=i2c_arm=on
dtparam=i2c_arm_baudrate=10000
larry-xmos commented 5 years ago

We've also tested the device tree overlay, as suggested, and that also appears to working fine. Thank you @srchack for the suggestion. The xmos/vocalfusion-rpi-setup repository is due to be updated with the hardware I2C solution.

jfathman commented 5 years ago

FWIW, we tested the experimental setup5.sh solution with the reduced baud rate and I2C control of the XVF3000 worked, but keep in mind that the reduced baud rate applies to all peripherals sharing that I2C bus. The slowdown is particularly noticeable in the significantly reduced rate at which our I2C operated 16x2 LCD paints text updates. There is a trade-off here that can impact user experience.

srchack commented 5 years ago

@larry-xmos Thanks,

@jfathman It is not desirable for me to be slow. I want to confirm the operation, but is it possible to share setup5.sh?

jfathman commented 5 years ago

@srchack I obtained setup5.sh from XMOS support via my employer, and I don't know if there is any NDA associated with that. Could you try asking XMOS support or your XMOS rep to provide it to you directly? If that doesn't work for you, let me know and I'll try to find out on my end if I am at liberty to share the file. Thanks.

larry-xmos commented 5 years ago

I believe the setup5.sh you are referring to configures 10kHz hardware I2C instead of the i2c-gpio-param driver

It also disables the hardware I2C for XVF3500 by calling raspi-config nonint do_i2c 1 and then raspi-config nonint do_i2c 0

It also added handling of model B that unlike B+ doesn't have the combined parameter

Feel free to use this copy

srchack commented 5 years ago

@jfathman @larry-xmos Thanks, I tried setup5.sh but I was not stable. I'm looking i2c-gpio solution is better. on 3B+, kernel 4.19.50-v7+, XVF3100.

jfathman commented 5 years ago

@srchack Could you please describe the instability you observed? My experience with setup5.sh is that I2C communication with the XVF3000 is intermittent as shown below. I often have to repeat the operation several times to achieve success. I have not explored this further, so it could be an I2C integration issue unrelated to setup5.sh, but if you see similar errors, that could be independent confirmation of some kind of timing problem with the setup5.sh approach. I see the same errors on Raspbian stretch and the newly released Raspbian buster.

jfathman@rpi:~$ sudo ./vfctrl_i2c AGCMAXGAIN
rdwr ioctl error -1: Remote I/O error
AGCMAXGAIN:NA

jfathman@rpi:~$ sudo ./vfctrl_i2c AGCMAXGAIN
rdwr ioctl error -1: Remote I/O error
Error: Control read command failed

jfathman@rpi:~$ sudo ./vfctrl_i2c AGCMAXGAIN
AGCMAXGAIN:31.6

jfathman@rpi:~$ sudo ./vfctrl_i2c AGCMAXGAIN
rdwr ioctl error -1: Remote I/O error
AGCMAXGAIN:NA

jfathman@rpi:~$ sudo ./vfctrl_i2c AGCMAXGAIN
rdwr ioctl error -1: Remote I/O error
Error: Control read command failed

jfathman@rpi:~$ sudo ./vfctrl_i2c AGCMAXGAIN
AGCMAXGAIN:31.6

jfathman@rpi:~$ sudo ./vfctrl_i2c AGCMAXGAIN
AGCMAXGAIN:31.6
srchack commented 5 years ago

@jfathman It is the same phenomenon. I also recognize that it is an I2C integration issue.

hyuting1008 commented 4 years ago

@larry-xmos @srchack @johned0 Hello guys. I am using XVF3000 L33 and trying to use the i2c to do parameter control. My Raspberry Pi 3B kernel is 4.14.73-v7+.

I've tried three kinds of i2c setup: One is the original setup.sh which sets in /boot/config.txt dtparam=i2c_arm=on dtparam=i2c_arm_baudrate=10000 this came across error and xmos on 0x2c would be disappear.

the other two are #dtparam=i2c_arm=off dtoverlay=i2c-gpio,bus=3,i2c_gpio_sda=2,i2c_gpio_scl=3,i2c_gpio_delay_us=5,timeout-ms=100 and dtparam=i2c_arm=off both load with load_i2c-gpio_driver.sh but it didn't work either. and every time I execute vfctrl_i2c, terminal will shut down.... why would this happen?

I also tried on RPI4 because RPI4 seemed to fix the clock stretching bug, but it showed the same error..... why RPI4 cannot work either?

Sorry for lack of the knowledge. May I ask how you guys fix the problem? I would appreciate any information you may give.

mbanth commented 2 years ago

We no longer build the I2C-based drivers, using the default ones from the Raspberry Pi OS instead. Consequently, I'm closing this issue.