Request for TP-Link RE220 v1 images (RE200 v3 clone) by someone with a toolchain

Confirmed. On rev200 v3, I get:

root@OpenWrt:~# ls -al /sys/devices/platform/leds/leds/
drwxr-xr-x   10 root     root             0 Jan  1  1970 .
drwxr-xr-x    3 root     root             0 Jan  1  1970 ..
drwxr-xr-x    2 root     root             0 Jan  1  1970 green:lan
drwxr-xr-x    2 root     root             0 Jan  1  1970 green:power
drwxr-xr-x    2 root     root             0 Jan  1  1970 green:wifi
drwxr-xr-x    2 root     root             0 Jan  1  1970 green:wifi2g
drwxr-xr-x    2 root     root             0 Jan  1  1970 green:wifi5g
drwxr-xr-x    2 root     root             0 Jan  1  1970 green:wps
drwxr-xr-x    2 root     root             0 Jan  1  1970 red:wifi2g
drwxr-xr-x    2 root     root             0 Jan  1  1970 red:wifi5g

#2
echo 0   > /sys/devices/platform/leds/leds/green:power/brightness               # turns LEDs off
echo 255 > /sys/devices/platform/leds/leds/green:power/brightness               # turns LEDs on
#3
echo 0   > /sys/devices/platform/leds/leds/red\:wifi2g/brightness               # turns power led (green) off
echo 255 > /sys/devices/platform/leds/leds/red\:wifi2g/brightness               # turns power led (green) on
#4
echo 0   > /sys/devices/platform/leds/leds/red\:wifi5g/brightness               # green light on wifi symbol ?
echo 255 > /sys/devices/platform/leds/leds/red\:wifi5g/brightness               # red light on wifi symbol

Thanks for testing. Does turning off green:wifi also work?

#wifi light off
echo 0   > /sys/devices/platform/leds/leds/green:wifi/brightness
echo 0   > /sys/devices/platform/leds/leds/red:wifi5g/brightness

#wifi light green
echo 255   > /sys/devices/platform/leds/leds/green:wifi/brightness
echo 0   > /sys/devices/platform/leds/leds/red:wifi5g/brightness

#wifi light red
echo 0   > /sys/devices/platform/leds/leds/green:wifi/brightness
echo 255   > /sys/devices/platform/leds/leds/red:wifi5g/brightness

#wifi light kinda orange
echo 255   > /sys/devices/platform/leds/leds/green:wifi/brightness
echo 255   > /sys/devices/platform/leds/leds/red:wifi5g/brightness

@borromini
I can live with the leds as is. Your call, if you want to implement dts changes.

Proposed RE220v1 .dts file
rename re200-v3 dts content to re220-v1 then prepend the = re200.dtsi content
then update led definitions per earlier post

I'm hesitant to change green:power as it might leave all leds off. I see led_power is referenced in a few aliases, so not sure ramifications of changing it.
In fact if night-mode is implemented in hardware, maybe it is why all lights are off during the U-boot failsafe phase.

gpio 43 becomes green:powerx   (was red:wifi2g)
gpio 40 becomes red:wifi       (was red:wifi5g)

Could additionally try this:

gpio 44 becomes green:nightmode   (was green:power)
gpio 43 becomes green:power       (was red:wifi2g)

I can test any builds you want to try.

I have been keeping an eye on this thread with a lot of interest. I have a RE220 v1 and would like to jump over to using openwrt instead of stock tp-link fw.

Some questions if I may:
1 - Would using the GPL link on TP-Link's website help? It is an openwrt version: https://static.tp-link.com/resources/gpl/re220v1_gplcode.tar.bz2
2 - Do you need another tester? I am happy to help test this out, building is beyond my skills right now.
3 - For more experienced builders/users - How long does it normally take from working model to being listed in the openwrt supported hardware tables?

I apologize in advance for the noob questions. Thanks.

@Borromini will you be able to prepare the PR? It seems @amteza never had the build working 100%

  1. Good stuff. I don't think it is needed at this point.
  2. It would be great to have someone else test the RE220-v1
    I'll repeat my comment from the other RE220-V1 thread.
    Like other devices in this family (RE220v2, RE200) the 5GHz radio is not perfect. If you are happy with stock firmware, you may want to stick with it.

If you are relying on the device, you may not want to use it for testing.

I have not tried reverting back to OEM firmware.

If you want to be fully informed check out the thread on the RE200
The RE200 TOH is also useful.

If you do want to test, you can try the factory image from Borromini's Sept 29 post.

Note that a couple of vulnerabilities have been identified recently that are not in the experimental build.

  1. I'll leave that to the experienced builders.

