LNA issue with MT7620N on Asus RT-N12E B1

dj-l · May 29, 2021, 10:58pm

Hi all =D

I just wanted to install OpenWrt on my Asus RT-N12E B1 with MediaTek MT7620N inside, one week ago. I realized that the RX wifi signal is very bad. If a connected client has a distance of less than 0.25 meters from the antennas of the router, I get around -88 dBm RX on router side. The TX signal of the Asus router, measured on client side, is very strong. If I am around 1 meter far away the RSSI (RX signal on router side) is around -94 dBm and the wifi will be disconnected.

I looked into the sources of the MT76 MAC80211 drivers at https://github.com/openwrt/mt76 and RT6352 (which seems to be inside the MT7620N) at https://github.com/torvalds/linux/blob/master/drivers/net/wireless/ralink/rt2x00/ . I found out that there was removed an AGC calibration in the RT2x00 driver https://github.com/torvalds/linux/commit/5991a2ecd070ce5ef646b4e8e0bc8d99110604ed . If I patch it back, I can improve the signal distance from 1 meter to around 3 meters. The visible RSSI inside OpenWrt does not change. After patching, just the disconnection threshold of the wifi is now by around -105 dBm RSSI, instead of -94 dBm.

But 3 meters are also very bad. But I don't know what's going wrong. My current consideration is, that there exist an external LNA in the Asus RT-N12E B1, which is not configured by the MT76 driver or RT2x00 driver. I found something here https://github.com/lede-project/source/commit/b367eef21dccbc5115778001955847ac3af47db8 .

Another issue is, that I don't have any specs for the Register Maps. The AGC for example is configured to a BBP Register 66. BBP means Broadband Processor, but I don't know which Vendor and IP it is, inside the MT7620N. Therefore I can't google for a programming manual. The programming manual of the MT7620N just says that BBP registers 0x0000-0x0200 are "Reserved".

So here are coming the big questions, which could help

Does anybody know, if the Asus RT-N12E B1 with an MT7620N inside is using an external LNA? Or how can I find it out?
Does anybody knows, where I can download a Register Map Manual of the MT7620N? I downloaded the "MT7620 Programming Guide", but many registers are not documented, i.e. the BBP Registers (page, 369).
Any other ideas what to do? Any experiences in such cases?

Thanks for every hint,
Dirk =)

daniel · May 30, 2021, 1:01am

Hi Dirk,

what you describe sounds very much like LNA not being setup correctly and/or calibration data being completely wrong. I don't know that device myself, but just checking https://fcc.io/MSQ/-RT1901 internal photos show straight RF paths with just some tiny SMD resistors and capacitors as filters, but no LNA/mixer chip.

The driver in charge of the Ralink RT6352 WiFi IP contained in the the MT7620 SoC family is rt2x00. Only later variants developed by MediaTek are supported by the mt76 driver (MT7610 being apparently the exception there).

In all the years of dealing with those chips I have never come across a datasheet covering register definitions of the BBP, RFCSR and RF parts. I assume that the vendor driver is the only reference we can refer to, and there are variants which are in better shape than what you find the original SDK

There are some obvious things still missing in rt2x00 which are covered by the vendor driver. TSSI (temperature sensor and compensation measures) are the most important when i. comes to range/tx-power issues.

Regarding what to do:
If you have time and nerves for it, setup an Ubuntu 16.04 VM or container, clone wive-ng-mt, spray the wifi driver with educative printfs, build and run the result. Then try to learn from it and improve rt2x00.
Of course, this works best if you have two identical devices, one running the vendor reference plus your debugging/introspection code added and one running OpenWrt with rt2x00 giving you similar debugging output, e.g. about writing certain registers, so you can diff the results.

dj-l · May 30, 2021, 2:21am

Hey Daniel,

yeah nice. Thanks for the reference to the wive-ng-mt driver ... After a short view to it, I'm straight looking forward. I try to learn from the wive-ng-mt driver and try to get the differences. I report my state here, if I'm progressing

dj-l · July 15, 2021, 3:09pm

Hi ladies and gentleman xD

here comes an update to this issues and some questions

Analytics

