mt7610e external frontend patch

[apr456]

There are extra init settings, that used in mediatek mt7610e driver and not used in mt76.

In my router this init enables external frontend in 5GHz band. Without it, tx power seems very low (i.e. connection possible only near the router). Maybe, those settings could work in other devices, too.

My device: totolink A1004NS (mt7620a + mt7610e).

Patch is attached to this message.

mt76.patch.txt

[sgruszka]

Most likely others need this as well :-) There is pending issue #216 which I hope your patch address.

[hpn0t0ad]

Confirmed working with my TP-LINK Archer C2 v1.0!
Finally we have 5GHz with usable signal strength on that device.
Really cool, thanks a lot!

[sgruszka]

@apr456 is there Mediatek vendor driver code on which your patch is based ?

[apr456]

Yes, the code is in chips/mt76x0.c, function MT76x0_ReadFlashAndInitAsic

Link:
https://github.com/presisco/mt7610e-p4rev-118062/blob/62c13fb633eda141384001acd795770cafaebbd8/src/chips/mt76x0.c#L4125

[LGA1150]

Confirmed working with HC5761 (MT7620A+MT7610E)

[orangepizza]

I wonder why @apr456 didn't create pull request with this patch?

[orangepizza]

I created pull request with this patch file, but if apr456 want request yourself I'll close the pull request.

[ThauEx]

@orangepizza could you please provide some kind of package, which can be used "fix" an existing openwrt snapshot installation?

[orangepizza]

@orangepizza could you please provide some kind of package, which can be used "fix" an existing openwrt snapshot installation?

it can't work. kernel hashes will different so opkg dependency will block its install.

[ThauEx]

So only full images would work? If so, found you provide one? Just asking, because I would like to have this fix as soon as possible and it doesn't look like, the fix is getting merged soon.

[orangepizza]

So only full images would work? If so, found you provide one? Just asking, because I would like to have this fix as soon as possible and it doesn't look like, the fix is getting merged soon.

I'll need to know what's your device name, is it's only work for that specific kernel image

[ThauEx]

Here are the details of my device: (if I should upgrade to the latest snapshot, tell me)
Model: TP-Link Archer C2 v1
Firmware Version: OpenWrt SNAPSHOT r9914-430b66bbe8 / LuCI Master (f138fc93)
Kernel Version: 4.14.113

[hpn0t0ad]

Here are the details of my device: (if I should upgrade to the latest snapshot, tell me)
Model: TP-Link Archer C2 v1

You can use my image if you like: https://drive.google.com/drive/folders/17ELnvpivUjHC2wcZiIJOwNFdRcKuzcLj

TP-Link Archer C2 v1, r10127-3209f5ae3d, kernel 4.14.123
I've included LuCI and some other stuff, see manifest or config.seed

[orangepizza]

I just finished compile
tplink c2v1.zip

[ThauEx]

I just finished compile
tplink c2v1.zip

Thank you very much, works great!

@hpn0t0ad thank you too

[WiredLife]

The patch works fine on Archer C2 v1 :D
5 GHz is now stable and power is good, but the max value is still 11 dBm.
Anyone knows the real output power?

Btw
I compiled myself r10307-629e6538a1 for TP-Link Archer C2 v1 with this patch (on current trunk), LuCI and 900-Disable-DFS.patch (patch to maximize power and disable DFS).
You can use it if you want, but you will probably break rules in your country and get caught, go in jail and die xD
https://drive.google.com/file/d/1bWEOcakeJl7xV6CwnkuD48ZdwZZ1lKrz/view?usp=sharing

[CHKDSK88]

This patch make mt7610 in D-Link DWR-118-A1 usable.

Both directions:

