From 161c7c232b45d360e08023922ea4d313ae034740 Mon Sep 17 00:00:00 2001
From: Joseph <162703152+josephnef@users.noreply.github.com>
Date: Tue, 2 Jun 2026 21:24:47 +0300
Subject: [PATCH] T1: extend canary oracle with 8814AU path-C/D BB regs
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The original `DEVOURER_DUMP_CANARY` set was 8812AU-specific —
covered path A/B BB regs (0xc**, 0xe**) plus shared MAC/RF regs.
8814AU has additional path C/D BB-table state at 0x18xx (path C)
and 0x1Axx (path D) — the existing oracle silently skipped these
on 8814AU, so any init drift in the path-C/D programming was
invisible.

Extends the dump:
- `RadioManagementModule::phy_SwChnlAndSetBwMode8812` now appends
  the 8814AU path-C/D registers when `version_id.ICType ==
  CHIP_8814A`. Covers TX-AGC (0x1820-0x1840 / 0x1a20-0x1a40),
  BB-swing (0x181c / 0x1a1c), and IGI (0x1850 / 0x1a50).
- RF[C] / RF[D] are intentionally skipped — paths C/D RF are
  write-only by HW design on 8814AU (kaeru cite "RTL8814AU RF
  read mechanism — paths C/D write-only by HW design"). Read
  attempts return undefined data so there's no useful canary
  surface there.
- `tools/canary_kernel_dump.sh` takes an optional third `chip`
  argument (default `8812`). With `chip=8814`, dumps the same
  path-C/D set so the kernel + devourer captures are comparable
  line-by-line.

Surfaced divergences (8814AU, ch6, fresh capture vs aircrack-ng
/88XXau in VM):
- 8 BB-AGC anchor regs differ (0x80c, 0x82c, 0x830, 0x834,
  0x8ac, 0x8b0, 0x8c4, 0xe90).
- 7 MAC anchor regs differ (0x040, 0x100, 0x420, 0x4c8, 0x522,
  0x610, 0x614).
- Path-C/D BB-swing (0x181c / 0x1a1c) at 5G — kernel writes
  0x2D400053 (band-set), devourer leaves BB-init 0x40000053.
- Path-C/D IGI (0x1850 / 0x1a50) — kernel 0x22 vs devourer 0x20
  on 5G; DIG floor doesn't apply to 8814 path-C/D in devourer.
- REG_MACID @ 0x610/0x614 = 0 on devourer (EFUSE port from prior
  T1 work fires for 8812/8821 but not 8814 — different EFUSE
  offset).

Each of these is a separate follow-on fix; this PR is just the
oracle plumbing so future 8814 init-correctness work has visible
ground truth to chase. The current dump output is purely
diagnostic — no functional behaviour change on any chip.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---
 src/RadioManagementModule.cpp | 24 ++++++++++++++++++++++++
 tools/canary_kernel_dump.sh   | 16 +++++++++++++++-
 2 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/src/RadioManagementModule.cpp b/src/RadioManagementModule.cpp
index fe2abb1..0375c7c 100644
--- a/src/RadioManagementModule.cpp
+++ b/src/RadioManagementModule.cpp
@@ -337,6 +337,30 @@ void RadioManagementModule::phy_SwChnlAndSetBwMode8812() {
     for (uint32_t a : rf_canary)
       _logger->info("RF[B] 0x{:02x} = 0x{:05X}", a,
                     phy_query_rf_reg(RfPath::RF_PATH_B, a, 0xfffffu));
+
+    /* 8814AU extension: dump path-C/D BB-AGC + IGI + BB-swing. Paths C/D
+     * exist at BB-register-table level (0x18xx for path C, 0x1Axx for
+     * path D, see hal/Hal8814PhyReg.h). NB: the corresponding RF
+     * registers for paths C/D are write-only by HW design on 8814AU
+     * (see kaeru cite "RTL8814AU RF read mechanism — paths C/D
+     * write-only by HW design") — read attempts return undefined
+     * data, so we skip RF[C]/RF[D]. The BB-table state IS readable
+     * and is the canary surface for path-C/D init drift. */
+    if (_eepromManager->version_id.ICType == CHIP_8814A) {
+      static const uint16_t bb_canary_8814_pathCD[] = {
+          /* Path-C TX-AGC table */
+          0x1820, 0x1824, 0x1828, 0x182c, 0x1830, 0x1834, 0x1838, 0x183c,
+          0x1840,
+          /* Path-C BB-swing + IGI */
+          0x181c, 0x1850,
+          /* Path-D TX-AGC table */
+          0x1a20, 0x1a24, 0x1a28, 0x1a2c, 0x1a30, 0x1a34, 0x1a38, 0x1a3c,
+          0x1a40,
+          /* Path-D BB-swing + IGI */
+          0x1a1c, 0x1a50};
+      for (uint16_t a : bb_canary_8814_pathCD)
+        _logger->info("BB 0x{:04x} = 0x{:08X}", a, _device.rtw_read32(a));
+    }
     _logger->info("=== END DEVOURER_DUMP_CANARY ===");
   }
 
diff --git a/tools/canary_kernel_dump.sh b/tools/canary_kernel_dump.sh
index 339620d..0927e78 100755
--- a/tools/canary_kernel_dump.sh
+++ b/tools/canary_kernel_dump.sh
@@ -38,12 +38,14 @@
 set -euo pipefail
 
 if [[ $# -lt 2 ]]; then
-  echo "Usage: $0 <iface> <channel>" >&2
+  echo "Usage: $0 <iface> <channel> [chip]" >&2
+  echo "  chip: 8812 (default) | 8814" >&2
   exit 1
 fi
 
 IFACE="$1"
 CHANNEL="$2"
+CHIP="${3:-8812}"
 
 if ! ip -o link show "$IFACE" >/dev/null 2>&1; then
   echo "iface '$IFACE' not found — did you modprobe 88XXau?" >&2
@@ -93,4 +95,16 @@ for PATH_IDX in 0 1; do
   done
 done
 
+# 8814AU extension: path-C/D BB-AGC + IGI + BB-swing. RF[C]/RF[D]
+# are write-only by HW design on 8814AU (read attempts return undefined
+# data), so we only dump BB-table state for paths C/D.
+if [[ "$CHIP" = "8814" ]]; then
+  for ADDR in 0x1820 0x1824 0x1828 0x182c 0x1830 0x1834 0x1838 0x183c \
+              0x1840 0x181c 0x1850 \
+              0x1a20 0x1a24 0x1a28 0x1a2c 0x1a30 0x1a34 0x1a38 0x1a3c \
+              0x1a40 0x1a1c 0x1a50; do
+    printf "BB %s = %s\n" "$ADDR" "$(readreg $ADDR)"
+  done
+fi
+
 echo "=== END DEVOURER_DUMP_CANARY ==="