hilink: record verified USB HS hardware results and bound the fault domain

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 = <PAD_UNKNOWN>` (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 <device> > /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.