-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.1.105, port 48596
[  5] local 192.168.1.6 port 5201 connected to 192.168.1.105 port 48598
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec  18.8 MBytes   158 Mbits/sec
[  5]   1.00-2.00   sec  27.4 MBytes   230 Mbits/sec
[  5]   2.00-3.00   sec  27.9 MBytes   234 Mbits/sec
[  5]   3.00-4.00   sec  27.9 MBytes   234 Mbits/sec
[  5]   4.00-5.00   sec  21.9 MBytes   184 Mbits/sec
[  5]   5.00-6.00   sec  27.4 MBytes   230 Mbits/sec
[  5]   6.00-7.00   sec  27.8 MBytes   234 Mbits/sec
[  5]   7.00-8.00   sec  28.9 MBytes   242 Mbits/sec
[  5]   8.00-9.00   sec  27.6 MBytes   231 Mbits/sec
[  5]   9.00-10.00  sec  27.6 MBytes   231 Mbits/sec
[  5]  10.00-10.03  sec   930 KBytes   234 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-10.03  sec  0.00 Bytes  0.00 bits/sec                  sender
[  5]   0.00-10.03  sec   264 MBytes   221 Mbits/sec                  receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.1.105, port 48610
[  5] local 192.168.1.6 port 5201 connected to 192.168.1.105 port 48612
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec  19.2 MBytes   161 Mbits/sec
[  5]   1.00-2.00   sec  24.0 MBytes   201 Mbits/sec
[  5]   2.00-3.00   sec  27.1 MBytes   227 Mbits/sec
[  5]   3.00-4.00   sec  27.7 MBytes   232 Mbits/sec
[  5]   4.00-5.00   sec  28.7 MBytes   241 Mbits/sec
[  5]   5.00-6.00   sec  28.4 MBytes   238 Mbits/sec
[  5]   6.00-7.00   sec  28.6 MBytes   240 Mbits/sec
[  5]   7.00-8.00   sec  26.3 MBytes   221 Mbits/sec
[  5]   8.00-9.00   sec  27.7 MBytes   233 Mbits/sec
[  5]   9.00-10.00  sec  28.8 MBytes   241 Mbits/sec
[  5]  10.00-10.08  sec  2.31 MBytes   253 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-10.08  sec  0.00 Bytes  0.00 bits/sec                  sender
[  5]   0.00-10.08  sec   269 MBytes   224 Mbits/sec                  receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------

[sgruszka]

@apr456 @orangepizza , the correct way to get the patch applied is post it to linux-wireless mailing list.
I'll do this but need to know true name of @apr456 to properly sign-off-by the patch, see:
https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin

Note: Vendor driver set the registers under '#ifdef RTMP_MAC_PCI', but I tested the patch on usb MT7610U (and also on MT7630E) and did not find any problems , so I think we can take the patch as is, without additional checks regarding bus or chip version.

[orangepizza]

@apr456 @orangepizza , the correct way to get the patch applied is post it to linux-wireless mailing list.
I'll do this but need to know true name of @apr456 to properly sign-off-by the patch, see:
https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin

I don't think @apr456 will give real name, he doesn't on github much often (this and a issue create on 2017/11 is his only activity on github)

[nbd168]

I'm currently testing a reworked version of this patch, which I will push to this repo and submit upstream soon.

[nbd168]

Done

[sanitariu]

Can we make similar patch for Archer C20 but version 5 ?
There we have absolutely the same problem.

[orangepizza]

Can we make similar patch for Archer C20 but version 5 ?
There we have absolutely the same problem.

It's done on wireless chipset (mt7610e) so it should be already applied.

[sanitariu]

Yes i saw it but there must be something wrong.
Current power: 14 dBm which is 25mw ... next room you loose it.

[suppenkasper0815]

Hey guys,

in Openwrt 21.02rc4 the power of ArcherC2v1 is still 9dBm (max and driver default) for CH 36-64 and 11dBm (max and driver default) for CH 100-165. I would really love if someone could explain what is the actual state and where are still issues or what we could do to bring it into mainline soon. - There are also a few other devices on the market with that pain-in-the-ass chipset, but advantage in my opinion is the very low power consumption and worth to bring it into main support.

[sanitariu]

Actual state is that somehow 5ghz driver (mediatek 7610) is reading incorrect or not reading at all any kind of values for channel/tx-power couples and it is falling to some safe defaults.I am trying to find where is this happening but until now .... not much of a luck. The only "solution" i find out is to touch mt76x0/eeprom.c and change:
/* vht mcs 8, 9 5GHz /
/ val = mt76x02_eeprom_get(dev, 0x132); */
val = 23;
t->vht[8] = s6_to_s8(val);
t->vht[9] = s6_to_s8(val >> 8);

