Hi everyone,
I’m working on a Sercomm board (MT7621AT + MT7603EN + MT7615N). I started by porting OpenWrt 25.12 using an Etisalat S3 image as a base, which is what initially led me to modifying the DTS.
At first, I noticed that the S3 image maps the Factory partition differently from the stock firmware:
- Stock firmware: Factory is at
mtd3(128KB) - S3 image: Factory is mapped to
mtd2(1MB)
Because of this mismatch, I initially suspected that the driver was reading invalid calibration data. I even tried extracting my original factory.bin and placing it under /lib/firmware/mediatek/, hoping to force the driver to use it, but that didn’t work.
I also attempted to manually split the factory data per radio, extracting the corresponding regions and creating separate EEPROM files. I tested different filenames and locations under /lib/firmware/ (including mediatek/), using both .bin and .eeprom formats, but none of these approaches had any effect.
(I also previously made a post — in the wrong forum section — asking how to force the S3 image to use my factory data without modifying the DTS. Now I understand that this approach was always going to fail....)
After creating a proper DTS for my device, I was able to fix the partition mapping and confirm that MAC addresses are read correctly from Factory. However, this led to a new discovery: the Factory partition itself appears to be incomplete.
After digging deeper into my device and extracting the full squashfs from the stock firmware, I think I’ve found why the mt7615e driver is stuck at very low transmit power (6 dBm).
From what I can see, the stock firmware does not store a complete EEPROM in the Factory partition.
Instead, it seems to use a split / hybrid approach:
-
Factory partition (mtd3 @ 0x8000):
Contains only ~1024 bytes (0x400). This includes MAC address and some basic calibration data.
https://pastebin.com/NFwxgBx8 -
Stock Firmware filesystem (/etc/wireless/mt7615/):
Contains:-
mt7615.eeprom.bin (also ~1KB, looks like a template)
https://pastebin.com/x94H5AfV -
mt7615-sku.dat (per-country power tables)
https://pastebin.com/DqZGjt5c
-
-
What the vendor driver does:
Using scripts like mt7615.lua, it appears to load the template EEPROM, overlay data from Factory, apply SKU limits (via .dat)
https://pastebin.com/ELbp6Lf1
So the final EEPROM used at runtime is dynamically assembled.
My understanding is that the mt76 driver expects a complete EEPROM blob.
Right now in my DTS, I point to:
- mtd3 @ 0x8000 for the 5GHz EEPROM
But that region only contains the first ~1KB. So, calibration tables for 5GHz are missing or invalid and the driver falls back to 6 dBm.
Additional findings
- The device uses internal PA/LNA (no external FEM visible - photos attached)
- The stock firmware allows much higher TX power (~19–30 dBm depending on channel), confirmed via mt7615-sku.dat.
My current state
- Partition layout is corrected in DTS
- MAC addresses are properly assigned via nvmem-cells
- Radios initialize correctly
- But TX power remains capped due to incomplete EEPROM data
I also have a second identical unit running the stock firmware (vendor-modified, SDK-based on an old OpenWRT release), with full backups of all original partitions available.
Question / Idea
At this point, I’m wondering:
Would it be possible to reconstruct a full EEPROM image by combining the partial calibration data from Factory, the vendor template (mt7615.eeprom.bin), possibly respecting limits from mt7615-sku.dat, and then expose that as a complete EEPROM to the mt76 driver?
I’m not sure if this approach makes sense, or if I’m misunderstanding how calibration data should be structured.
Alternatively, would it be possible to use a “generic” EEPROM for the MT7615N?
Or is there a better approach?
More Info:
Custom DTS (WIP)
LINK: https://pastebin.com/2xBUb9FK
LED
In the stock firmware, all LEDs (Power, WiFi, LAN) are solid green by default, with no blinking patterns during normal operation.
- POWER: GPIO 519
- WIFI_R/G1 (Bi-color):
-
- Green: GPIO 524 (Active Low).
-
- Red: GPIO 520. (Active Low).
- WIFI_B1 (Blue): GPIO 522 (Active Low).
- LAN3: It stays dim green and does not respond to GPIO commands. Still unknown.
- WPS Button: GPIO 523 (Active High / hi when pressed).
Serial Pinout
I identified and soldered pins for the serial connection, pinout images attached.
The correct baud rate is 57600.
Preview Image:
Images
LINK:
https://imgur.com/a/h9Ev7SC
Relevant Stock Firmware Info
Full Boot Log Link:
https://pastebin.com/rm1HUixw
Additionally includes: "ifconfig", "iwpriv", "cat /proc/cpuinfo", "logread | grep -i wifi", "lspci"
Partitions
root@Andes:/# cat /proc/mtd
dev: size erasesize name
mtd0: 07f80000 00020000 "ALL"
mtd1: 00080000 00020000 "Bootloader"
mtd2: 00020000 00020000 "Config"
mtd3: 00020000 00020000 "Factory"
mtd4: 02000000 00020000 "firmware"
mtd5: 02000000 00020000 "firmware2"
mtd6: 01d2cffa 00020000 "rootfs"
mtd7: 01100000 00020000 "rootfs_data"
dmesg | grep mt76
root@Andes:/# dmesg | grep mt76
[ 12.988000] mt7603_init()-->
[ 13.004000] <--mt7603_init()
[ 13.028000] l1set_profile_path() profile remain /etc/wireless/mt7603/mt7603.dat
[ 13.100000] l1set_single_sku_path() sku path update from /etc/Wireless/RT2860AP/SingleSKU.dat to /etc/wireless/mt7603/mt7603-sku.dat
[ 37.988000] l1set_profile_path() profile remain /etc/wireless/mt7603/mt7603.dat
[ 37.988000] l1set_single_sku_path() profile remain /etc/wireless/mt7603/mt7603-sku.dat
[ 38.416000] mt7603_init_mac_cr()-->
[ 40.440000] mt7603_switch_channel(): Switch to Ch#6(2T2R), BBP_BW=0
[ 40.456000] mt7603_set_ed_cca: TURN OFF EDCCA mac 0x10618 = 0x8564267c, EDCCA_Status=0
[ 70.428000] mt7615_apply_cal_data() : eeprom 0x52 bit 1 is 0, do runtime cal , skip RX reload
[ 70.428000] mt7615_apply_cal_data() : eeprom 0x52 bit 0 is 0, do runtime cal , skip TX reload
[ 70.640000] mt7603_switch_channel(): Switch to Ch#2(2T2R), BBP_BW=0
mt76-related kernel logs only appear before the WiFi subsystem is fully initialized.
The WiFi LED turns on after the 5GHz radio is active.
Once the 5GHz interface is brought up, logging via dmesg stops completely.
Relevant New Firmware Info
iw phy phy1 info | grep -i dbm
* 5180.0 MHz [36] (6.0 dBm)
* 5200.0 MHz [40] (6.0 dBm)
* 5220.0 MHz [44] (6.0 dBm)
* 5240.0 MHz [48] (6.0 dBm)
* 5260.0 MHz [52] (6.0 dBm) (radar detection)
.................
**Always 6.0 dBm**
dmesg | grep mt76
root@OpenWrt:~# dmesg | grep mt76
[ 1.369604] mt7621_gpio 1e000600.gpio: registering 32 gpios
[ 1.381496] mt7621_gpio 1e000600.gpio: registering 32 gpios
[ 1.393337] mt7621_gpio 1e000600.gpio: registering 32 gpios
[ 1.405390] mt7621-pci 1e140000.pcie: host bridge /pcie@1e140000 ranges:
[ 1.418693] mt7621-pci 1e140000.pcie: No bus range found for /pcie@1e140000, using [bus 00-ff]
[ 1.436137] mt7621-pci 1e140000.pcie: MEM 0x0060000000..0x006fffffff -> 0x0060000000
[ 1.452425] mt7621-pci 1e140000.pcie: IO 0x001e160000..0x001e16ffff -> 0x0000000000
[ 1.816272] mt7621-pci 1e140000.pcie: pcie2 no card, disable it (RST & CLK)
[ 1.830063] mt7621-pci 1e140000.pcie: PCIE0 enabled
[ 1.839707] mt7621-pci 1e140000.pcie: PCIE1 enabled
[ 1.863781] mt7621-pci 1e140000.pcie: PCI host bridge to bus 0000:00
[ 3.142572] mt7621-nand 1e003000.nand: ECC strength adjusted to 4 bits
[ 3.155715] 5 fixed-partitions partitions found on MTD device mt7621-nand
[ 3.169856] Creating 5 MTD partitions on "mt7621-nand":
[ 17.335160] mt7603e 0000:02:00.0: enabling device (0000 -> 0002)
[ 17.347371] mt7603e 0000:02:00.0: ASIC revision: 76030010
[ 17.362466] mt7603e 0000:02:00.0: Firmware Version: ap_pcie
[ 17.373665] mt7603e 0000:02:00.0: Build Time: 20160107100755
[ 17.406310] mt7603e 0000:02:00.0: firmware init done
[ 17.593961] mt7603e 0000:02:00.0: registering led 'mt76-phy0'
[ 17.707871] mt7615e 0000:01:00.0: enabling device (0000 -> 0002)
[ 17.729650] mt7615e 0000:01:00.0: registering led 'mt76-phy1'
[ 17.826892] mt7615e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20180518100604a
[ 17.884353] mt7615e 0000:01:00.0: N9 Firmware Version: _reserved_, Build Time: 20200814163649
[ 17.951494] mt7615e 0000:01:00.0: CR4 Firmware Version: _reserved_, Build Time: 20190415154149
root@OpenWrt:~#
dmesg | grep -Ei "eeprom|cal|limit"
root@OpenWrt:~# dmesg | grep -Ei "eeprom|cal|limit"
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[ 0.016020] Calibrating delay loop... 586.13 BogoMIPS (lpj=2930688)
[ 0.146962] rcu: Hierarchical SRCU implementation.
[ 0.828095] NET: Registered PF_UNIX/PF_LOCAL protocol family
[ 2.157983] pci 0000:01:00.0: 2.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x1 link at 0000:00:00.0 (capable of 4.000 Gb/s with 5.0 GT/s PCIe x1 link)
root@OpenWrt:~#
Background / flashing notes
Since there is no official target for this specific board, I tested several images through trial and error.
I picked the S3 image because, on paper, the hardware looked similar, and it became my entry point to learning how all of this works.
As I kept digging, it turned into a bit of a "snowball" project where I had to figure out how to handle UBI volumes, fix kernel headers (legacy U-Boot), realize that the partition maps don't match, and eventually understand that the EEPROM is incomplete.
At this point:
- Ethernet is working
- Wi-Fi initializes correctly
- But 5GHz TX power is stuck at ~6 dBm
I’m still learning, so I may have taken a suboptimal path getting here. Any help, suggestions, or pointers would be greatly appreciated. Thanks in advance.