okay well, I got the Wive-NG firmware compiled and working on my Asus RT-N12E B1 router. It works very well without the "LNA issue" (seems to be more an calibration issue with my current knowledge). I have filled the rt6352.c from Wive-NG with DBGPRINT(RT_DEBUG_TRACE)'s and logged the RTMP_BBP_IO_WRITE8_BY_REG_ID() with klogd/syslogd for many situations, such like $> wifi up/down, connections, etc.

After that I realized that the LNA/calibration issue does not occur anymore on OpenWrt and seems to be fixed. I used the same OpenWrt squash image (sha1sum verified) as before. Also the stock firmware (following "Stock") is working too as before. But curiously now, OpenWrt and Stock are using other MAC addresses for LAN/WAN/wifi adapters. So I got the idea that Wive-NG has flashed an (EEP-)ROM, which OpenWrt and Stock may are not doing. Next step I've done was to find out where the MAC addresses are located and found that there are located at the MTD block mtd2, which is called factory partition in OpenWrt https://github.com/openwrt/openwrt/blob/9ec5f5f230851ef9c980e99a43c3ddffca50a7fc/target/linux/ramips/dts/mt7620n_asus_rt-n12p.dts#L93

For tests, I erased the factory partition and tried to boot all three firmwares. The result: Stock will be not full booting up anymore. OpenWrt is not getting up the wifi adapter anymore, as aspected as I read in the OpenWrt documentation https://openwrt.org/docs/techref/flash.layout#explanations (on Ralink: mtd4 -> mtd2 and art -> factory)

"mtd4 for the ART (Atheros Radio Test) - it contains calibration data for the wifi (EEPROM). If it is missing or corrupt, ath9k (wireless driver) won't come up anymore."

Just the Wive-NG firmware is still fully working, by recovering the whole factory partition. I could locate the raw BIN data for it in the source as static C-array of the mt76x2+rt6352 driver in Wive-NG, called RT6352_EeBuffer[] which will be set to pPRTMP_ADAPTER->chipCap.EEPROM_DEFAULT_BIN in RT6352_Init() https://gitlab.com/Ntemis/wive-ng-mt/-/blob/master/linux-3.4.x/drivers/net/wireless/ralink/mt76x2/chips/rt6352.c#L37

As you can see, you can locate the default MAC addresses (which will be patched be Wive-NG, but NOT by OpenWrt and Stock!) at offset RT6352_EeBuffer[4..9] = 00:0c:43:76:e8:72 for the primary MAC which is used for wifi. It's a Ralink Technology reserved MAC address. There are also 2 secondary MAC addresses at RT6352_EeBuffer[40..45] and RT6352_EeBuffer[46..51].

The Wive-NG driver writes this raw BIN data to an EEPROM pPRTMP_ADAPTER->EEPROMImage during Set_LoadEepromBufferFromBin_Proc() at https://gitlab.com/Ntemis/wive-ng-mt/-/blob/master/linux-3.4.x/drivers/net/wireless/ralink/mt76x2/common/eeprom.c#L464

These data seems to be used for calibrating the wifi of the MT7620, as you can see in mt76x2_cal_free_data_get() at https://gitlab.com/Ntemis/wive-ng-mt/-/blob/master/linux-3.4.x/drivers/net/wireless/ralink/mt76x2/chips/mt76x2.c#L5048

Conclusion

With my current experience and knowledge I am really sure, that the Stock factory partition was corrupted, from the OpenWrt point of view. The overwritten factory partition is working well with all firmwares, I have tested: OpenWrt, Stock and Wive-NG itself. But I didn't backup the Stock factory partition before I booted up Wive-NG, which enforces to overwrite it. Therefore, I can't reconstruct the issue and can not locate it in more detail. So it would be very helpful if anybody can provide a dump of a Stock factory/mtd2 partition.

Without it, I currently have no related issues anymore. But OpenWrt itself does not fix it. How could a fix working? The OpenWrt Documentation says, that OpenWrt won't bring up wifi adapters with corrupted factory partitions. On the other hand it was a Stock partition, so it may be not broken and a bug in the OpenWrt driver.

