using I2C on openwrt 19.07

[docbee]

I am working on a new version of the Meteobridge PRO device that should be powered by Vocore2 instead of Carambola2. Vocore2 is used as the heart and needs to communicate via I2C and SPI with other devices on the board.

My openwrt 19.07 config builds kmod-i2c-core and kmod-i2c-gpio-custom. The I2C bus is physically connected to VoCore2 pins labeled "I2C SD" and "I2C CLK". When I load and initialize the gpio kernel module by "insmod i2c-gpio-custom bus0=0,5,4" it tells me "i2c-gpio i2c-gpio.0: using pins 5 (SDA) and 4 (SCL)" which sounds ok to me. In addition the expected "/dev/i2c-0" is established.
Problem is, that when I run "i2cdetect 0" I don't see any of the connected devices. What am I doing wrong?

[Vonger]

Do you set i2c mode in DTS(device tree)?
It is default GPIO mode, if you need to run it as i2c, you need to modify that pinmux to I2C.

Also VoCore2 already has internal 4.7kR pull up for the i2c bus, do not need external resistor.
You can reference to the two patches which we use i2c for external sound chip at github.com/vonger/vocore2, in folder 19.07
vocore2-fixmaster-es8388.patch, 0045-i2c-add-mt7621-driver.patch

[docbee]

Thanks. When I understand the two recommended patch files correctly, they don't make the pinmux changes needed.

Current pinmux is as follows:

Code: Select all

root@OpenWrt:/# cat /sys/kernel/debug/pinctrl/pinctrl/pinmux-pins
Pinmux settings per pin
Format: pin (name): mux_owner gpio_owner hog?
pin 0 (io0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 1 (io1): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 2 (io2): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 3 (io3): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 4 (io4): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 5 (io5): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 6 (io6): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 7 (io7): 10000b00.spi (GPIO UNCLAIMED) function spi group spi
pin 8 (io8): 10000b00.spi (GPIO UNCLAIMED) function spi group spi
pin 9 (io9): 10000b00.spi (GPIO UNCLAIMED) function spi group spi
pin 10 (io10): 10000b00.spi (GPIO UNCLAIMED) function spi group spi

Which file do I have to change to enable I2C mode on io pins 4/5? What exactly do I have to enter there?

[docbee]

Trying to apply the patches and having I2C fixed by that did no work for me. Applying all patches puts my image into a boot loop with a kernel panic.
This is how I currently build the image:

Code: Select all

#!/bin/sh
#
# install openwrt 19.07 including vocore patches
#
git clone https://github.com/openwrt/openwrt.git
cd openwrt
git checkout v19.07.3
./scripts/feeds update -a
./scripts/feeds install -a
cd ./package
git clone https://github.com/vonger/vocore2.git
cd ..
#
# patch for 1T1R and 2T2R
echo "======= PATCH 1T1R / 2T2R"
mkdir ./package/kernel/mt76/patches
cp ./package/vocore2/openwrt.1907/0822-mt76-read-factory-eeprom.patch ./package/kernel/mt76/patches
#
# enable SD card
echo "======= PATCH SD CARD"
patch -p1 < ./package/vocore2/openwrt.1907/vocore2-default-enable-sdcard.patch
patch -p1 < ./package/vocore2/openwrt.1907/vocore2-fixmaster-sdcard.patch
#
# enable i2c
cp ./package/vocore2/openwrt.1907/0045-i2c-add-mt7621-driver.patch ./target/linux/ramips/patches-4.14
#
# done
echo "======== DONE"
#


I2C section in menuconfig looks like this:

Code: Select all

-*- kmod-i2c-core................................................ I2C support
-*-   kmod-i2c-algo-bit............................. I2C bit-banging interfaces 
< >   kmod-i2c-algo-pca................................ I2C PCA 9564 interfaces
< >   kmod-i2c-algo-pcf................................ I2C PCF 8584 interfaces
-*-   kmod-i2c-gpio.................................. GPIO-based bitbanging I2C
<*> kmod-i2c-gpio-custom........................ Custom GPIO-based I2C device
< > kmod-i2c-mt7628................................. MT7628/88 I2C Controller
< > kmod-i2c-mux................................ I2C bus multiplexing support
< > kmod-i2c-smbus........................... SMBus-specific protocols helper
< > kmod-i2c-tiny-usb................................... I2C Tiny USB adaptor

My thinking is, that GPIO pins 4 and 5 do not need to be bound to I2C on kernel level, but can just be used for i2C when loading the custom i2C module via "insmod i2c-gpio-custom bus0=0,5,4". kernel message tells me that now pins 4 and 5 are used for I2C. Do I really need to adjust pinmux? Why?

Running "i2cdetect 0" does still not find any devices although a couple are wired to those pins. I removed external pull-up resistors and I2C devices are powered with 3.3v.

Any idea how to get around this issue? Currently that is a show stopper to my project.

[docbee]

As no luck with the custom gpio driver I switched to the mt7628 one. I also enabled i2c in VOCORE2.dts.

Code: Select all

...
&i2c {
        status = "okay";
};

Now pinmux shows gpio pins 4 and 5 as bound to I2C:

Code: Select all

root@OpenWrt:/# cat /sys/kernel/debug/pinctrl/pinctrl/pinmux-pins
Pinmux settings per pin
Format: pin (name): mux_owner gpio_owner hog?
pin 0 (io0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 1 (io1): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 2 (io2): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 3 (io3): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 4 (io4): 10000900.i2c (GPIO UNCLAIMED) function i2c group i2c
pin 5 (io5): 10000900.i2c (GPIO UNCLAIMED) function i2c group i2c
pin 6 (io6): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 7 (io7): 10000b00.spi (GPIO UNCLAIMED) function spi group spi
pin 8 (io8): 10000b00.spi (GPIO UNCLAIMED) function spi group spi
pin 9 (io9): 10000b00.spi (GPIO UNCLAIMED) function spi group spi
pin 10 (io10): 10000b00.spi (GPIO UNCLAIMED) function spi group spi


kernel log also reports about an existing i2c device:

Code: Select all

root@OpenWrt:/# dmesg | grep i2c
[   13.373595] i2c /dev entries driver
[   13.386166] i2c-mt7621 10000900.i2c: clock 100KHz, re-start not support
root@OpenWrt:/#

Unfortunately, i2cdetect reports nonsense:

Code: Select all

root@OpenWrt:/# i2cdetect -y 0
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: 30 31 32 33 34 35 36 37 -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- -- 

Any idea how to proceed? (the 0045 patch has been applied)

[docbee]

Today I switched back to the i2c-gpio-custom kernel module and tried using GPIOs 39 and 40 as SDA and SDL. To my surprise that worked instantly. I can now go that way, but not getting the default pins 4/5 working with i2C is not a good sign. I wonder which hurdles I will stumble next when trying SPI?

@vonger: Could you please give a bit more explanation how to get I2C working as designed? Just dropping a few file names to look-up things is not that much helpful. Not all of us are best friends with DTS files and pinmuxing.

[Vonger]

You should use kmod-i2c-mt7628 for i2c.
And you can check es8388 patch, it is sound codec which need to use i2c.

[docbee]

1) When I apply the two es8388 patches the resulting kernel image will be stuck in and endless loop caused by a kernel panic.

2) In addition to that there are two patches related to es8388: 0810-sound-es8388-aplay.patch, vocore2-fixmaster-es8388.patch
The 0810-sound-es8388-aplay.patch does not say anything about I2c imho.
The "vocore2-fixmaster-es8388.patch" makes some changes to the "VOCORE2.dtsi" that are related to I2C:

