mt7663s: PATCH_FINISH_REQ never acknowledged on AMPAK MT7661RSN (Amlogic S905X2 STB)

Provenance — please read this first, so the report is not misrouted

• Driver under test: mt7663s from mt76 in the Linux kernel, as shipped by the
  ophub/amlogic-s9xxx-armbian kernel package 5.10.269-ophub. All 18 runs below were done on
  this box with that kernel.
• Not a distro-local hack: a clean out-of-tree build of
  drivers/net/wireless/mediatek/mt76 from stable tag v5.10.269 (sparse checkout of that
  subtree only) fails with identical logs — that is run 1, the unmodified baseline. All
  parameterised runs were built from that tree.
• Not tested: I have not tested the openwrt/mt76 tree at this commit. I did check its
  history: no commit touching mt7615/mcu.c or mt76/sdio.c since 2023 changes the ROM-patch
  download path, so I do not expect master to differ here — but that is a reading of the history,
  not a test. Happy to retest against master if you want; it uses APIs newer than 5.10
  (pm_sleep_ptr(), DEFINE_SIMPLE_DEV_PM_OPS), so I would build it against this box's 6.18
  kernel instead.
• The OpenWrt image used as a control is NOT an OpenWrt-mt76 product: it is an Amlogic
  vendor/community BSP image built for this specific TV box
  (openwrt_amlogic_s905x2-hg680fj_k4.9.337), with CONFIG_WLAN_VENDOR_MEDIATEK unset — it
  drives the chip with MediaTek's vendor driver (drivers/staging/mt766x/mt7663_sdio.ko).
  None of its code is the subject of this report; it is included only as a working control.
• Already reported on the distro side — please don't reroute it there: I filed
  ophub/amlogic-s9xxx-armbian#3619 (MT7661RSN, 6.18) and #3615 (MT7663 family, 6.12). #3619 was
  answered: the analysis correctly identified the MCU dying at "start patch", but its conclusion
  (ROM patch does not match the silicon) is disproved by runs 1–9 below — five different patches
  fail identically, including the blob the working vendor BSP actually loads. #3615 has no reply.
  ophub only packages mainline kernels and cannot change mt76, so the fix belongs in
  mt76 / linux-wireless.

