Gluon: Add Support for rt2x00: mt7620

[mmalte]

There is a fresh lede Patch for the mt7620 which claims to improve the behavior of these devices significantly:
https://git.lede-project.org/?p=source.git;a=commit;h=9eacb9d7fc0b4c921f8d2ec91a51f10d8c3ae12f

The Archer C20i and C50 are based on this Platform and are already in the lede release candidate.
https://wiki.openwrt.org/toh/tp-link/archer-c50
https://wiki.openwrt.org/toh/tp-link/archer-c20i

I'de love to see this Devices in Gluon since they support Dualband and only cost 30-40€

What do you think about it, is it worth buying devices and test them or send them to you?

[NeoRaider]

The 5GHz WLAN of the Archer C20(i) uses an MT7610, which is completely unsupported and will likely never be supported.

The 5GHz WLAN of the Archer C50 (MT7612) uses the mt76 driver and will likely have the same issues as the DIR860L B1 (high packet loss, stability issues).

[mmalte]

I've tried a DIR860L B1 last weekend, we archived 40mbit/s via Freifunk Aachen with fastd, build from the current gluon master.

Now it is running with the lede rc again and I did not notice such a packetloss, maybe @ohnezahn is able to provide additional information.

[maklein]

The 5GHz WLAN of the Archer C20(i) uses an MT7610, which is completely unsupported

At this moment, in LEDE: yes.

and will likely never be supported.

there ist a driver for this chipset on github for kernel 4.x
so maybe it is worth looking into it.

[rotanid]

@mmalte have you tried both 2,4 and 5ghz? have you tried 11s mesh?

[Ohnezahn]

@NeoRaider I cannot reproduce high packet loss. Just ran mtr through a 860L (running LEDE 17.01-rc2) over 5GHz for some time and got the following results:

 Host              Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. wolf-neu        0.0%  1708    0.7   0.7   0.5 281.2   7.2

[belzebub40k]

@Ohnezahn are you running your tests over a 802.11s mesh link or do just test the client WiFi?
According to https://github.com/freifunk-gluon/gluon/blob/master/targets/targets.mk#L14 only 802.11s links have a high packet loss.

[Adorfer]

i can't reference Daniel here directly. (links here go to the external git of LEDE),
so i just pointed this issue via mail towards him.
But anyway, i hope my "increase priority" pledge does help a little.

[dangowrt]

Ok, I'll try to clarify things:

• Archer C20i uses MT7620A + MT7610E. The rt2x00 driver which I'm fixing now is for MT7620A, ie. the 2.4GHz part only. MT7610E is a very crappy chip and will very certainly never be supported.
• Archer C50 v1.0 uses MT7620A + MT7612E. Here the 5 GHz part is supported by Felix' mt76 driver and the 2.4GHz is built-into the MT7620A SoC and can be used with the rt2x00 driver (which is what that kickstarter campain is all about)
• There are tons of devices which either use MT7620N (2.4GHz only, no PCIe) or MT7620A (which can be used with rt2x00) + MT7612E (ie. the _nice_ new 802.11AC 2T2R chip for 5 GHz)
• DIR860L B1 uses MT7621AT which doesn't have any built-in WiFi. They added MT7602E and MT7612E, very nice and new chips, both supported by Felix' mt76 driver. Completely different story, got nothing to do with either rt2x00 nor MT7610E. If you got reproducible problems with mt76, file a bug there and/or discuss it on lede-dev mailing list.

[Adorfer]

@dangowrt yes, there a a lot of MT7620 devices out there, support for any of those would help.
( other chips "not supported", "5GZ not supported by mt7620" or "other $CHIPSET will never be suppored" might be out of scope here)

[dangowrt]

@Adorfer I'm dog-feeding from the rt2x00 stuff and still working on it right now. Things did already get much better and after some more cleaning, the patch will be in shape for being discussed with the upstream authors/maintainers. The most obvious and significant _bug_ is missing support for TX-power temperature compensation as well as thermal throttling in the current version of our driver. Both are needed especially on devices which use MT7620 without a heatsink, because then the chip will shut down once it receives any serious traffic because of overheating (the vendor driver prevents this by throttling the speed, ie. reducing it to 1T1R and less aggregation once it gets warmer, so it never reaches the critical temperature when the chip shuts down)

[dangowrt]

and I'll try to carry out some 802.11s testing once I got some more devices flying around which may support this.

[rubo77]

you get the archer c50 for 9€ at the moment at this shop with A...

Is it usable already? maybe only 2.4GHz or only with 802.11s? that would be a great cheap option

[corny]

you get the archer c50 for 9€ at the moment at this shop with A...

I bet these are fake offers.

[psyborg55]

The most obvious and significant bug is missing support for TX-power temperature compensation as well as thermal throttling in the current version of our driver. Both are needed especially on devices which use MT7620 without a heatsink, because then the chip will shut down once it receives any serious traffic because of overheating

nothing is missing there anymore, and probably LOFT and other calibrations are not needed too.

stressing the chip for hours with approx 90-100Mbps of iperf traffic did not cause any chip shutdown.

device originated TX iperf test reached 130Mbps without any TX status or FIFO warnings in logs!

these warnings might get logged due to other factors, such as data type (TCP/UDP), packet window size, MTU/MRU, high load etc.

[dangowrt]

Actually none of the above mentioned missing features were added to rt2x00 so far (TSSI, DPD, ...), hence the infamous TX hang and other bugs still occur in the same way as they did at the time when this issue was opened (some other users do regular tests and give feedback). What has improved is the driver backport in LEDE (currently being updated by Hauke) which now includes the initial support for RT6352 (aka. MT7620) in the rt2x00 driver, so we are about to be on the same page with kernel.org instead of having tons of local patches.
Generally I do believe that we will need all of the calibration routines to achieve good results on that borked hardware.

[dangowrt]

That's good news. Can you rebase those changes on top of recent kernel.org sources? Modifying an outdated and patched-up file in your build tree might be good for a first round of tests but cannot be discussed nor merged uptream in the long term. Please consider using https://git.lede-project.org/?p=lede/dangole/staging.git;a=summary as a base as that would allow directly submitting those changes upstream (ie. though linux-wireless mailing list and the wireless-drivers-next tree)

[ambassador86]

Just for reference: the subtarget has been added in #1217

[rotanid]

closing as the target is generally supported.
please open issues for specific devices, but only if they already have support in LEDE/OpenWrt - otherwise please contact developers there (mailing list, forum) or provide patches there (mailing list, github)