RTL8821AU: drop redundant PR #37 trace-derived post-fwdl pokes#61
Merged
Conversation
Removes the 86-line `if (CHIP_8821)` block from `rtl8812au_hal_init`: - Hardcoded T2U Plus MAC at REG_MACID (0x0610..0x0615) — burned-in to one specific chip's address (`e0:d3:62:97:a9:72`), wrong for every other 8821AU. PR #42's proper 8821-specific init flow programs MAC from EFUSE. - ~13 trace-derived register pokes at 0x004c/0x004e/0x0040/0x0208/ 0x0520/0x0670/0x0a0a/0x1874-0x187f — captured from one aircrack-ng/88XXau cold-init session on the T2U Plus, never re-derived from first principles. Made redundant by #42's proper init flow that drives the chip from any starting state. - BB/AGC value-override cluster at 0x0830/0834/8a4/8b0 + 0x0c20-0x0c44 + 0x0c50/0c54/0c90/0cb4/0e90 — these mirror what aircrack-ng's phydm runtime AGC settles on after init. Devourer doesn't run phydm; the override was a "best we can do" shortcut. Removed pending a proper port (the AGC tuning kernel does without the dynamic feedback loop will need to be revisited if 8821AU RX sensitivity regresses). NB: the "Trace-derived 8814 post-fwdl init writes" sub-block that USED to live inside this `if (CHIP_8821)` branch is NOT touched here — PR #57 (2026-05-29) moved it to its proper `if (is_8814a)` location with byte-reversed u32 literals after discovering it had been mis-gated. That block stays. This is a re-scope of PR #43 (closed) against current master, with the #57-rescued 8814 init left untouched. ## What this PR doesn't validate Android-side hotplug end-to-end. PR #42 was originally confirmed by @RomanLut to fix hotplug on PixelPilot + hx-esp32cam-fpv WITH the trace pokes still in place. This PR removes them. Proper init flow alone should be sufficient (that's the whole point of #42 — driving the chip from any starting state without relying on pre-captured pokes that matched one specific state) — but it deserves re-validation before merge. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Re-scope of #43 (closed) against current master.
What's removed
The 86-line
if (CHIP_8821)block inHalModule::rtl8812au_hal_initimmediately after the post-fwdl REG_CR / REG_RXFLTMAP2 setup:e0:d3:62:97:a9:72); wrong for every other 8821AU. PR RTL8821AU: 8821-specific init flow (replaces trace-derived parity) #42's proper 8821-specific init flow programs MAC from EFUSE.The double-writes to 0x0520 and 0x0670 with different values per write (one from this block, one from the "8814 post-fwdl init" block underneath) were the original smell that surfaced this in #43.
What this PR does NOT touch
The "Trace-derived 8814 post-fwdl init writes" sub-block that USED to live inside this same
if (CHIP_8821)branch. PR #57 (merged 2026-05-29) moved it to its properif (is_8814a)location with byte-reversed u32 literals after discovering it had been mis-gated. That block stays. This is the only difference from #43.Linux validation (carried over from #43)
tests/regress.py --full-matrix --channel 100on 8814 + 8821 T2U Plus, VM mode. No regressions; 8821 cells preserved within RF variance:NB: that matrix was captured against the #43 branch state; will need a fresh run against this PR before merge.
What this PR doesn't validate
Android-side hotplug end-to-end. PR #42 was originally confirmed by @RomanLut to fix hotplug on PixelPilot + hx-esp32cam-fpv with the trace pokes still in place. This PR removes them. Proper init flow alone should be sufficient (that's the whole point of #42 — driving the chip from any starting state without relying on pre-captured pokes) — but it deserves re-validation before merge.
@RomanLut — when you have a moment, could you re-build PixelPilot / hx-esp32cam-fpv against this branch and confirm 8821AU hotplug still works on Android? Single replug cycle is enough. If it regresses, the trace pokes were load-bearing for hotplug specifically (unlikely IMO but possible) and we revert.
Test plan
--full-matrixre-run against this branch tip🤖 Generated with Claude Code