GL-MT300N-V2 - gpio 4 5 45 46 not working - solved

dmonty · 2019-03-04T23:47:50.471Z

I’m having trouble getting gpio 4 5 45 46 working. They measure 3.3v 3.3v 3.3v 0.0v

cd /sys/class/gpio
echo 4 > export
echo out > gpio4/direction
echo 0 > gpio4/value

echo 46 > export
echo out > gpio46/direction
echo 0 > gpio46/value

Changing “value” between 0 and 1 has no effect on gpio. They always read 3.3v 3.3v 3.3v 0.0v.

It seems that the pins 4 and 5 are held by i2c. Pins 45 46 are held by uart1(ttyS1). How do I release the i2c and uart1(ttyS1) to be able to use the pins for gpio? I eventually want to run a 1wire bus on these pins but I’m 1st trying to get them to respond to regular gpio.

I’m running this image:
http://downloads.openwrt.org/releases/18.06.2/targets/ramips/mt76x8/openwrt-18.06.2-ramips-mt76x8-gl-mt300n-v2-squashfs-sysupgrade.bin

kyson-lok · 2019-03-05T07:51:42.632Z

You can edit the dts file, set i2c and uart1 to gpio, then rebuild a firmware. Here is an example:

github.com/gl-inet/openwrt

ramips: set i2c pin to gpio on GL.iNet GL-MT300N-V2

committed 03:51AM - 21 Nov 18 UTC

kysonlok

+1 -1

dmonty · 2019-03-05T22:12:34.674Z

Thanks that worked. I added both i2c for pin 4 5 and uart1 for ping 45 46.
ralink,group = “wdt”, “gpio”, “wled_an”, “p0led_an”, “p1led_an”, “i2s”, “i2c”, “uart1”;

GPIO pins are now responding to /sys/class/gpio commands.

However now I can’t install the 1-wire modules even though I added them as modules in make menuconfig. Even though my kernel version is the same as up-stream the kmod-w1-* packages are not installable.

root@OpenWrt:/etc# opkg install kmod-w1 kmod-w1-master-gpio kmod-w1-gpio-custom
Installing kmod-w1 (4.14.103-1) to root…
Downloading http://downloads.openwrt.org/releases/18.06-SNAPSHOT/targets/ramips/mt76x8/packages/kmod-w1_4.14.103-1_mipsel_24kc.ipk
Installing kmod-w1-master-gpio (4.14.103-1) to root…
Downloading http://downloads.openwrt.org/releases/18.06-SNAPSHOT/targets/ramips/mt76x8/packages/kmod-w1-master-gpio_4.14.103-1_mipsel_24kc.ipk
Installing kmod-w1-gpio-custom (4.14.103-3) to root…
Downloading http://downloads.openwrt.org/releases/18.06-SNAPSHOT/targets/ramips/mt76x8/packages/kmod-w1-gpio-custom_4.14.103-3_mipsel_24kc.ipk
Collected errors:

satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-w1:
kernel (= 4.14.103-1-6b7f4bb0e839f1545297907a37980184)
opkg_install_cmd: Cannot install package kmod-w1.
satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-w1-master-gpio:
kernel (= 4.14.103-1-6b7f4bb0e839f1545297907a37980184)
opkg_install_cmd: Cannot install package kmod-w1-master-gpio.
satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-w1-gpio-custom:
kernel (= 4.14.103-1-6b7f4bb0e839f1545297907a37980184)
opkg_install_cmd: Cannot install package kmod-w1-gpio-custom.

dmonty · 2019-03-05T22:53:54.609Z

Found packes in /openwrt/openwrt/bin/targets/ramips/mt76x8/packages - manually scp them to /tmp for install.

dmonty · 2019-03-05T23:27:36.130Z

Is there any reason why gpio isn’t enabled by default by incuding i2c and uart1 (pins 4 5 45 46)?

ralink,group = “wdt”, “gpio”, “wled_an”, “p0led_an”, “p1led_an”, “i2s”, “i2c”, “uart1”;

Should I create a pull request upstream on openwrt?

It also looks like group uart0 could also be added as well would make the serial pins gpio 12, 13 available.

kyson-lok · 2019-03-06T03:09:16.436Z

In general, the kernel magic-number of a firmware built by yourself is inconsistent with other. But you can force to install it with –force-depends.

dmonty · 2019-03-06T18:07:01.790Z

When I added “i2c” and “uart1” to the ralink,group does this break it so pins can’t be used for i2c or uart any more? Is the firmware set that it can only be i2c or only gpio not both toggled in software?

What I’m creating is a network environment monitor for data centers ( if the room is too hot/cold, or wet, or has power issues etc). OpenWRT is great because I can add snmp graphs, email alerts etc. The GL-MT300N-V2 pins defaults to i2c/uart. Should I be using i2c peripherals which are more expensive and larger? Re-compiling to switch the pins to GPIO works but is time consuming. Hence why it would be nice to push the change up-stream - yet I don’t want to break original i2c functionality of the pins.