Help needed: Some GPIOs that normally work under vendor firmware no longer function under OpenWrt

Hi,

I'm working on an OpenWrt port for a device that is running a vendor firmware. It is based on MediaTek MT7620A. Here is the /etc/openwrt_release:

DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='SNAPSHOT'
DISTRIB_REVISION='r19989-24eee4b244'
DISTRIB_TARGET='ramips/mt7620'
DISTRIB_ARCH='mipsel_24kc'
DISTRIB_DESCRIPTION='OpenWrt SNAPSHOT r19989-24eee4b244'
DISTRIB_TAINTS='no-all'

I don't know why these two GPIOs, 40 and 45, don't work under OpenWrt when it works normally in the vendor firmware. GPIO40 is for controlling the LAN LED, while GPIO45 is for resetting the LTE module sitting on the mPCIe of the unit. I have gotten all other GPIOs working good in this port, except for these two, so I hope someone could help me understand, as these things are a little out of depth for me at the moment.

Here's an excerpt of the device tree file I created:

#include "mt7620a.dtsi"

#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>

/ {
	compatible = "evoluzn,fx-id3", "ralink,mt7620a-soc";
	model = "Evoluzn FX-ID3";
<snip>
	gpio-export {
		compatible = "gpio-export";
		#size-cells = <0>;

		reset_cp {
			gpio-export,name = "reset_cp";
			gpio-export,output = <1>;
			gpios = <&gpio2 5 GPIO_ACTIVE_LOW>;
		};
	};

	leds {
		compatible = "gpio-leds";

		lan {
			label = "green:lan";
			gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
		};
<snip>
	};

	keys {
		compatible = "gpio-keys";

		reset {
			label = "reset";
			gpios = <&gpio2 29 GPIO_ACTIVE_LOW>;
			linux,code = <KEY_RESTART>;
		};
	};
};

And here's the relevant /sys/kernel/debug/gpio output:

gpiochip1: GPIOs 40-71, parent: platform/10000660.gpio, 10000660.gpio:
 gpio-40  (                    |green:lan           ) out lo ACTIVE LOW
 gpio-45  (                    |reset_cp            ) out hi ACTIVE LOW
 gpio-69  (                    |reset               ) in  hi ACTIVE LOW

So if I do echo 255 > /sys/class/leds/green:lan/brightness it should have turned on the LAN LED, but it doesn't turn on. Also, if I echo 1 > /sys/class/gpio/reset_cp/value it should power cycle/turn on the LTE module on the mPCIe, but this also doesn't do anything. Inverting the values also doesn't give responses from these two GPIOs.

Can anybody tell me what's going on here?

-ianp

Very likely, you need to assign GPIO function to them in pinctrl, because default setup (or one done in U-boot) is different. I don't have any examples at hand, unfortunately, but you can grep other .dts'es for that keyword

Thanks for the tip. I was following a hint in one of your patches for the ZTE MF286 series regarding the WLAN LED Mapping here https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=82b59846368db85ad1470396d95e7c20157288eb

At the moment, I don't understand the pinmux section and its structure. Maybe it is the same condition that I am experiencing with this device as the MF286. At the moment, I'm still trying to figure out the pinctrl subsystem and muxing.

For that device (using MT7620) it is done quite differently, IIRC. MF283+ might be a tiny bit closer, being a RT3352-based platform. See, for example here: https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/dts/mt7620a_dlink_dwr-118-a2.dts - and look for &state_default node.

1 Like

That is also another section of the device tree I'm having a hard time making sense of. :grin: Why a pinctrl group like "ephy" for example with a function = "ephy" from the top level dtsi would need to be reassigned a function = "gpio" under &state_default in the specific dts.

Some devices define it like this:

&ethernet {
     ...
     pinctrl-names = "default";
     pinctrl-0 = <&ephy_pins>;
}

&wmac {
    ...
    pinctrl-names = "default";
    pinctrl-0 = <&pa_pins>;
}

While others have it like this:

&ethernet {
     ...
}

&wmac {
     ...
}

&state_default {
     default {
          groups = "ephy", "pa";
          function = "gpio";
     }
}

I don't think the two forms are the same.

Well, that bit with &state_default node helped get the LAN LED working. I added "ephy" into the node and removed the pinctrl-* lines from the &ethernet node. Now there's only the issue with GPIO45, or what I need to do to power-up the modem in this port.

According to this: https://w.electrodragon.com/w/images/3/34/MT7620_Datasheet.pdf GPIO45 seems to be shared with NAND_CS_N function, maybe this can help you out.

1 Like

This will really help, but first I will need to digest the information contained therein. Thank you once again the help. :relaxed:

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.