wifi: mt76: mt7615: fix MT7663 PCIe embedded EEPROM loading by davkdavk · Pull Request #1063 · openwrt/mt76

davkdavk · 2026-03-08T11:23:18Z

Summary

fix MT7663 PCIe boards that store the WiFi EEPROM image inside the factory partition at offset 0x8000
use an early PCI probe flag for PCI ID 14c3:7663 so the fallback does not depend on EEPROM contents
fall back to reading the full factory partition (or mtd2) when mediatek,mtd-eeprom is not present

Problem

On a Wavlink WL-WN575A3 Rev B running OpenWrt 25.12.0, the MT7663 PCIe radio (PCI ID 14c3:7663) was loaded by mt7615e, but the driver read an empty or invalid EEPROM image from the default path.

The actual MT7663 EEPROM image is embedded in the factory partition at offset 0x8000.

Because the driver did not load that embedded image:

the MAC address was invalid and randomized on every boot
the firmware received incorrect EEPROM data
5 GHz throughput was severely degraded

EEPROM analysis

Observed layout in factory:

partition: factory (mtd2)
size: 0x10000
MT7663 EEPROM image offset: 0x8000
MT7663 header at 0x8000: 0x7663
MAC at 0x8004: 80:3f:5d:33:90:32

Before

dmesg:

mt7615e 0000:01:00.0: Invalid MAC address, using random address ...

Observed throughput:

~11 Mbps down
~45 Mbps up

After

The driver now:

detects the MT7663 PCIe variant from PCI probe
reads the full factory partition when the DT lacks mediatek,mtd-eeprom
loads the embedded EEPROM image from 0x8000

Observed validation log:

mt7663 debug: reg_map=mt7663 rev=0x76630010 chip=0x7663 initial header=0x0000 mac=00:00:00:00:00:00
mt7663 debug: fallback probe enabled for embedded EEPROM
mt7663 debug: mediatek,mtd-eeprom missing, reading full factory partition
mt7663 debug: probe offset 0x8000 header=0x7663 mac=80:3f:5d:33:90:32
found embedded MT7663 EEPROM at offset 0x8000

Observed results:

correct stable MAC address: 80:3f:5d:33:90:32
5 GHz throughput improved from ~11 Mbps to ~84 Mbps

Notes

This change is targeted at MT7663 PCIe boards whose EEPROM is embedded in factory at 0x8000 and that do not expose the usual mediatek,mtd-eeprom binding.

Some MT7663 PCIe boards store the WiFi EEPROM image inside the factory partition at offset 0x8000 instead of exposing it through the usual mediatek,mtd-eeprom binding. Record the PCI probe result early and fall back to reading the full factory/mtd2 partition so the driver can load the embedded 0x7663 EEPROM image with the correct MAC address and power calibration data. Signed-off-by: David Kearsley <thadavhjb@gmail.com>

MT7663 currently bypasses the computed per-rate power limits when building the MCU SKU table and fills every entry with a flat txpower value. Drop that special case so the firmware receives the EEPROM-derived OFDM/HT/VHT power limits that are already parsed by the driver. Signed-off-by: David Kearsley <thadavhjb@gmail.com>

Djfe · 2026-03-15T12:17:48Z

Just wondering, since I'm not a maintainer:
Can't the EEPROM loading be fixed within the DTS? I mean it already specifies the offset of 0x8000.
https://github.com/openwrt/openwrt/blob/7824dbcab815a6fa605b6cecf94c200b9d3973f7/target/linux/ramips/dts/mt7628an_wavlink_wl-wn575a3.dts#L113

please send patches to mt76 to the linux kernel wireless mailing list
This github repo does not merge pull requests at all.

see for examples:
https://patchwork.kernel.org/project/linux-wireless/list/?order=date&state=*

Djfe · 2026-03-15T12:19:51Z

I meant to send this link instead
https://patchwork.kernel.org/project/linux-wireless/list/?series=&submitter=&state=*&q=&archive=both&delegate=

davkdavk · 2026-03-15T13:20:59Z