Code: Select all

 &pinctrl {
        state_default: pinctrl0 {
                gpio {
-                       ralink,group = "wled_an", "refclk", "wdt";
+                       ralink,group = "wled_an", "wdt";
                        ralink,function = "gpio";
                };

+&i2c {
+       status = "okay";
+
+       codec: es8388@10 {
+               #sound-dai-cells = <0>;
+               compatible = "everest,es8328";
+               reg = <0x10>;
+
+               clocks = <&clkctrl 20>;
+               clock-names = "refclk";
+       };


Taking the es8388 stuff away I experienced that adding the "status=okay" line for I2C does make I2C devices show up, but i2cdetect does not show the correct bus status.

Are you sure you ever made I2C running with the kmod-i2c-mt7628 on 19.07? I start doubting that.

[Vonger]

Maybe you can try our exists firmware, it is based on the patch.
address here: http://vonger.cn/misc/vocore2/20191127.bin

also in http://vonger.cn/misc/vocore2/ has some other version firmware.

[docbee]

I am developing the next version of the Meteobridge PRO. Therefore, precompiled images are not a solution for me, I need complete control and the ability to patch things when I put this in volume on the market.

Is it too much to ask to provide dts and other kernel config files that simply make the I2C and SPI pins on the VoCore2 to operate as advertised? Going with OPENWRT 19.07 and selecting VoCore2 there does not result into an OPENWRT image with I2C and SPI support.

I am fine to replace config files manually when upstreaming into OPENWRT is an issue. But being rather left alone on how to get basic stuff like this running is a bit frustrating. Currently, I just got pointers to URLs where I might find something. A proper VOCORE2.dts with working i2C and SPI support on the pins advertised is all I ask for. I think that is a rather reasonable request.