If the OpenWrt wifi driver should fix the partition, then the next question is where the fix should be implemented? I think the calibration data are depending on the SoC MT7620N and not on the wifi RT6352 itself. Also in the Wive-NG driver, the BIN image is located in mt76x2/chips/rt6352.c. The driver structure in OpenWrt seems not to be the same. On a short look to the OpenWrt driver structure, I think the BIN data should be located in openwrt/mt76 sub-project. But currently the Ramips / mt7620n_asus_rt-n12p is not using that driver and I would need some instructions/tutorial how make use of the mt76 driver in OpenWrt for the ramips / mt7620n_asus_rt-n12p target.

Questions

Can anyone provide a dump of the Stock factory/mtd2-partition from an Asus RT-N12E B1 for reconstructing the LNA/calibartion?
Should corrupted factory partitions be fixed by the OpenWrt drivers?
If yes: Where should the fix be implemented, which driver? openwrt/mt76 is currently not loaded on Asus RT-N12E B1.
Exist a tutorial which describes, how to make use of a new driver for a existing target machine?

Thanks for reading and hopefully some ideas,
Dirk =)

daniel · July 16, 2021, 4:23pm

What we are dealing with is most likely a vendor-modified version of Ralink's proprietary driver.
Doing as Wive-NG does -- just replacing EEPROM-data -- is not really a good option, as we loose calibration which is specific for the board as well as the antenna(s) used.

What we need to do now is hard to judge without having seen the vendor's factory partition content. Maybe we just miss a single bit it to enable external LNA, maybe it's completely different and we would have to add support for yet another different EEPROM layout in the driver.

So for now, lets hope that someone comes up with a dump....

dj-l · July 21, 2021, 11:06pm

Hi Daniel, hi community,

I have written a detailed HowTo dump the factory-partition /dev/mtd2 using either the Asus stock firmware or at your option OpenWrt, here Asus RT-N12E B1: dump of factory-partition (/dev/mtd2) required

But additionally, I'm currently not happy with the current situation. On the one hand I think, as Daniel that drivers should not touch the factory partition, it would be an mistake from the point of software engineering. But on the other hand, in practice it is currently not possible to fix that issue in the current situation without using a third-party firmware.

Idea

My current idea is to implement three module parameters for the Ralink driver, maybe in the rt2800lib kernel mod?! I need to look where is the best place. The first parameter factory-image=/etc/ralink/mt7620n/factory.bin is a file-path in the user space, where to find a *.bin factory-dump which could be loaded during module_init(). If that file does not exist in the mounted user space file system, then it will be ignored and the driver does work as before. If that file exist it will be used and patched i.e. with the original MAC-addresses of the router, etc. But not be flashed onto the /dev/mtd2 partition.

The second module parameter could be factory-image-nopatch=1, default is 0. If it is set, then the loaded factory image will be not patched, i.e. the MAC-addresses of the *.bin image will be used, etc.

The third module parameter could be factory-image-FORCE-FLASH=1, default is 0. If it is set, then the loaded *.bin image will be really non-recoverable flashed onto /dev/mtd2 after a backup was dumped to the RW file system if an backup file does not yet. klogd should report that.

The default configuration of OpenWrt maybe, that the module will be loaded with $> modprobe rt2800lib factory-image=/etc/ralink/mt7620n/factory.bin, without delivering a factory.bin file. Also, then there are no copyright issues. The OpenWrt user just need to copy the target/linux/ramips/base-files/etc/ralink/mt7620n/factory.bin to the source tree and build (not tested yet) -- or copy the /etc/ralink/mt7620n/factory.bin to the running OpenWrt system and reload the mod. Thats the current idea.

If you need the behavior of the Wive-NG firmware then the module should be loaded like this $> modprobe rt2800lib factory-image=/etc/ralink/mt7620n/factory.bin factory-image-nopatch=1 factory-image-FORCE-FLASH=1.

Workflow

I just try to begin to implement this idea in an own forked Linux kernel tree. I have seen that there exist the variable $(CONFIG_EXTERNAL_KERNEL_TREE) in the kernel configuration, which I could use. That Linux fork should be then able to use by you/third-party using the configuration variable $(CONFIG_KERNEL_GIT_CLONE_URI). Also, if it will be accepted by the community, then it maybe included as kernel patch into OpenWrt and/or merged into the official Linus kernel tree.