The Wavlink WL-WN575A3 Rev B has a MediaTek MT7663 PCIe 5GHz chip. The OpenWrt mt76 driver couldn't find its calibration data (EEPROM) because the MT7663 data sits at offset 0x8000 in the factory MTD partition, not at offset 0x0000 where the driver normally looks. Without valid calibration data the driver fell back to a random MAC address and ran at 3 dBm TX power instead of the calibrated ~23 dBm. Fix Patched mt7615/eeprom.c in the mt76 package with three changes: Added mt7615_read_factory_partition() — reads the full factory MTD partition into a buffer as a fallback when the normal OF/DT EEPROM load fails In mt7615_eeprom_load(), when the device is MT7663, check offset 0x8000 for the 0x7663 signature and if found, copy MT7663_EEPROM_SIZE bytes from there into the driver's EEPROM buffer Removed the mt7615_check_eeprom() guard and the is_valid_ether_addr() check that were blocking the fallback path from ever firing Confirmed working when dmesg shows: mt7615e 0000:01:00.0: found embedded MT7663

…

On Sun, 15 Mar 2026, 10:50 pm Felix Baumann, ***@***.***> wrote: *Djfe* left a comment (openwrt/mt76#1063) <#1063 (comment)> I meant to send this link instead https://patchwork.kernel.org/project/linux-wireless/list/?series=&submitter=&state=*&q=&archive=both&delegate= — Reply to this email directly, view it on GitHub <#1063 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BVLH7SSOG6BPUZQ7FO2MLU34Q2NX3AVCNFSM6AAAAACWK4ZN5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANRSHA4DENZSGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

Djfe · 2026-03-15T19:33:52Z

weird, why does the driver not look at the offset that is defined in the nvmem partition (0x8000)? @neheb @Ansuel do you maybe have an idea? (sorry to bother you but you worked on the nvmem implementation for eeprom/calibration data iirc)

Djfe · 2026-03-15T19:35:04Z

In the meantime: could you upload the factory partition to github maybe? (zipped img file or so)

neheb · 2026-03-15T19:48:09Z

Sounds like a bug. Nvmem eeprom loading works absolutely fine.

davkdavk · 2026-03-16T03:24:57Z

Loading OpenWRT on a WL-WN575A3 loads a bung kernel module and I only get 3mw output. I have been working with OpenCode as I have been interested in fixing the issues on my own device, and hopefully this leads to a global fix for others as well.. From OpenCode Subject: mt76: mt7615: MT7663 EEPROM not loaded on boards with factory partition offset 0x8000 Board: Wavlink WL-WN575A3 Rev B Chip: MediaTek MT7663 (PCIe, driven by mt7615e) OpenWrt version: 25.12-SNAPSHOT Problem: On this board the MT7663 calibration EEPROM is embedded in the factory MTD partition at offset 0x8000, not at 0x0000. The mt7615 driver's normal EEPROM load path fails because it looks at the wrong offset. With no valid EEPROM the driver falls back to a random MAC address and runs at 3 dBm TX power instead of the calibrated ~23 dBm. Root cause: mt7615_eeprom_load() in mt7615/eeprom.c does not attempt to read the factory MTD partition directly when the normal OF/DT load fails. The 0x7663 signature and all valid calibration data including TX power tables are present at offset 0x8000 in the factory partition but the driver never reads from there. Fix: Add a mt7615_read_factory_partition() helper that reads the full factory MTD partition (by name, falling back to MTD device 2) In mt7615_eeprom_load(), when the device is MT7663 and normal EEPROM load fails, check offset 0x8000 for the 0x7663 LE16 signature If found, copy MT7663_EEPROM_SIZE bytes from that offset into dev->mt76.eeprom.data Do not gate this path on mt7615_check_eeprom() or is_valid_ether_addr() — the EEPROM at 0x8000 is valid even though the data at 0x0000 is not Confirmed working on device when dmesg shows: mt7615e 0000:01:00.0: found embedded MT7663 EEPROM at offset 0x8000 Result: correct MAC address 80:3f:5d:33:90:32, TX power 23 dBm, stable VHT80 5GHz on channel 44. MTD layout for reference: mtd2 = factory (64KB) 0x0000: MT7628 2.4GHz calibration (header 0x7628) 0x8000: MT7663 5GHz calibration (header 0x7663) I hope this helps Dave

…

On Mon, 16 Mar 2026, 6:18 am Rosen Penev, ***@***.***> wrote: *neheb* left a comment (openwrt/mt76#1063) <#1063 (comment)> Sounds like a bug. Nvmem eeprom loading works absolutely fine. — Reply to this email directly, view it on GitHub <#1063 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BVLH7SX5QP4XF7KTG4QZJFL4Q4CJBAVCNFSM6AAAAACWK4ZN5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANRTG43DCNZZGE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

davkdavk · 2026-03-16T03:26:16Z

It also had to switch kernel modules.

…

On Mon, 16 Mar 2026, 1:54 pm davkdavk, ***@***.***> wrote: Loading OpenWRT on a WL-WN575A3 loads a bung kernel module and I only get 3mw output. I have been working with OpenCode as I have been interested in fixing the issues on my own device, and hopefully this leads to a global fix for others as well.. From OpenCode Subject: mt76: mt7615: MT7663 EEPROM not loaded on boards with factory partition offset 0x8000 Board: Wavlink WL-WN575A3 Rev B Chip: MediaTek MT7663 (PCIe, driven by mt7615e) OpenWrt version: 25.12-SNAPSHOT Problem: On this board the MT7663 calibration EEPROM is embedded in the factory MTD partition at offset 0x8000, not at 0x0000. The mt7615 driver's normal EEPROM load path fails because it looks at the wrong offset. With no valid EEPROM the driver falls back to a random MAC address and runs at 3 dBm TX power instead of the calibrated ~23 dBm. Root cause: mt7615_eeprom_load() in mt7615/eeprom.c does not attempt to read the factory MTD partition directly when the normal OF/DT load fails. The 0x7663 signature and all valid calibration data including TX power tables are present at offset 0x8000 in the factory partition but the driver never reads from there. Fix: Add a mt7615_read_factory_partition() helper that reads the full factory MTD partition (by name, falling back to MTD device 2) In mt7615_eeprom_load(), when the device is MT7663 and normal EEPROM load fails, check offset 0x8000 for the 0x7663 LE16 signature If found, copy MT7663_EEPROM_SIZE bytes from that offset into dev->mt76.eeprom.data Do not gate this path on mt7615_check_eeprom() or is_valid_ether_addr() — the EEPROM at 0x8000 is valid even though the data at 0x0000 is not Confirmed working on device when dmesg shows: mt7615e 0000:01:00.0: found embedded MT7663 EEPROM at offset 0x8000 Result: correct MAC address 80:3f:5d:33:90:32, TX power 23 dBm, stable VHT80 5GHz on channel 44. MTD layout for reference: mtd2 = factory (64KB) 0x0000: MT7628 2.4GHz calibration (header 0x7628) 0x8000: MT7663 5GHz calibration (header 0x7663) I hope this helps Dave On Mon, 16 Mar 2026, 6:18 am Rosen Penev, ***@***.***> wrote: > *neheb* left a comment (openwrt/mt76#1063) > <#1063 (comment)> > > Sounds like a bug. Nvmem eeprom loading works absolutely fine. > > — > Reply to this email directly, view it on GitHub > <#1063 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/BVLH7SX5QP4XF7KTG4QZJFL4Q4CJBAVCNFSM6AAAAACWK4ZN5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANRTG43DCNZZGE> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

neheb · 2026-03-16T03:30:41Z

Instead of this hack solution, please use nvmem. It's already implemented.

davkdavk · 2026-03-16T03:33:28Z

Sorry if I have caused an issue . Will look at NVMEM

…

On Mon, 16 Mar 2026, 2:01 pm Rosen Penev, ***@***.***> wrote: *neheb* left a comment (openwrt/mt76#1063) <#1063 (comment)> Instead of this hack solution, please use nvmem. It's already implemented. — Reply to this email directly, view it on GitHub <#1063 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BVLH7SXXVNYVS6LAJCYHHGT4Q5YPRAVCNFSM6AAAAACWK4ZN5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANRUHAZDSNZRGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

davkdavk · 2026-03-16T05:48:04Z

*The bug is the size — 0x200 is 512 bytes but MT7663_EEPROM_SIZE is 0x400 (1024 bytes).* The cell is too small so the driver rejects it.

…

eeprom_factory_8000: ***@***.*** { > reg = <0x8000 0x200>; > };Message ID: ***@***.***> >

Djfe · 2026-03-17T00:24:45Z

@neheb the dts for the device already gets it from nvmem using the 0x8000 offset which is why I was confused why a custom function should be necessary.
https://github.com/openwrt/openwrt/blob/7824dbcab815a6fa605b6cecf94c200b9d3973f7/target/linux/ramips/dts/mt7628an_wavlink_wl-wn575a3.dts#L68

@davkdavk great find

according to this it's 0x600, I think. (1536)
The thing is: that is just the maximum length that should not be exceeded, no?
how large is the section in the factory partition on the flash of your wavlink actually? (the section that starts at 0x8000 within that partition)
If it's not larger than 0x200 (defined in the dts) then it should be fine

neheb · 2026-03-17T00:45:23Z

So the actual bug is

					eeprom_factory_8000: eeprom@8000 {
						reg = <0x8000 0x200>;
					};

needs to be 600.

openwrt/openwrt@65cd6a6

says it's 4da8.

ping @DragonBluep

DragonBluep · 2026-03-17T00:53:14Z

So the actual bug is
					eeprom_factory_8000: eeprom@8000 {
						reg = <0x8000 0x200>;
					};
needs to be 600.

openwrt/openwrt@65cd6a6

says it's 4da8.

ping @DragonBluep

Yes. If you are interested, you can insert some debugging code into mt76 to print its size len.

mt76/eeprom.c

Line 154 in d2b1e1a

static int mt76_get_of_eeprom(struct mt76_dev *dev, void *eep, int len)

neheb · 2026-03-17T00:59:41Z

git grep 0x8000\ 0x | grep -v 0x200 | grep -v 0x4da8
dts/mt7628an_yuncore_cpe200.dts:						reg = <0x8000 0x600>;

sounds like that's wrong then.

DragonBluep · 2026-03-17T02:41:14Z

git grep 0x8000\ 0x | grep -v 0x200 | grep -v 0x4da8
dts/mt7628an_yuncore_cpe200.dts:						reg = <0x8000 0x600>;

sounds like that's wrong then.

Please PR to fix them. Incorrect eeprom size can result in very low tx power, about 3 dBm. Acked-by: Shiji Yang <yangshiji66@outlook.com>.

davkdavk · 2026-03-17T05:00:38Z

Thanks for the reply. I am a novice when it comes to coding. If there is someone that can shed more light on this, that would be great. I have tried various fixes and for the meantime I've had to do the hack just to get my own personal hotspot going .. happy to help and provide test results if needed

…

On Tue, 17 Mar 2026, 10:55 am Felix Baumann, ***@***.***> wrote: *Djfe* left a comment (openwrt/mt76#1063) <#1063 (comment)> @neheb <https://github.com/neheb> the dts for the device already gets it from nvmem using the 0x8000 offset which is why I was confused why a custom function should be necessary. https://github.com/openwrt/openwrt/blob/7824dbcab815a6fa605b6cecf94c200b9d3973f7/target/linux/ramips/dts/mt7628an_wavlink_wl-wn575a3.dts#L68 @davkdavk <https://github.com/davkdavk> great find according to this <https://github.com/openwrt/mt76/blob/d2b1e1aa8ec4636fb216194120ea0ed74fc8b094/mt7615/mt7615.h#L54> it's 0x600, I think. (1536) The thing is: that is just the maximum length that should not be exceeded, no? how large is the section in the factory partition on the flash of your wavlink actually? (the section that starts at 0x8000 within that partition) If it's not larger than 0x200 (defined in the dts) then it should be fine — Reply to this email directly, view it on GitHub <#1063 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BVLH7SQYSW6SWLROTU2TL7T4RCLOJAVCNFSM6AAAAACWK4ZN5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANZRGQ4TOOJTGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

neheb · 2026-03-17T05:27:48Z

openwrt/openwrt#22463

davkdavk added 2 commits March 8, 2026 21:46

neheb mentioned this pull request Mar 17, 2026

ramips: cpe200: fix eeprom size openwrt/openwrt#22459

Merged

Conversation

davkdavk commented Mar 8, 2026

Summary

Problem

EEPROM analysis

Before

After

Notes

Uh oh!

Djfe commented Mar 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Djfe commented Mar 15, 2026

Uh oh!

davkdavk commented Mar 15, 2026 via email

Uh oh!

Djfe commented Mar 15, 2026

Uh oh!

Djfe commented Mar 15, 2026

Uh oh!

neheb commented Mar 15, 2026

Uh oh!

davkdavk commented Mar 16, 2026 via email

Uh oh!

davkdavk commented Mar 16, 2026 via email

Uh oh!

neheb commented Mar 16, 2026

Uh oh!

davkdavk commented Mar 16, 2026 via email

Uh oh!

davkdavk commented Mar 16, 2026 via email

Uh oh!

Djfe commented Mar 17, 2026

Uh oh!

neheb commented Mar 17, 2026

Uh oh!

DragonBluep commented Mar 17, 2026

Uh oh!

neheb commented Mar 17, 2026

Uh oh!

DragonBluep commented Mar 17, 2026

Uh oh!

davkdavk commented Mar 17, 2026 via email

Uh oh!

neheb commented Mar 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Djfe commented Mar 15, 2026 •

edited

Loading