Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't build i2c-gpio-param #13

Open
srchack opened this issue May 21, 2019 · 23 comments

Comments

Projects
None yet
7 participants
@srchack
Copy link

commented May 21, 2019

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

This comment has been minimized.

Copy link
Contributor

commented May 21, 2019

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

This comment has been minimized.

Copy link
Author

commented May 21, 2019

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

This comment has been minimized.

Copy link

commented May 29, 2019

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

@srchack

This comment has been minimized.

Copy link
Author

commented May 29, 2019

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

This comment has been minimized.

Copy link
Contributor

commented May 30, 2019

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

This comment has been minimized.

Copy link
Author

commented May 31, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented May 31, 2019

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

@johned0

This comment has been minimized.

Copy link

commented May 31, 2019

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 :
raspberrypi/linux#2981
raspberrypi/linux#2983

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

@magicfuh

This comment has been minimized.

Copy link

commented Jun 12, 2019

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

This comment has been minimized.

Copy link

commented Jun 13, 2019

Please refer to ticket #32225 for an interim solution.

@larry-xmos

This comment has been minimized.

Copy link
Contributor

commented Jun 13, 2019

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

This comment has been minimized.

Copy link

commented Jun 14, 2019

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

This comment has been minimized.

Copy link
Author

commented Jun 14, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 14, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 21, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jul 2, 2019

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

This comment has been minimized.

Copy link

commented Jul 2, 2019

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

This comment has been minimized.

Copy link
Author

commented Jul 3, 2019

@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

This comment has been minimized.

Copy link

commented Jul 3, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Jul 3, 2019

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

This comment has been minimized.

Copy link
Author

commented Jul 5, 2019

@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

This comment has been minimized.

Copy link

commented Jul 5, 2019

@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

This comment has been minimized.

Copy link
Author

commented Jul 8, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.