No. I watched carefully during several runs of the script.
Sorry. Always forget that all but gpio0 contollers are disabled by default.
Add into dts-files:
&gpio1 {
status = "okay";
};
&gpio2 {
status = "okay";
};
&gpio3 {
status = "okay";
};
and check again.
Sorry, I'd flashed an older build that did not contain the changes. Output deleted and will update soon.
Success 
root@Shepnet:/tmp# ./blink_all.sh 3s 40 44
GPIO LED Test
Usage: ./blink_all.sh [wait time] [gpio start] [gpio end]
Example: ./blink_all.sh 3s 0 1
leave gpio range blank to test all GPIOs.
[gpiochip40:40:out] = 0
[gpiochip40:40:out] = 1
[gpiochip40:41:out] = 0
[gpiochip40:41:out] = 1
[gpiochip40:42:out] = 0
[gpiochip40:42:out] = 1
[gpiochip40:43:out] = 0
[gpiochip40:43:out] = 1
[gpiochip40:44:out] = 0
[gpiochip40:44:out] = 1
root@Shepnet:/tmp#
The Globe/Internet LED turned steady green during [gpiochip40:40:out] = 0
Edit: I'm guessing based on mt7620a.dtsi that gpiochip40 is in group gpio1
gpio1: gpio@638 {
compatible = "ralink,mt7620a-gpio", "ralink,rt2880-gpio";
reg = <0x638 0x24>;
interrupt-parent = <&intc>;
interrupts = <6>;
gpio-controller;
#gpio-cells = <2>;
ralink,gpio-base = <24>;
ralink,nr-gpio = <16>;
ralink,register-map = [ 00 04 08 0c
10 14 18 1c
ralink,gpio-base = <24> ralink,nr-gpio = <16> -> 16+14 =40,
I'm also guessing the LAN4 hardware driver would need to be deactived in the dts?
You go in right direction but don't pay attention that gpio numbering is zero based.
gpio2: gpio@660 {
compatible = "ralink,mt7620a-gpio", "ralink,rt2880-gpio";
reg = <0x660 0x24>;
interrupt-parent = <&intc>;
interrupts = <6>;
gpio-controller;
#gpio-cells = <2>;
ralink,gpio-base = <40>;
ralink,nr-gpio = <32>;
ralink,register-map = [ 00 04 08 0c
10 14 18 1c
20 24 ];
status = "disabled";
};
So total dts-file midifications:
- Release hardware control:
&gsw {
mediatek,port4 = "ephy";
};
- Set gpio control:
&state_default {
gpio {
ralink,group = "i2c", "uartf", "ephy";
ralink,function = "gpio";
};
};
- Enable gpio2 controller:
&gpio2 {
status = "okay";
};
- Add green lan LED into leds section:
lan {
label = "tew-810dr:green:lan";
gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
};
- Assing default LED action in target/linux/ramips/mt7620/base-files/etc/board.d/01_leds (for current snapshot) or target/linux/ramips/base-files/etc/borad.d/01_leds (for previous releases), e.g.
trendnet,tew-810dr)
ucidef_set_led_netdev "lan" "lan" "$boardname:green:lan" eth0.1
ucidef_set_led_netdev "wan" "wan" "$boardname:orange:wan" eth0.2
;;
or
trendnet,tew-810dr)
ucidef_set_led_switch "lan" "lan" "$boardname:green:lan" "switch0" "0x0f"
ucidef_set_led_switch "wan" "wan" "$boardname:orange:wan" "switch0" "0x10"
;;
I recalled reading this at https://openwrt.org/docs/techref/hardware/port.gpio
Example
In this example we will use GPIO29 and use it as a switch.
With latest linux kernels you may need to first get the gpio base
cat /sys/class/gpio/gpiochip*/base | head -n1
200
and sum the base to your GPIO:
200 + 29 = 229
Now first step is making GPIO available in Linux:
echo "229" > /sys/class/gpio/export
then you need to decide if it will be input or output, as we will use it as a switch so we need output
echo "out" > /sys/class/gpio/gpio229/direction
and last line turns GPIO on or off with 1 or 0:
echo "1" > /sys/class/gpio/gpio229/value
but did not have any context help me understand it.
Is the base already set at 40 so you specified:
gpios = <&gpio2 0 GPIO_ACTIVE_LOW>;
rather than
gpios = <&gpio2 40 GPIO_ACTIVE_LOW>;
?
Last question:
Instead of having the Globe/Internet LED blink green on lan and orange on wan, would it be possible have green on br-lan (both wireless and ethernet) and orange if the wan fails?
- Yes. As you can see in gpio2 controller description:
ralink,gpio-base = <40>;
- Yes you can. Moreover you can reassign any action in LED submenu of LuCI web interface.
My LEDs now mirror the function of the OEM firmware with an entry in the luci leds section. That entry generates the following in /etc/config/system:
config led
option dev 'br-lan'
option sysfs 'tew-810dr:green:lan'
option name 'lan'
option trigger 'netdev'
list mode 'link'
list mode 'tx'
list mode 'rx'
I would like to have this as an ".../mt7620/base-files/etc/board.d/01_leds" entry.
What I have, below, came from a TP-Link entry in 01_leds. It is not working by itself.
trendnet,tew-810dr)
ucidef_set_led_netdev "lan" "lan" "$boardname:green:lan" "br-lan" "link tx rx"
;;
What am I missing?
Not sure but possibly race condition. Script execution berfore creation of bridge interface?
Thinking about options:
- Will test changing the device br-lan -> eth0 LED monitor connection in/out of lan. Suspect I will loose the ability to monitor file transfers between wifi connected machines on the network.
- Rename tew-810dr:green:lan -> tew-810dr:green:wan and monitor wan traffic. Change tew-810dr:orange:wan -> tew-810dr:orange:lan and leave orange:lan unconfigured
- Removing 01_leds entry and add device page entry about setting up.
- Script to poll for creation of br-lan and then execute uci commands
Edit: Option 1 would not implement on install or reboot. I also prepended a "sleep 4 &&" line the 01_leds entry hoping the shell would recognize. Reviewed uci documentation and did not find any sleep options.
Not sure option 2 is viable but will test. If 2 fails will email openwrt-devel regarding possible race condition and potential work arounds.
Edit2: This is interesting - none of my 01_leds entrys are written to /etc/config/system until I enter them in LuCi/system/leds. I'm developing this in master in hopes of a commit ? possible code regression or some syntax error on my part?
Did you change 01_leds and rebuild/reflash firmware? If I recall correctly this script is executed before mounting overlay. So any changes are ignored.
Yes, I would remove the led entry via LuCi/system/leds and reflash with a rebuilt firmware containing the 01_leds changes.
And without saving previous config? If not just reset router with command "firstboot".
Well, I saved my configuration and ran "firstboot" from the command line. My power led turned orange and uci and LuCi were inaccessible. I tried retracing my steps from a prior recovery without success.
I'm on my backup router, also a TEW-810DR running OEM firmware. This cameo based board apparently needs a ncc_att_hwid (cameo hardware id) attached at the end of the build and won't reflash without it. Not sure how the signature is aligned or how forgiving it is from a syntax standpoint. Just know minie is simi-bricked I still have serial ttl access and will go back to the prior thread to see if I can tftpboot recover.
I can enter a failsafe with power-on/reset button depressed but it is the OEM Trendnet failsafe at 192.168.10.1.
I'm wondering if this is becase the TEW-810DR has 16mb SPI Flash chip that is partitioned into 8mb x 2. Or I have screwed up the partitions.
Things to try today:
-
Will try flashing your image from the Trendnet failsafe web.
-
I can get into the serial interface with screen in Debian 10 but there is no prompt or screen contents. If I hit a couple of times, the U-Boot menu flashes by and boots OpenWRT. After reviewing screen shots of the U-Boot menu, will try blindly entering menu options.
-
If I get meaninful info from serial U-Boot, will post the info into the U-Boot Serial flash thread and setup a tftp server in Debian 10.
Thanks
It looks like I have 2 "Failsafe" modes. If I delayed pressing reset until the first Green power led blink, I can ssh into openwrt @ 192.168.1.1. If I can scp the image to 192.168.1.1:/tmp/ and run the sysupgrade command, I may be back in business.
Edit: There were 2 Failsafe modes and un-bricking was easy when I waited for the OpenWrt failsafe green blink. mount_root, scp the bin file to root@192.168.1.1:/tmp and run sysupgrade -n /tmp/.bin
Your build works great so far - I'll use for a couple of days to be sure. I think the changes you made should carry over to the D-Link DIR-810L, and once tested, would be good to commit for both devices.
Thanks
If it is OK, I would like to submit your *.dts, with due credit, to openwrt-devel for testing with the D-Link DIR-810L. Also, did you have a 01_leds entry? I do not have a D-Link to test my self and if it tests OK I'll submit a patch with a cameo-810.dtsi, add TEW-810 support and modify DIR-810L to use the cameo-810.dtsi
Ok
Yes. You can see /rom/etc/board.d/01_leds
Well, I split the dts into a cameo-810.dtsi, removed the 01_leds tew-810dr:orange:wan entry, added tew-810 entries in target/linux/ramips/image/mt7620/base-files/etc/board.d/02_network. Built images on a git master pull, no error messages, and flashed to test. The Flash image semi-bricked again - this time a u-boot menu 3 and a kernel crash loop. Cold start just alternates between power:orange and globe:green - no opportunity to boot OpenWrt failsafe. Can still boot into factory failsafe and flash. The factory failsafe flash does not alter status. Unfortunately, do not have a backup mtd0 or bootloader. I am not ready to submit patches at this time. 
Since I have a backup TEW-810, I'm thinking about getting a CH341A 24 25 EEPROM BIOS Series SPI Writer USB to TTL Flasher USB Programmer, copying the OEM flash and writing it to the semi-bricked device. I'm also open to other recovery suggestions.