[SOLVED]Getting I2C to Work with a MT300N - Something's wrong?

beecan · 2017-01-16T08:16:18.000Z

Edit: I was being a dolt and was focused on I2C packages only (opkg list | grep i2c) and neglected to install a critical one. Once installed everything worked:
opkg install kmod-gpio-pcf857x

I have no problem running I2C, specifically with a pcf8574 on the 66XX series routers. I would use those routers except that have issues with rt3070 chipsets where it can’t use a USB wifi more than occasionally unless it is plugged in through a USB hub (powered or unpowered). It appears to have issues handshaking with that chipset reliably on all the adapters I have - but that’s a story for another post.

I have done the same process on the on the MT300N (using the clean CC image from GL). It seems like it will work up until it is time to export the GPIOs that should be created by the PCF chip and then it appears there is a conflict with the rt2880 driver trying to use those pins, which is confusing because from what I understand these pins are free to use for other uses.

I selected GPIO 2 for SDA and GPIO 44 for SCL. I verified those GPIOs work fine as both in and out modes prior to using them for I2C. I have installed all the modules and the PCF is detected on 0x20.

#insmod i2c-gpio-custom bus0=0,2,44
dmesg seems to indicate no problem with this
[ 99.100000] i2c-gpio i2c-gpio.0: no of_node; not parsing pinctrl DT
[ 99.100000] rt2880-pinmux pinctrl: request pin 2 (io2) for pio:2
[ 99.100000] rt2880-pinmux pinctrl: request pin 44 (io44) for pio:44
[ 99.100000] i2c-gpio i2c-gpio.0: using pins 2 (SDA) and 44 (SCL)

#i2cdetect 0
reports the device was found at 0x20 (no new errors or logs in dmesg)

#echo pcf8574 0x20 > /sys/bus/i2c/devices/i2c-0/new_device
dmesg reports it seems OK with [ 268.870000] i2c i2c-0: new_device: Instantiated device pcf8574 at 0x20

All of that works as expected and you would think it is going to work… and by the way, this same chip/board does work with the 66XX when I plug it into it, so it isn’t the PCF module. EXCEPT…
The dmesg is missing an important part, “gpiochip_add” is missing in that log that tells us it created a new chip for the expander and what new GPIOs were registered on the device. If it were working like it should it would say something like this as it does on the 66XX series: “<span style=“background-color: #f8f8f8; color: #000000; font-family: Consolas, Monaco, monospace;”>gpiochip_add: registered GPIOs 56 to 63 on device: pcf8574”</span>
The problem happens that I expect the PCF to register as chip56 and I can export GPIOs 56 through 63. Or, even if it wasn’t going to be at 56 that a new chip would be registered in /sys/class/gpio. But after creating the new device no new chip shows up in there. So I try to export gpio 56 anyways.

echo 56 > /sys/class/gpio/export

ash: write error: Invalid argument

dmesg says:
[ 240.890000] rt2880-pinmux pinctrl: request pin 56 (io56) for pio:56
[ 240.890000] rt2880-pinmux pinctrl: pin 56 is not set to gpio mux
[ 240.890000] rt2880-pinmux pinctrl: request() failed for pin 56
[ 240.900000] rt2880-pinmux pinctrl: pin-56 (pio:56) status -22

Since I don’t see a new chip appear for the PCF it seems like it really is not initiated and it did not create the GPIOs which makes me believe that gpiochip_add is not being called.

Can anyone assist on this? We are so close to buying a lot of these GL routers but it seems like each model has some sort of problem. One works great with I2C but has trouble using the adapters we use, one works great with adapters but I2C is broken. The MT300N has been the best performer for our application but without I2C is won’t work.

beecan · 2017-01-16T15:37:52.000Z

I have a few different models of GL routers here that we have been evaluating so I figured I would try to see if I could get I2C working a bone stock AR-150 (external ant version).

I soldered on all the headers like I do on these and installed the packages. The AR150 was actually the worst result yet. Despite verifying the pins were functional as normal GPIO’s before proceeding I couldn’t even detect the I2C device using i2cdetect. I rechecked all the pins and connections a few times and verified on bench it was not a problem with my IC and/or wiring. I’m going to spend more time if needed to check that the AR150 is sinking current properly but during testing the two GPIOs I was going to use prior as just outputs they only measured 2.7V high which seemed odd because on the other models high matches the 3.3V logic level and I confirmed the 3.3V pin is operating at 3.3V.

What’s strange though is I2C works great for my on the 6416 model, which as far as I know is the same SOC as the AR150. The difference between the two is 64XX runs Barrier Breaker while the AR150 is running Chaos Calmer. I’m starting to think that Chaos Calmer is defunct for I2C, at least for some hardware, and it isn’t all that surprising seeing there is not even a i2c-tools package in that distro and it has to be sourced third party.

Either way, I’m just disappointed because they routers showed so much promise for our needs. The 6416a works great with I2C and the PCF port expanders and it would have been a gem if it would reliably work with our wifi adapters without needing an unpowered USB hub to do the negotiation. The MT300N works great with our adapters but I2C is impossible so far, at least in terms of using a port expander and we need more than few unused GPIOs it makes available.

I am really hoping someone here or from GL can do a proof of concept on the MT300N showing how to get a port expander in I2C working. I’m starting to fear we’re going to have to get the devices we need custom made somewhere instead of buying the GL’s for our project we were going to be using all these for. I think the only one we haven’t tried yet is the 300M but I’m not holding out for anything that runs Chaos Calmer yet until I know I2C with a PCF is possible on that distro.

beecan · 2017-01-22T13:01:24.000Z

I’m really hoping someone at GLinet will see this as I imagine they could debug the issue in no time. I am 85% sure the issue is with the Chaos Calmer release having a bug or not fully developed for the hardware.

The reason being is the 6416A works fine, and it uses Barrier Breaker. The AR150 which use the same SoC does not work, and it runs Chaos Calmer. The MT600N does not work and it uses Chaos Calmer.

I need hundreds of these routers if we can get I2C working properly on the MT600N. I would even settle for instructions on how to get a Barrier Breaker version of the firmware built. I have built the images in the past, but only to the extent that the target devices were already listed and it was just a matter of making a custom image with different packages included or config. I have no clue what it takes at the moment to create a new target, but I’m going to maybe have to start studying.

All I need is a I2C based port expander to work with the MT600N like it does with the 6416A and we are in business.

mikemx55 · 2019-02-21T11:47:29.546Z

Hi, this is marked as solved, but how did you solve it?
I’m having the same problem here.