@jedboy, I can prepare a build that works, but compilation will build the kernel modules in. I don't think it's the way to go; I'm not sure PR will be accepted in that case. Do you want me to try anyways?

I think following the standard way would be best.

1 Like

I will, but with a baby girl and a few pressing personal projects, it will take some time. I haven't abandoned this.

1 Like

No worries. Thanks.

yes it does.

@Borromini Would it be possible to include switch aware VLAN in the PR as well ?
I posted this a while back :

But also am not familiar with PR process.

Please advise.

Sorry for delayed response.

Thanks for the information.

I was able to flash my RE220 to the linked fw, but I had to downgrade to v.190616 because with more recent fw version from TP-link would produce an error about invalid fw.

Overall, I was able to get RE220 to work, however the lights would not light up but that is not a big issue for me.

Since this is a test device for me, I made several different configurations and everything was working as far as I could tell.

Then I ran into trouble. I decided to attempt to upload the same openwork firmware and things were going along nicely until I had a power outage. Sooooo... now I have a pretty white brick.

I am going to try to revive it so I am getting that together.

I wish you guys well.

Sorry for the wait guys, got some time to take another peek, so here we go.

Well from what I can tell this is already in the code?

        tplink,re200-v2|\
        tplink,re200-v3|\
        tplink,re200-v4|\
        tplink,re220-v1|\
        tplink,re220-v2|\
        tplink,re305-v1|\
        tplink,re305-v3|\
        tplink,tl-wr802n-v4|\
        tplink,tl-wa801nd-v5|\
        widora,neo-16m|\
        widora,neo-32m)
                ucidef_add_switch "switch0"
                ucidef_add_switch_attr "switch0" "enable" "false"
                ucidef_set_interface_lan "eth0"
                ;;

Good catch, it shouldn't be.

Is it an actual LED that is visible on the device or is this just a GPIO that turns all LEDs off?

I have changed the other LEDs like you asked:

  • Green power LED to GPIO 43 (was red WiFi 2G LED)
  • Green night light to GPIO 44 (if it's not a LED I will remove it)
  • Red WiFi 5G LED to a band agnostic red WiFI LED.

Let me know about the night light GPIO, then I can adapt the DTS and build a new image for everyone to test.

thank you! VLAN-aware change must have been made in the latest releases :grinning::+1:

GPIO 44 does not map to a specific LED. I guess the correct thing is to remove it. I will test your updated image and see if removing it causes any problems (like keeping all lights off by default).

Alright, master images (including LuCI) can be found here, the patch to add support (which applies cleanly to 22.03 HEAD btw, in case anyone wants to try) is there as well. I am getting the message on 22.03 that the images are too big to be built though, but that might be some personal settings that are lingering. I haven't been able to clean them out though, so YMMV.

I used new sysupgrade image on device that had your previous image.

When device starts, power light comes on, but it is the only one.

There are some problems with the image.
No 2.4GHz radio
no ../leds/leds directory.

root@OpenWrt:~# ubus call system board
{
        "kernel": "5.10.156",
        "hostname": "OpenWrt",
        "system": "MediaTek MT7628AN ver:1 eco:2",
        "model": "TP-Link RE220 v1",
        "board_name": "tplink,re220-v1",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "SNAPSHOT",
                "revision": "r21374+1-366bcffa0e",
                "target": "ramips/mt76x8",
                "description": "OpenWrt SNAPSHOT r21374+1-366bcffa0e"
        }
}
root@OpenWrt:~# cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'pci0000:00/0000:00:00.0/0000:01:00.0'
        option channel '36'
        option band '5g'
        option htmode 'VHT80'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'OpenWrt'
        option encryption 'none'

root@OpenWrt:~# ls -al /sys/devices/platform/leds
drwxr-xr-x    2 root     root             0 Jan  1  1970 .
drwxr-xr-x   19 root     root             0 Jan  1  1970 ..
-rw-r--r--    1 root     root          4096 Nov 30 17:25 driver_override
-r--r--r--    1 root     root          4096 Nov 30 17:25 modalias
lrwxrwxrwx    1 root     root             0 Nov 30 17:25 of_node -> ../../../firmware/devicetree/base/leds
lrwxrwxrwx    1 root     root             0 Nov 30 17:25 subsystem -> ../../../bus/platform
-rw-r--r--    1 root     root          4096 Nov 30 17:25 uevent
root@OpenWrt:~#

Can you still change the value of that GPIO 44? If so, do the other LEDs activate again?

Anything in logread or dmesg about that radio?

Other than the LEDs, nothing changed in the DTS AFAIK. But I'll double check.

nothing jumps out at me. dmesg has 'MAC error detected'