Hardware: FiberHome HG680-FJ set-top box, Amlogic S905X2. Combo
module AMPAK "MT7661RSN"; it enumerates on SDIO as 037a:7603 (WiFi) + 037a:7663 (BT), so
mt7663s and btmtksdio bind normally. Kernel 5.10.269-ophub. The same failure signature is
reported for the same box/module on 6.18.41-ophub (ophub#3619) and for the MT7663 family on
6.12.94-ophub (ophub#3615).

Symptom: the ROM patch payload is transferred, then the MCU stops answering exactly at the
"start patch" command, and both WiFi and Bluetooth (they share the CR4) go dead:

mt7663s mmc0:0001:1: HW/SW Version: 0x65326363, Build Time: 2006030247debug
mt7663s mmc0:0001:1: Message -4294967289 (seq 13) timeout   <- 0x80000007 MCU_CMD_PATCH_FINISH_REQ
mt7663s mmc0:0001:1: Failed to start patch
mt7663s mmc0:0001:1: Message -4294967280 (seq 14) timeout   <- PATCH_SEM_CONTROL release
mt7663s mmc0:0001:1: Failed to release patch semaphore
mt7663s mmc0:0001:1: mediatek/mt7663pr2h.bin not found, switching to mediatek/mt7663pr2h_rebb.bin

ip link set wlan0 up → RTNETLINK answers: Input/output error. wlan0 is registered.

Notes on the log: -4294967289 is 0xFFFFFFFF00000007; masked with MCU_CMD_MASK it is CID 0x07
= PATCH_FINISH_REQ. The ~20 s gap is the driver's own timeout
(mt7615_mcu_wait_response(): expires = jiffies + 20 * HZ), not a slow transfer — the 278 KB
payload moves in under 2 s. The "not found, switching to ..." line is printed after any failure
of the primary file; the HW/SW Version: line above it proves the file was found and parsed.

What I ruled out (each run after a full chip reset; the chip can be reset in software by
unbinding/rebinding the mmc host ffe03000.sd, which toggles the sdio-pwrseq GPIO):

• Five different ROM patches, all failing identically: linux-firmware mt7663pr2h.bin
  (7663e2ccn04) and mt7663pr2h_rebb.bin (7663e2-1802); the vendor's own
  mt7663_patch_e2_hdr.bin (7663mp-1802, build 2021-03-08) extracted from this box's
  /vendor/firmware; the E1 patch; and mt7663_patch_e2_hdr.bin build 1902151020c5f53, which is
  the blob the working vendor BSP actually loads.
• Command variants (out-of-tree build at the exact tag, module parameters): patch-config CID
  0x01 vs 0x05 (vendor uses INIT_CMD_ID_PATCH_START = 0x05 for the patch), scatter CID 0xEE
  vs 0x00 (vendor sends ucCID = 0 with INIT_PKT_FT_PDA_FWDL) vs 0x06, chunk size 4076 vs
  2048 vs 512, check_crc = 0 vs 1, scatter txd Q_IDX 0x1e vs 0x00, txd PKT_FMT FW vs
  CMD, and a 2 ms delay after every scatter chunk. All identical failure.
• SDIO clock lowered at runtime to 50 / 25 / 12.5 MHz: no change.
• DTB timing: removed sd-uhs-sdr104 so the card enumerates as SDR50 @100 MHz (no tuning),
  plus post-power-on-delay-ms = <100> on sdio-pwrseq: no change.
• btmtksdio blacklisted so nothing else touches the shared MCU: no change.
• Chip ECO is E2, read from the registers the vendor driver uses (TOP_HVR = 0x00008b10 →
  hw 0x10; TOP_FVR = 0x00008a01 → rom 0x01), so the E2 patch is the correct one. (Minor: the
  factory version here is 0x0b while the vendor table says 0x0a.)
• Comparison against both public vendor drivers (Android gen4m for MT7661, and MT7663 LinuxAP)
  shows no remaining difference we can find: patch address 0xDC000, 30-byte patch header,
  {addr,len,mode} config payload, DOWNLOAD_CONFIG_ACK_OPTION = BIT(31) = DL_MODE_NEED_RSP,
  finish payload {check_crc, rsv[3]}, FWDL port 0x1e, packet formats 3/2, WPDMA bypass bit 9,
  WPDMA register HIF+0x208.

Also worth noting for review: on the SDIO path mt76 does not use MT_TXQ_FWDL at all.
mt76s_alloc_tx() allocates only indices 0..MT_TXQ_MCU_WA-1, and mt7663s_mcu_send_message()
sends every MCU message — including FW_SCATTER — through MT_TXQ_MCU (hw_idx 5); the scatter port
comes from the txd field, not a hardware queue. Before firmware runs, each scatter packet is written
individually with no PSE/PLE quota check (goto next skips mt7663s_tx_pick_quota()); with a
512-byte chunk the host queue fills mid-scatter and the transfer aborts with
Failed to send firmware to device. That is a real robustness gap, though adding a 2 ms delay per
chunk does not change the failure, so it is not the root cause here.

Control experiment — the vendor BSP works on the same box. The Amlogic BSP image for this board
brings WiFi up in AP mode on first boot. It does not use mt76 in any form
(CONFIG_WLAN_VENDOR_MEDIATEK is not set); it uses MediaTek's vendor driver
drivers/staging/mt766x/mt7663_sdio.ko, an Amlogic BSP mmc host (aml_sd_emmc),
CONFIG_AMLOGIC_WIFI=y glue, and a DTB where the generic sdio@ffe03000 node is disabled in favour
of a wifi { compatible = "amlogic, aml_wifi"; pwm_config = ...; } node. Scanning that image
byte-for-byte, its firmware blobs are the same ones tested above (two identical to
linux-firmware, one identical to the vendor blob that fails under mt76).

So: same silicon, same firmware blob, vendor driver works, mt76 dies at PATCH_FINISH_REQ.

Ask:

1. Is this signature known for this module/silicon, or is there an MCU/HIF init step for SDIO that
   mt76 does not perform?
2. If you suspect the transport, what would you like captured (tracepoints, SDIO error counters,
   xmit-queues, register dumps)? I can build and test any patch.
3. If the answer is "vendor firmware/driver only", recording that would still help — several
   Amlogic boxes with AMPAK MT7661RSN currently have no WiFi under any mainline kernel.

I have the hardware and can iterate quickly: the chip can be reset in software and out-of-tree
builds take ~70 s on the box.

Attached: hg680-mt7663s-evidence.tar.gz — the full technical report (README.md), a clean
single-failure dmesg, full dmesg + applied parameters for all 18 runs, an index of the evidence
(evidence/README.md), the out-of-tree patch and test scripts in English (evidence/tools/), and
the DTB edit. Vendor blobs from the box's /vendor/firmware available on request.

Start with drivers/net/wireless/mediatek/mt76, especially mt7615/mcu.c, mt76/sdio.c, mt7615_mcu_wait_response(), and mt7663s_mcu_send_message(). Reproduce the PATCH_FINISH_REQ timeout using the attached logs and test scripts, then compare the reported SDIO and firmware-download behavior with the working vendor-driver control. Done means identifying whether mt76 misses an MCU/HIF step and validating the finding on this hardware.