diff --git a/devices/ssc338q_fpv_openipc-urllc-aio/USB-HS-INVESTIGATION.md b/devices/ssc338q_fpv_openipc-urllc-aio/USB-HS-INVESTIGATION.md index e2fc559..157007b 100644 --- a/devices/ssc338q_fpv_openipc-urllc-aio/USB-HS-INVESTIGATION.md +++ b/devices/ssc338q_fpv_openipc-urllc-aio/USB-HS-INVESTIGATION.md @@ -10,9 +10,39 @@ USB 2.0 EHCI port (`Sstar-ehci-1`). unbind/rebind cycles. - The active device tree reports `dpdm_swap = <0>` and `power-enable-pad = ` (0xffff). +- **Verified on hardware (2026-10, Piotr):** the full `soc:Sstar-ehci-1` + platform-driver unbind/bind cycle (step 5 below) was performed over + Ethernet, waited out, and `/sys/bus/usb/devices/1-1/speed` still returned + `12`. A complete HCD/UTMI re-initialization therefore **does not** restore + high-speed negotiation on this board. +- **Verified on hardware (2026-10, Piotr):** changing the input supply + capacity did not improve negotiation. Supply-headroom tuning is ruled out. - RF/FEC configuration is not a USB fix and is out of scope for this issue. - This document contains no credentials, pairing or RF-access material. +## Conclusion (current fault-domain classification) + +Combined with the exact vendor EHCI/UTMI source audit below (which found no +HiLink-specific software discrepancy in anything this overlay or the shipped +kernel build controls), the verified on-hardware results above eliminate the +remaining software-adjacent candidates that are cheap to test: + +- **Ruled out:** wifibroadcast/OpenIPC configuration, RF/FEC settings, + ordinary userspace timing, a simple USB-device rebind, a full + HCD/UTMI re-initialization (done on hardware, no change), and + input-supply-capacity tuning (done on hardware, no change). +- **Remaining fault domain:** the USB **high-speed physical path / signal + integrity / rework** — D+/D− routing and symmetry, controlled impedance + and stubs, series/ESD components on the pair, connector and solder + integrity, or PHY-side / device-side silicon-level hardware — exactly the + boundary detailed in the hardware section below. + +Two caveats stay attached to this classification: it does not prove that +every conceivable undocumented analog register in the vendor PHY block is +irrelevant (the audited paths cover what the shipped source programs, not +the full register space), and it does **not** claim any high-speed success — +the fault is unresolved; only its domain is now sharply bounded. + ## Audited sources Audited 2026-10-02. Everything the firmware ships is stock upstream of this @@ -175,28 +205,49 @@ All tuning is compile-time; there are no runtime knobs in this repo. ## HiLink D+/D- hardware / rework investigation boundary -The remaining candidates are analog/hardware and are explicitly **outside -software scope**: +With the software and software-adjacent candidates ruled out (see the +conclusion above), the remaining fault domain is the USB **high-speed +physical path / signal integrity / rework**, explicitly outside software +scope: - D+/D- pair routing on the HiLink carrier: continuity and symmetry from the - SSC338Q pads to the module socket, series resistors / ESD protection parts - on the pair, connector solder joints. + SSC338Q pads to the module socket; controlled impedance along the pair; + stubs or test points hanging off it; series resistors / ESD protection + parts on the pair; connector and solder joint integrity. - HS chirp failure with FS working is the classic marginal-analog signature: the same pair carries FS traffic fine while the HS chirp (a short, amplitude-critical burst at reset) is missed by the host squelch detector. +- Concrete next hardware diagnostics, cheapest first (1-2 need the port or + module to be reachable — the radio is a directly attached module, so this + may mean a rework socket or a piggyback cable): + 1. Try a **known-good HS USB device** (any USB 2.0 flash disk) on the same + port. HS on the disk but not on the radio points at the + module/device side; FS on both points at the board-side pair. + 2. Try the **same RTL8812EU module on a different known-good HS host** + (a PC). HS there isolates the fault to this board's physical path. + 3. Measure D+/D- continuity and symmetry against the SSC338Q pads, and + inspect series/ESD parts and connector solder under magnification. + 4. With suitable equipment, capture the HS chirp amplitude/eye at the + host-side connector against the USB 2.0 electrical limits. - Any board rework (series resistor changes, pair shortening, shielding) invalidates prior software observations; re-verify from the on-device commands below after any hardware change. -No physical hardware validation has been performed for this document; nothing -below has been executed on the actual board and no boot image was built. +Evidence status: the platform-driver re-probe (step 5 below) and the +input-supply-capacity change were performed on hardware (2026-10, Piotr) — +both completed with no improvement, recorded above. The register-read +diagnostics (steps 1-4 below) have not been reported yet; no HS negotiation +has been observed at any point, and this document does not claim any. -## Safe on-device verification (reads only, plus one reversible re-probe) +## On-device verification (read-only diagnostics; step 5 re-probe already completed on hardware) Run from a root shell on the device over a link that is **not** the USB radio (Ethernet or serial console — see the wlan0 warning in step 5). All register reads are read-only `devmem` accesses; do **not** write UTMI/USBC/UHC registers from userspace (a write can wedge the bus until reboot). +Steps 1-4 have not been run/reported on the affected board yet and remain +the cheapest way to capture register-level evidence (CA calibration result, +squelch value, line state, force-FS latch) alongside the hardware work. Register addresses (physical; the RIU window maps virtual `0xFD200000` to physical `0x1F200000` — `MS_IO_OFFSET 0xDE000000`, @@ -245,7 +296,9 @@ number `n` sits at byte offset `2*n`, except odd `n` which sits at `2*n - 1` the 16-bit value at UTMI+0x78 masked with `0xFFF0` reading `0x0000` or `0xFFF0` — a failed RX calibration suppresses chirp detection and points at power/analog, not software. `dmesg` also prints `WARNING: CA Fail !!`. -5. **Full PHY re-init (in-kernel equivalent of a power cycle)** +5. **Full PHY re-init (in-kernel equivalent of a power cycle) — COMPLETED, + no improvement** (2026-10, Piotr: performed over Ethernet, device still + enumerated at 12 Mbit/s). Kept here for reproducibility: ``` ls /sys/bus/platform/drivers/Sstar-ehci-1/ # note the device name echo > /sys/bus/platform/drivers/Sstar-ehci-1/unbind @@ -259,12 +312,15 @@ number `n` sits at byte offset `2*n`, except odd `n` which sits at `2*n - 1` restart) rather than poking WiFi config. Rebind re-runs `Titania3_series_start_ehc()` (USBC reset handshake, CA calibration, squelch/eye init) and then re-enumerates the radio. Expected - dmesg on success: `Sstar-ehci-1 H.W init`, `[USB] init squelch level 0x..` + dmesg on HS success: `Sstar-ehci-1 H.W init`, `[USB] init squelch level 0x..` and a `new high-speed USB device number N` line. Re-running steps 1-4 - afterwards gives the post-init register state. + afterwards gives the post-init register state. Observed on hardware: the + device re-enumerated at full speed again. 6. **True analog power cycle** — only a full board re-power removes power from the UTMI PHY and the module (VBUS is hardwired; `power-enable-pad` - is not driven by Linux). Power-cycle, then repeat steps 1-5 and compare: + is not driven by Linux). Note this is distinct from the already-tested + input-supply-*capacity* change, which alters headroom but was recorded as + not improving negotiation. Power-cycle, then repeat steps 1-5 and compare: identical FS results across cold boot, re-probe and replug indicate the condition is stable (analog/hardware), while an occasional HS success would point at marginal timing.