From 7d2072cfc703d11ce096bfd4b0ec187689fa9216 Mon Sep 17 00:00:00 2001 From: Joseph <162703152+josephnef@users.noreply.github.com> Date: Tue, 26 May 2026 17:02:04 +0300 Subject: [PATCH] RTL8814AU: drop REG_CR=0 post-fwdl write that wedges bulk-OUT (#36) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit FirmwareDownload_8814A's post-fwdl CPU kick zeroes REG_CR (0x0100) just after MCUFWDL=0x79. This clears all 8 enable bits in byte 0 (HCI TX/RX DMA, TXDMA, RXDMA, PROTOCOL, SCHEDULE, MACTXEN, MACRXEN). The later `REG_CR |= MACTXEN|MACRXEN` at HalModule.cpp:241 only re-sets bits 6+7, leaving the DMA-enable bits 0..5 at zero — so the chip's TX/RX DMA engines never come up. bulk-OUT URBs queue at EP 0x02 but the FIFO never drains; URBs sit until libusb's 500 ms async timeout cancels them (-ENOENT), producing the catastrophic submit-failure pattern reported in #36. Kernel rtw88_8814au never writes REG_CR=0 during post-fwdl. The "byte-for-byte rtw88-mirror" comment block above this code was wrong about this specific address. Bisected today by gating the 7 divergent post-fwdl writes individually behind env vars; only 0x0100 reproduces the wedge. Verification: - Local devourer-TX 12 s on 8814AU: 2203/2203 OK (was 0.4% completion) - 8812AU + 8821AU sanity: unchanged (different code path) - tests/regress.py --full-matrix: 8814 devourer-TX cells [2,4,6,8] now show 0 fail annotation (was 4700+ failures each) The fix is sufficient for #36 but does not restore 8814AU on-air emission — chips ACK URBs cleanly but no frames hit air. That is a separate gate (TX descriptor or rate config) and out of scope here. Closes #36. Co-Authored-By: Claude Opus 4.7 (1M context) --- src/FirmwareManager.cpp | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/src/FirmwareManager.cpp b/src/FirmwareManager.cpp index 67b54b0..d28d3da 100644 --- a/src/FirmwareManager.cpp +++ b/src/FirmwareManager.cpp @@ -531,7 +531,16 @@ void FirmwareManager::FirmwareDownload_8814A() { * byte-for-byte after the last fwdl IDDMA program. */ _device.rtw_write8(REG_MCUFWDL, 0x79); /* declare init ready */ _device.rtw_write8(0x010d, 0x00); /* REG_RD_CTRL+1 */ - _device.rtw_write8(0x0100, 0x00); /* REG_CR byte 0 = 0 */ + /* DO NOT write 0x0100 (REG_CR) = 0 here. Bisect 2026-05-26 of #36 wedge: + * zeroing REG_CR disables byte 0's DMA-enable bits (HCI_TXDMA_EN/ + * HCI_RXDMA_EN/TXDMA_EN/RXDMA_EN/PROTOCOL_EN/SCHEDULE_EN). The later + * `REG_CR |= MACTXEN | MACRXEN` at HalModule.cpp:241 sets bits 6,7 but + * leaves bits 0..5 zero, so the chip's TX/RX DMA engines never come up + * — bulk-OUT URBs queue at EP 0x02 but the FIFO never drains. URBs sit + * until libusb's 500 ms async timeout cancels them (-ENOENT), giving + * the 95%+ submit-failure pattern reported in #36. Kernel rtw88_8814au + * never writes this address with this value. With this single write + * removed, devourer-TX on 8814AU goes from 0.4% completion to 100%. */ _device.rtw_write32(0x1330, 0x80000000); /* REG_3081_DCDC_CTRL */ _device.rtw_write16(0x0230, 0x0000); /* REG_PCIE_CTRL_REG word */ _device.rtw_write32(0x022c, 0x80000000); /* REG_BIST_CTRL */