If I progressed I'm replying here
greets Dirk =)

daniel · July 22, 2021, 10:15am

I think the best would be to ask the vendor for GPL sources and see (together with the recovered original factory partition) how they are dealing with EEPROM fields. Then we can (hopefully) recognize the differences in EEPROM format (maybe it's just the LNA and/or PA bits) and deal with it in rt2x00 -- there are already some work-arounds for vendor-specific EEPROM modifications and Ralink themselves also came up with at least two entirely different EEPROM formats, we support both (in the driver, MT7620 is always using the newer format, but maybe that device is an exception to that rule).

Solving the problem by adding additional module parameters and/or side-loading an EEPROM-data file which doesn't match the board isn't such a good idea imho. If what we are dealing with really cannot be probed/recognized at run-time in the driver, we should add some flag in device-tree to tell the driver how to parse the existing EEPROM.

Also note that the rt2x00 driver in OpenWrt is not built in-tree from Linux sources. It's an out-of-tree package, usually much newer than what is shipped with the kernel. Take a look at package/kernel/mac80211/patches/rt2x00 to get an idea how to modify the driver.

dj-l · July 25, 2021, 7:42pm

Hi Daniel,

okay I have asked the Asus specification support the following questions:

If they can provide a backup of a valid factory-partition /dev/mtd2?
If they can provide a specification of the data-layout for the factory-partition /dev/mtd2?
Or in best case, if they can provide a OpenSource/GPL licensed driver for the RT6352 wireless logic inside the SoC MT7620N?

As long I'm waiting for an answer I progress my current idea above. For that, I have currently a question:

I have seen, that the OpenWrt driver at package/kernel/mac80211/patches/rt2x00 is just provided as a series of patches. How is the default workflow to insert a patch into the series of patches? Or does exist a repository for it, from which these patches were exported?

Greets Dirk.

lukasz92 · July 26, 2021, 7:34am

GPL: https://drivers.eu/Network/ASUS/RT-N12E_B1 , but you will not find definitions for this model in dump - possible some other device has almost the same firmware.

Asus tweaks official source code from Mediatek - you can forget about sourcecode of these tweaks. Source code of official Mediatek driver for this chip can be found on some leaks.

dj-l · July 27, 2021, 9:40pm

Hey Lukasz,

thanks for the link to the GPL sources. It seems to be the sources of the Asus Stock firmware. I took a look to it. The syslog of it tells me that it is using the rt2860v2 driver for the RT6352 wifi logic. But the sources of that driver are not delivered in the GPL firmware. Instead the GPL Stock firmware seems to be linked against the compiled object file drivers/net/wireless/.objs/rt2860v2_ap.obj (without debugging symbols) which is delivered in that package. Also a compiled version of the whole rt2860v2_{sta,ap}.ko is delivered in the skeleton for the sqashfs root in asustools/squashfs-root/.

It is possible to extract symbol information and disassemble the rt2860v2_ap.obj using the objdmup delivered in tools/brcm/K26/hndtools-mipsel-uclibc-4.2.4/bin/mipsel-uclibc-objdump. The relocation information says that the rt2860v2_ap.obj needs to be linked together with an RT635x and RT6352 library which also seems not to be delivered in the GPL Stock firmware, neither as source code nor as binary object; maybe just as a not-exported binary inside the rt2860v2_{ap,sta}.ko kernel module.

As so far, I'm trying to look if I can extract some necessary information related to the factory-partition layout from the rt2860v2_ap.obj.

The Asus support has expanded my request to next-level and it seems to go to a laboratory now. I hope that they can provide at least an official valid factory-partition /dev/mtd2, that I can reproduce the initial low RSSI issue on OpenWrt.

lukasz92 · July 28, 2021, 8:55am

Hi dj-l, if you find any reference in configuration to internal/external LNA and PA (and what changes do the setting introduce to the driver), that it could be a good point. But I think they are only about singlesku files, the oem driver references (which every mt76* and rt2800* driver does not use).

rt2860v2_ap.obj is almost complete ko file.
Driver uses only factory partition, which you have to define in MTD maps (already done).

Asus would not provide source for rt2860v2_ap.obj