Now i see good values in luci and console using iw phy like these:

	Frequencies:
		* 5180 MHz [36] (22.0 dBm)
		* 5200 MHz [40] (21.0 dBm)
		* 5220 MHz [44] (21.0 dBm)
		* 5240 MHz [48] (20.0 dBm)
		* 5260 MHz [52] (19.0 dBm) (radar detection)
		* 5280 MHz [56] (19.0 dBm) (radar detection)
		* 5300 MHz [60] (19.0 dBm) (radar detection)
		* 5320 MHz [64] (19.0 dBm) (radar detection)
		* 5500 MHz [100] (disabled)
		* 5520 MHz [104] (disabled)
		* 5540 MHz [108] (disabled)
		* 5560 MHz [112] (disabled)
		* 5580 MHz [116] (disabled)
		* 5600 MHz [120] (disabled)
		* 5620 MHz [124] (disabled)
		* 5640 MHz [128] (disabled)
		* 5660 MHz [132] (disabled)
		* 5680 MHz [136] (disabled)
		* 5700 MHz [140] (disabled)
		* 5720 MHz [144] (disabled)
		* 5745 MHz [149] (24.0 dBm)
		* 5765 MHz [153] (24.0 dBm)
		* 5785 MHz [157] (24.0 dBm)
		* 5805 MHz [161] (24.0 dBm)
		* 5825 MHz [165] (24.0 dBm)
		* 5845 MHz [169] (disabled)
		* 5865 MHz [173] (disabled)

I do not know exactly if this is working correct.

[hpn0t0ad]

Although patching eeprom.c does increase the values reported by iw, it does not seem to influence the actual txpower, i.e. the signal strength as seen by the clients remains unchanged.

this is what iw reports with the patch (regdomain PA)

                        * 5180 MHz [36] (20.0 dBm)
                        * 5200 MHz [40] (20.0 dBm)
                        * 5220 MHz [44] (20.0 dBm)
                        * 5240 MHz [48] (19.0 dBm)
                        * 5260 MHz [52] (19.0 dBm)
                        * 5280 MHz [56] (19.0 dBm)
                        * 5300 MHz [60] (19.0 dBm)
                        * 5320 MHz [64] (19.0 dBm)
                        * 5500 MHz [100] (20.0 dBm)
                        * 5520 MHz [104] (20.0 dBm)
                        * 5540 MHz [108] (20.0 dBm)
                        * 5560 MHz [112] (20.0 dBm)
                        * 5580 MHz [116] (20.0 dBm)
                        * 5600 MHz [120] (20.0 dBm)
                        * 5620 MHz [124] (20.0 dBm)
                        * 5640 MHz [128] (20.0 dBm)
                        * 5660 MHz [132] (20.0 dBm)
                        * 5680 MHz [136] (20.0 dBm)
                        * 5700 MHz [140] (20.0 dBm)
                        * 5720 MHz [144] (20.0 dBm)
                        * 5745 MHz [149] (20.0 dBm)
                        * 5765 MHz [153] (20.0 dBm)
                        * 5785 MHz [157] (20.0 dBm)
                        * 5805 MHz [161] (20.0 dBm)
                        * 5825 MHz [165] (20.0 dBm)
                        * 5845 MHz [169] (disabled)
                        * 5865 MHz [173] (disabled)

[sanitariu]

Seems like we will wait for proper fix from nbd or other. At least seems like the driver is stable and for 3 days i have no crash.

[namidairo]

Actual state is that somehow 5ghz driver (mediatek 7610) is reading incorrect or not reading at all any kind of values for channel/tx-power couples and it is falling to some safe defaults.

I believe the VHT80 power delta offset for MT7610 might be wrong, a quick look shows that it could be 0xD3 instead of 0x52

Edit: Never mind, this looks correct https://github.com/openwrt/mt76/blob/master/mt76x0/eeprom.c#L136

val = mt76x02_eeprom_get(dev, 0x132);

I think this might also be wrong as well.

The MCS9 is the 5Ghz rate base (0x120) + 12, but it looks like we've gone and done 0x120 + 0x12 instead?

@nbd168 Could you check these two with the documentation you have?

[Neustradamus]

To follow this ticket