MT7610E drive installation to VR200, Deck works

These messages means that "radio" partition at offset 0 contain incorrect EEPROM data. It's possible that it contain EEPROM for mt7662 wifi chipset.
Just for test you can backup radio partition and write any mt7610 refferance eeprom data from Mediatek SDK.
You can get eeprom from Padavan project

Thanks for your reply, first of all my device is Tp link archer c20 v1, 2.4ghz works fine only 5ghz radio is not showing up under wireless.
I backed up the radio. Which eeprom should i write?, i believe i need to write for mt7610e, which is the chip for 5ghz. there are two files available on the link above MT7610E-V10-FEM.bin and MT7612E_EEPROM.bin, which one should i try?

mt7610 and mt7612 are different wifi chipsets so only MT7610E-V10-FEM.bin suit you.
And for tp-link archer c20 v1 EEPROM offset is 0x8000

OK thanks, so just to be clear, i need to replace radio.bin(backed up) with MT7610E-V10-FEM.bin file correct? and start writing at offset 0x8000... is that right?

You need to overwrite data of radio partition at position 0x8000 with data of MT7610E-V10-FEM.bin file. In unix command line it may be done as follow:

dd if=MT7610E-V10-FEM.bin of=radio.bin bs=1 seek=$((0x8000)) conv=notrunc

where radio.bin is backup copy of radio partition.
Then write this new radio.bin file back to flash. To unlock read only radio partition use kmod-mtd-rw package. Something like:

opkg update
opkg install kmod-mtd-rw
insmod mtd-rw i_want_a_brick=1
mtd unlock radio
mtd write radio.bin radio

After reboot mt7610 driver will read correct EEPROM.

1 Like

I did the above, ran the commands, verified it with hex editor.. and after flashing the modified radio... 5Ghz lives.

Thu Jul  1 08:23:35 2021 kern.err kernel: [   15.242503] mt76x0e 0000:01:00.0: card - bus=0x1, slot = 0x0 irq=4
Thu Jul  1 08:23:35 2021 kernel: [   15.249059] mt76x0e 0000:01:00.0: ASIC revision: 76100002
Thu Jul  1 08:23:35 2021 kernel: [   15.301321] mt76x0e 0000:01:00.0: Firmware Version: 0.1.00
Thu Jul  1 08:23:35 2021 kernel: [   15.392138] mt76x0e 0000:01:00.0: EEPROM ver:01 fae:00

Haven't tested it much aside from noticing the transmit power being only 6 dBm. Will discuss it more once i test it further.

I have one little confusion, now that i have modified the radio partition, do i have to start the whole process (flashing modified radio partition) again, if i install a different version of openwrt or go back to stock firmware?

Thanks a lot for the help.

1 Like

No, you don't need. Neither openwrt nor stock firmware touch radio partition during installation.

1 Like

Thanks... I didn't think i would be seeing 5Ghz on this device with openwrt anytime sooner.. Anyway, i see it's not that stable. My current build is 19.07.6. My pings are almost three times higher than before, 2Ghz and 5Ghz both and random request timed out in between. There seems no unnecessary client disconnections neither hanging (at least for now).

If u have time, could u write to this topic. If can't, I'll but at least 1 month later (away from VR 200 device)
Maybe these guys help

Can we make the fix patched into the firmware somehow so that we don't need to modify the radio partition on c20 v1? With stock firmware the 5Ghz works without any modifications, shouldn't it be the same for openwrt as well?

I am not using RC3 for now, so don't know what i should ask there. Maybe later perhaps. Thanks

1 Like

Vendor driver may be configured to use default eeprom (included in source) or to read eeprom from file. Opensource driver don't contain default eeprom in source but may be configured to read eeprom from external file too.
But the main problem why radio partition was corrupted.

So the radio partition is part of eeprom? I don't understand how can it be corrupted when it can be read by stock firmware? Just for testing, i flashed the stock firmware again, and 5Ghz works fine with vendor driver(with unmodified radio partition).
I've noticed the dts file you referred to was from archer c2 v1, shouldn't that eeprom data also be present in c20 v1 dts? file?

eeprom is a part of radio partition.

Vendor driver may use default eeprom or read it from external file and don't use data from radio partition at all.

c20 v1 dts include
mt7620a_tplink_archer.dtsi with correct settings.

So what you mean is.. The vendor driver is using its source code to read default eeprom and it can also be read from radio file.. While open-source driver doesn't contain default eeprom but it can read from radio file as well.

So the radio partition was somehow corrupted which is why open source driver couldn't read default eeprom from it. We repaired the radio partition by adding the necessary eeprom data for mt7610e.

But I still don't understand how can the radio partition to be corrupted, or did it came already bad from factory?

Update: I think now understand how it happened. It's been years so I didn't think of that incident. When I first tried to install openwrt on c20v1.. I bricked it by overwriting the uboot.

The only way to recover from that was flashing the chip directly by programmer. I used the dump file from this link where the user states that ART partition is from his C50v1 and c50 v1 uses mt7612en for 5Ghz.

So all this time I was using the wrong eeprom data.
I can't think of anything else that could've corrupted the radio partition.

I think that you answer to your question yourself. You corrupt eeprom while flashing incorrect dump. :slight_smile:

Yes, i get that. But at that time there was no other flash dump available for c20v1, so i had to use that one and besides, like me many others also used his dump file to recover their c20v1 successfully.

The router worked great except for 5G radio. I didn't even looked at line Art partition is from c50v1. I just had to recover it anyhow.

So i ask you, do i still need proper flash dump for c20v1 (with Art partition from c20v1)? or should i just use the modified radio partition?


In shot. No, you don't need flash dump for c20v1.
Just longer explaination. eeprom is specific for each wifi device. It's built during calibration procedure with special equipment. Your specific data was lost so using eeprom from another device or average calibrations from wifi chip vendor make no difference practically.
Not so bad news: sometimes vendor of router device skip calibration procedure (to save time, equipment and money) and use the same MT7610E-V10-FEM.bin from wifi chip vendor.

Thanks for the explanation.. I really appreciate it.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.