RTL8733B: BL-M8733BU2 / 0bda:b733 combo module — second-sample validation, identity confirmation, BT-coex scope

[josephnef]

The RTL8733B backend merged in #388 rests on one surviving physical unit: a bare unbranded 1T1R RTL8731BU module, 0bda:f72b, cut D. A second f72b unit passed identity/EFUSE/firmware bring-up, then stopped enumerating and overheated on a custom power supply — it is excluded from every radio-validation claim. The 0bda:b733 combo identity in src/rtl8733b/Rtl8733bUsbIds.h comes from the vendor ID table and has never been seen on hardware.

An LB-LINK BL-M8733BU2 board is expected. This issue is what to do when it lands.

1. Confirm the identity table

• lsusb the board before anything else. If its VID:PID is neither 0bda:f72b nor 0bda:b733 (OEM re-brands are the norm — the BL-M8812EU2 airs as 0bda:a81a), add it to kUsbIds in Rtl8733bUsbIds.h and to the demo discovery lists in examples/rx and examples/tx.
• Confirm SYS_CFG2 chip-id 0x16. The factory refuses a known 8733B PID whose chip-id read fails rather than falling back to Jaguar1 — verify that guard on real hardware rather than trusting the code path.
• Record the cut. The DUT behind every existing number is cut D; a different cut exercises firmware selection that has never run.

2. Second-sample validation — the actual point

Re-run the full #388 evidence set on this board and state where it agrees and where it does not:

• build/doctor + tests/rtl8733b_lifecycle_soak.sh (10 cycles, channels 6/36).
• Witnessed per-rate delivery: 1/2/5.5/11 Mbps CCK and 6 Mbps OFDM on 2.4 GHz, 6 Mbps + MCS0/4/7 on both bands, 20 and 40 MHz.
• The high-traffic RX runs that exposed the 20 KiB-aggregate-vs-URB straddle.

If the two units disagree anywhere, that disagreement is the finding — a one-unit result becoming a two-unit result is worth more than any single new capability.

3. Bluetooth / coexistence scope

0bda:b733 is the combo module's Wi-Fi function. BT and coex are not implemented and not claimed. With a real combo module on the bench, decide deliberately:

• Does the Wi-Fi side behave identically with the BT function enumerated and idle? (Jaguar3 has precedent for coex firmware silencing the antenna when its runtime thread is missing — do not assume the 87xx part is inert here.)
• Is a coex runtime needed for sustained TX, as on the 8822C? Measure before assuming it is not.
• BT itself stays out of scope unless someone has a use case; say so in docs/rtl8733b.md rather than leaving it ambiguous.

4. Deferred bench items this board unblocks

• True VBUS cold boots. The rtl8733b: add RTL8731BU/RTL8733BU USB RX and TX #388 bench hub could not switch VBUS, so only physical replug and warm re-init were tested. Run tests/adapter_doctor_cold.sh with a per-port-power-switching hub (REGRESS_VBUS_MAP/uhubctl) — the chip retains state across soft re-init, so a warm loop cannot substitute.
• Secure-firmware variants were never exercised; the tested cut-D device used the normal NIC image. If this board carries a secure variant, that path gets its first run.
• Thermal, honestly. The dead second unit overheated on a custom supply. Watch DEVOURER_THERMAL_POLL_MS on this board under sustained TX — but per docs/warm-tx-degradation.md, a power cycle changes chip state and temperature together, so it can never separate them. Read the meter beside a result, never as its explanation.

Acceptance criteria

• README rows for RTL8731BU and RTL8733BU reflect what is physically validated on each, with each board's model named — and the second sample stated as such rather than silently folded in.
• docs/rtl8733b.md "Known gaps" loses the 0bda:b733-never-seen bullet and the VBUS-cold bullet, or explains why they survive.
• BT/coex either implemented, or explicitly scoped out with the measurement that shows Wi-Fi is unaffected by the BT function's presence.

Follow-up to #388. Related: #233, #390, #391.