[mt7996] BPI-R4-NIC-BE14 (MT7995AV + MT7976CN 0x79768b00): ~70 dB RF attenuation on Band 1 (5 GHz) despite clean FLASH_MODE=2 & 503ms NormalTRx

Open
  • Is something wrong?
#1,168 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
38/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
c, linux
Domain
embedded-iot, networking

Research direction

Start with mt7996_register_phy() in mt7996/init.c and trace how it chooses the Band 1 MAC when the EEPROM address is zero. The proposed fix should use the fallback MAC already held in dev->mphy.macaddr; done means the registered address is valid instead of 82:00:00:00:00:00. The RF attenuation questions remain unresolved and require hardware and driver expertise.

Written by the indexing model from the issue text.

Description

Hardware & Software Environment
  • Board: Banana Pi BPI-R4 Pro 8X (MT7988A)
  • Wi-Fi 7 NIC: BPI-R4-NIC-BE14 (MT7995AV 14c3:7990 2-3-3 + MT7976CN on ADIE 0 + MT7977IAN on ADIE 2)
  • OpenWrt / Kernel: SNAPSHOT r36304, kernel 6.18.44 (openwrt/mt76 commit be5ce7910521)
  • MCU Firmware: mt7996_wm_233.bin (20260311120702), mt7996_wa_233.bin (20260311120618)
  • Full Register Dumps, RFSPI Maps & Reproduction Scripts: 👉 https://github.com/lacrus66/bpi-r4-pro-be14-5ghz-audit
Problem Description

On the BPI-R4-NIC-BE14 module (from the batch with uninitialized 0x00 bytes in factory eFuse 0x1300..0x1317), Band 0 (2.4 GHz, ADIE 0) and Band 2 (6 GHz EHT320, ADIE 2) operate at full power and sensitivity (-22 dBm at 0.5m).
However, Band 1 (5 GHz, ADIE 0 MT7976CN 0x0f00002c = 0x79768b00) exhibits a ~70 dB RF attenuation across all 3 spatial streams (WF0, WF1, WF2).

What We Verified & Ruled Out (Full Audit in Repo)
  1. Clean FLASH_MODE = 2 (EE_MODE_BUFFER) & Calibration:
    • Bypassed OTP overwrite table .rodata+0x1268 so mt7996_mcu_set_eeprom() sends a verified 7680-byte buffer (cmp -l /sys/kernel/debug/ieee80211/phy0/mt76/eeprom = 0 bytes diff).
    • Tested both donor 561e3cf6 EEPROM and native card eFuse + reference target power (0x1300..0x15ff = 0x2e / 23 dBm).
    • Fixed the degenerate 82:00:00:00:00:00 Band 1 MAC bug caused by zeroed 0x0004..0x000f in 561e3cf6 (mt76_eeprom_override() only updates dev->mphy.macaddr without writing back to eeprom + 0x0004 before mt7996_register_phy(MT_BAND1)).
    • Set 0x0198 = 0x00 and 0x01af = 0x00: NormalTRx full runtime calibration on ePhyIdx[1] executes for 503.75 ms, and thermal sensors read an accurate 28.0 °C (ADC[0x41]).
  2. ADIE 0 (MT7976CN) RFSPI & Baseband (WF_PHY / WF_MAC):
    • All three 5 GHz slices in ADIE 0 (0x0f0001c8..01d4 WF0, 0x0f0001dc..01e8 WF1, 0x0f000724..0730 WF2) transition from 0x0120000X / 0xe314900c (OFF) to 0x1266280X / 0xe3149186 (ON) and switch sub-band LO bits (0xe3149186 -> 0xe3349186) between Ch 44 (5220 MHz) and Ch 149 (5745 MHz).
    • With MT_WF_RFCR (0x820f5000) set to 0x00000000 (fcsfail enabled on mon5), WF_PHY (0x83181010 / 0x83181018) detects preambles and decodes 802.11a/ax headers on 5220 MHz, passing frames to tcpdump, but the measured RSSI from a +22 dBm transmitter at 50 cm is -95 dBm on all three chains (0xe7, 0xeb, 0xf3).
Questions for MediaTek / mt76 Maintainers
  1. In MT7976CN (0x79768b00), RFSPI registers 0x0f0003a4, 0x0f0003d4, 0x0f000524 remain 0x00000008 (+0x28 = 0x00000114) on 5 GHz chains, whereas 2.4 GHz chains (0x0344, 0x0374) have 0x001fe088 (+0x28 = 0x00000000). Furthermore, in WF_PHY per-chain windows, offset +0x73a0 (0x00000d06) and +0x78d4..0x7ad0 are populated in 0x8313xxxx (chain 3) instead of 0x8310..0x8312. Is there a specific EEPROM byte or RFSPI strap for 0x79768b00 required to unmute the internal 5 GHz iFEM/TRSW?
  2. Could this batch of BPI-R4-NIC-BE14 cards (which shipped from the factory with uncalibrated 0x00 in 0x1300..0x1317) have a hardware fault on the 5 GHz PA/LNA power rail (VDD_PA_5G) that caused the factory ATE calibration to abort after 2.4 GHz?
Bonus: Proposed fix for the 82:00:00:00:00:00 Band 1 MAC bug in mt7996_register_phy()

When MT_EE_MAC_ADDR (0x0004) and MT_EE_MAC_ADDR2 (0x000a) are both zeroed in EEPROM/DT-overlay (as in OpenWrt commit 561e3cf6), mt76_eeprom_override(&dev->mphy) populates dev->mphy.macaddr with a random/DT MAC, leaving eeprom + 0x0004 all-zeros. Subsequently, mt7996_register_phy() copies those zeros from eeprom + MT_EE_MAC_ADDR and flips bits to 82:00:00:00:00:00 before calling mt76_eeprom_override(mphy), which passes is_valid_ether_addr(). Copying the fallback MAC from dev->mphy.macaddr (instead of raw eeprom + MT_EE_MAC_ADDR) resolves this:

/* in mt7996_register_phy() (mt7996/init.c): */
if (!is_valid_ether_addr(mphy->macaddr)) {
	memcpy(mphy->macaddr, dev->mphy.macaddr, ETH_ALEN);
	mphy->macaddr[0] |= 2;
	mphy->macaddr[0] ^= BIT(7);
}
Dominant language
C
Stars
895
Forks
461
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openwrt/mt76

All issues in openwrt/mt76

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.