diff --git a/devices/ssc338q_fpv_openipc-urllc-aio/USB-HS-INVESTIGATION.md b/devices/ssc338q_fpv_openipc-urllc-aio/USB-HS-INVESTIGATION.md new file mode 100644 index 0000000..639e97d --- /dev/null +++ b/devices/ssc338q_fpv_openipc-urllc-aio/USB-HS-INVESTIGATION.md @@ -0,0 +1,481 @@ +# RTL8812EU enumerating at 12 Mbit/s on `Sstar-ehci-1` — investigation record (root cause found; acceptance pending) + +Device: `ssc338q_fpv_openipc-urllc-aio` (HiLink URLLC, SSC338Q / infinity6e). +Radio: Realtek RTL8812EU, USB ID `0bda:a81a`, directly attached to the SSC338Q +USB 2.0 EHCI port (`Sstar-ehci-1`). + +## Fixed observations (treated as inputs, not re-derived here) + +- The radio repeatedly enumerated at **12 Mbit/s (full speed)** after USB + unbind/rebind cycles (pre-rework symptom; HS since restored — see the + series-damping experiment below). +- 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. +- **Verified on hardware (2026-10, Piotr):** the radio is a custom + carrier/module assembly, **not** a drop-in USB dongle: a four-wire host + harness/pad connection, two RF pigtails, and visible local regulation on + the carrier. +- **Verified on hardware (2026-10, Piotr):** 5.13 V measured directly at the + module input, inside the common 4.75–5.25 V input range. The earlier + "3.3 V fed into the 5 V input" hypothesis is therefore ruled out **at + module ingress** (upstream of the carrier's local regulation). +- **Verified on hardware (2026-10, Piotr):** each USB data net was physically + traced as `SSC338Q-side -> approximately 100 ohm series resistor -> + RTL8812EU-module D+ or D-`; each component measured about 100 ohm across + its own endpoints with all power removed. These are **two separate + per-line series resistors**, not one 100-ohm differential termination. +- **Verified on hardware (2026-10, Piotr):** both previously verified 100 + ohm per-line resistors were **replaced with matched 12 ohm parts**; + immediately afterward `/sys/bus/usb/devices/1-1/speed` returned **`480`**. + This is direct A/B evidence that the original 100 ohm-per-line network + **blocked High-Speed negotiation** on this unit. +- 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 (root cause found; acceptance pending) + +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), + input-supply-capacity tuning (done on hardware, no change), and + wrong-voltage-at-module-ingress (measured 5.13 V at the input, within the + 4.75–5.25 V range). +- **Fault domain where the cause was found:** the USB **high-speed physical + path / signal integrity / rework** — D+/D− routing and symmetry across + the carrier, harness/pads and intervening components, controlled impedance + and stubs, series/ESD/common-mode 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 supply + points were ruled out specifically (capacity tuning, ingress voltage); + power **quality** downstream of the measured input — supply noise/ripple + and the carrier's local regulator output — remains untested and stays + inside the open (now margin-focused) fault domain. + +Two caveats stay attached to this record: the audited paths never +characterized the vendor PHY's undocumented analog tuning, and this +document distinguishes **immediate HS restoration from full acceptance** — +long-term stability and signal margin are unproven (see the acceptance +gates below). + +**Root cause (proven on this unit):** the traced per-line ~100 ohm series +resistors were the negotiation blocker. FS signaling at 12 Mbit/s is +edge-slow and tolerant, while HS chirp/negotiation is amplitude- and +timing-critical; replacing both 100 ohm parts with matched 12 ohm parts +restored `480` immediately — a direct A/B result. This proof is scoped to +**this unit**: the exact SSC338Q PHY/reference-design series value remains +undocumented in this repository (the commonly seen external USB 2.0 +practice of roughly 15-33 ohm is illustrative, not a requirement), so other +builds of this carrier should not assume 12 ohm is universally correct. + +Operating posture: the **12 ohm parts stay installed** and **no further +resistance changes** are permitted until all three owner-run acceptance +gates below are recorded. The **4096 kbit/s** conservative limit remains in +force until then; one immediate speed read does not justify higher WFB +settings or any claim about long-term signal margin. + +## Audited sources + +Audited 2026-10-02. Everything the firmware ships is stock upstream of this +builder overlay — the per-device delta in this repository carries no USB +configuration at all. Exact provenance used for the audit: + +| Artifact | Source | Ref | +| --- | --- | --- | +| Kernel | `github.com/openipc/linux`, branch `sigmastar-infinity6e` | branch tip `97b7fc4e` at audit time, Linux 4.9.84 (the defconfig pins the branch, not the SHA, so later builds may move) | +| Kernel ref resolution | `OpenIPC/firmware` `general/external.mk` | `OPENIPC_KERNEL := $(OPENIPC_SOC_VENDOR)-$(OPENIPC_SOC_FAMILY)` | +| Kernel config | `OpenIPC/firmware` `br-ext-chip-sigmastar/board/infinity6e/infinity6e-ssc012b.config` | selected by this device's defconfig (`BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE`); moving master, HEAD `1b0d5e2` at audit time | +| DTB | `arch/arm/boot/dts/infinity6e-ssc012b-s01a.dtb`, built from the in-tree DTS and **compiled into the kernel Image** (`CONFIG_SS_BUILTIN_DTB=y`, `CONFIG_SS_DTB_NAME="infinity6e-ssc012b-s01a"`) | same kernel ref | +| WiFi driver | OpenIPC package `rtl88x2eu-openipc` → `github.com/libc0607/rtl88x2eu-20230815` (HEAD) + one cflags patch | `general/package/rtl88x2eu-openipc/rtl88x2eu-openipc.mk` | +| Builder overlay | this repository, `devices/ssc338q_fpv_openipc-urllc-aio/` | working tree | + +The bootloader does not hand the kernel an FDT on this platform: with +`CONFIG_SS_BUILTIN_DTB=y`, `arch/arm/kernel/devtree.c:281-299` falls back to +the DTB embedded in the Image and merges the bootloader's ATAGs (memory, +cmdline) into it. The audited DTS is what the running kernel sees. + +### Active DT node (matches the reported runtime state) + +`arch/arm/boot/dts/infinity6e.dtsi:818-828`: + +``` +Sstar-ehci-1 { + compatible = "Sstar-ehci-1"; + clocks = <&CLK_utmi>; + camclk = ; /* compiled out: CONFIG_CAM_CLK is not set */ + interrupts = ; + dpdm_swap=<0>; + power-enable-pad = ; + status = "ok"; +}; +``` + +`PAD_UNKNOWN = 0xFFFF` (`drivers/sstar/include/infinity6e/gpio.h:150`). +The board DTS `infinity6e-ssc012b-s01a.dts` applies **no** USB override, and +`CONFIG_SS_BUILTIN_UNFDT` is not set, so the kernel Image's builtin DTB is the +only device tree in play (see the boot path above). This matches the runtime +facts exactly. + +### Kernel config (USB-relevant, `infinity6e-ssc012b.config`) + +- `CONFIG_USB_EHCI_HCD=y` built-in; xHCI/OHCI/DWC2/DWC3 disabled; USB 3.0 node + unused for this radio. +- `CONFIG_MP_USB_MSTAR=y` — enables the Sstar patch set in + `drivers/usb/host/ehci-hcd.c` and `drivers/usb/core/hub.c`. +- `# CONFIG_SS_USB_LOWPWR_SUSPEND is not set`; no USB PHY framework drivers + (all UTMI handling is inside the Sstar EHCI driver). +- `CONFIG_USB_ANNOUNCE_NEW_DEVICES=y` — dmesg reports the enumerated speed. + +## HS chirp / squelch / reset / PHY-tuning paths (as built) + +All tuning is compile-time; there are no runtime knobs in this repo. + +1. **Probe-time UTMI init** — `drivers/sstar/usb/host/ehci-mstar.c`, + `Titania3_series_start_ehc()` (lines 232-579), called from + `ehci_hcd_mstar_drv_probe()` for `soc:Sstar-ehci-1` (call at line 681): + - USBC `0x0a`/`0x28` handshake resets the UHC MAC (lines 297-298). + - CA (RX calibration) start/poll at UTMI `0x3c` with a "CA Fail" warning if + the result reads all-ones or all-zeros (lines 330-339). + - Squelch/disconnect level: `UTMI_DISCON_LEVEL_2A = 0x62` + (`ehci-mstar.h:310`) written to UTMI `0x2a` (lines 323-328, 396-397). + - Chirp source select UTMI `0x15` bit5 (line 387); new-HW chirp overwrite + cleared at UTMI `0x40` bit4 (line 394). `ENABLE_NEW_HW_CHRIP_PATCH` is + **not** defined, so the chirp-detect-level register UTMI `0x42` keeps its + hardware default. + - Eye/ TX tuning: `UTMI_EYE_SETTING_2C..2F = 0x10,0x02,0x00,0x81` + (`ehci-mstar.h:355-361`) at UTMI `0x2c..0x2f` (lines 406-410). + - `ENABLE_HS_CONNECTION_FAIL_INTO_VFALL_ECO` is on (`ehci-mstar.h:152`), + USBC `0x11` bit1 (line 453) — the known "HS connection fails into VFALL" + mitigation is active. + - DP/DM swap: `_USB_UTMI_DPDM_SWAP_P0 = 0` (`ehci-mstar.h:294`) and + `dpdm_swap=<0>` in DT (probe lines 674-678 OR the DT value into `flag`) + both agree: no swap. UTMI `0x0b` bit5 stays clear. + - `_USB_ANALOG_RX_SQUELCH_PATCH = 0` (`ehci-mstar.h:254-258`): the + CA-calibration-based squelch adjustment is compiled out. +2. **Per-port-reset chirp window** — `drivers/usb/core/hub.c` + `hub_port_reset()` (lines 3124-3216), the `_USB_HS_CHIRP_PATCH` block, runs + on every root-hub port reset for USB 2.0: + - Before asserting reset: eye parameters zeroed (UTMI `0x2c..0x2f`) and + squelch switched to `0x80` at UTMI `0x2a` (line 3168) — the value the + Sstar chirp patch uses inside the reset window to catch a weak device + chirp. + - After the reset: eye parameters and squelch `0x62` restored, then a + UTMI TX/RX software-reset pulse (UTMI `0x06` bits1:0, lines 3207-3212). + - The FS/HS verdict comes from the EHCI port status alone. The + speed-report cross-check against the UHC `0x84/0x85` registers is + guarded by `_USB_SPEED_REPORT_RESET_PATCH`, which is referenced at + `hub.c:3007` but **never defined anywhere** — that block is compiled + out in this build. +3. **Full-speed fallback latch** — `hub.c` "bad dev" retry (lines 6113-6165): + after repeated failed enumerations the driver sets UHC `0x40` bit7 + ("force full speed", line 6138, via `hcd->ehc_base`); it is cleared on + root-hub reinit when the + device disconnects (lines 2353, 5557-5559). A device that enumerates + successfully at FS from insertion did not need this latch — the port + verdict itself was FS. +4. **VBUS gating** — `drivers/sstar/usb/host/infinity6e/usb_pad.c` + `Enable_USB_VBUS()` (lines 49-106): the DT property is present + (`0xffff`), so the fallback default (`PAD_PM_GPIO2`) is not used; the value + is truncated to `(unsigned char)0xffff = 255` (line 80). 255 is out of + range on this SoC — `GPIO_NR = 127` + (`drivers/sstar/include/infinity6e/gpio.h:149`, range-checked in + `mhal_pinmux.c:2054`) — so `gpio_request(255)` fails and the function + returns early. The probe ignores the return value + (`ehci-mstar.c:680`). Net effect: **no kernel-side VBUS gate**; VBUS to + the module is board-hardwired. Consistent with the device enumerating at + all. +5. **Clocks** — nothing in Linux consumes `CLK_utmi`/`CAMCLK_utmi` for this + controller: the EHCI driver contains no clock/camclk code at all, so the + UTMI reference clock state is inherited from the bootloader. There is no + in-Linux analog power-cycle; the closest in-kernel equivalent is a full + HCD unbind/rebind (below), which re-runs the whole + `Titania3_series_start_ehc()` block including CA calibration. +6. **WiFi driver** — `rtl88x2eu-20230815` `os_dep/linux/usb_intf.c` + (lines 637-661) passively records `pusbd->speed` (`USB_SPEED_FULL` → + `RTW_USB_SPEED_1_1`). There is no module parameter, retry or force-HS + logic in the Realtek driver; at most it *adapts* to the reported speed + (e.g. `USB_FULL_SPEED_BULK_SIZE` in `include/usb_ops.h:128-145`). The + speed is decided entirely by the host controller/PHY. + +## Why no device-specific software discrepancy was found (in this repository) + +- This repository's per-device delta for `ssc338q_fpv_openipc-urllc-aio` + contains no USB-host configuration anywhere: the defconfig selects + packages/flash size only, `load_sigmastar` drives the camera pipeline only, + the overlay seeds WiFi/wifibroadcast config, and the exclude list only + trims rootfs files. +- The defconfig is byte-identical to the closest sibling device + (`ssc338q_fpv_openipc-mario-aio`), so there is no per-device divergence to + correct. +- Kernel, builtin DTB and kernel config are stock `openipc/linux` + `sigmastar-infinity6e` / `OpenIPC/firmware` artifacts; the DT state + (`dpdm_swap=0`, `power-enable-pad=0xffff`) matches the reported runtime + state, i.e. the firmware built is the firmware audited. +- The FS fallback mitigations that exist in the kernel (chirp-window squelch + `0x80`, VFALL ECO) are compiled in and active for this build; the + speed-report cross-check is compiled out (undefined macro), which weakens + detection of a mis-reported speed but cannot by itself cause one. +- Therefore a device-specific **software** correction within this repository + is not justified by the evidence. A real fix would be a kernel-side change + (openipc/linux driver/DT) or hardware — both outside this overlay's scope. + +### Candidate corrections considered and rejected + +- `dpdm_swap=<1>`: a swapped D+/D- pair would break full-speed enumeration + too (same pair, same polarity); the device enumerates at FS, so polarity is + correct. Flipping it would kill enumeration entirely. Rejected. +- Enable `_USB_ANALOG_RX_SQUELCH_PATCH` or change `UTMI_DISCON_LEVEL_2A` / + eye settings: driver-source macro changes in `openipc/linux`, with no + in-repo evidence to pick values; the chirp window already uses the most + sensitive squelch (`0x80`). Rejected without on-hardware UTMI measurements. +- `power-enable-pad` → a real pad: VBUS is evidently board-hardwired + (device enumerates with the property at `PAD_UNKNOWN`); pointing the gate + at a wrong pad risks switching VBUS off. Rejected. +- WiFi driver module options: none exist that influence enumeration speed + (driver is passive). Rejected. + +## HiLink D+/D- hardware / rework investigation boundary + +Assembly as observed (2026-10, Piotr): the radio is a custom +carrier/module — not a drop-in dongle — connected to the host by a +**four-wire harness/pad** connection, with **two RF pigtails** and visible +**local regulation** on the carrier. The pad assignments have **not** been +documented yet; nothing below assumes one. + +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 and through the four-wire + harness: continuity and symmetry from the SSC338Q pads to the module + pads; controlled impedance along the pair; stubs or test points hanging + off it; series resistors / ESD protection / common-mode chokes or other + intervening components; via, connector/harness 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. + +**Next physical gate (before any rework):** + +1. **Macro photographs of both sides** of the carrier/module — not yet + reported. +2. **Identify all four host pads** — determine which are VBUS, GND, D+, + D- (the four-wire harness implies the classic set, but the actual + assignment must come from tracing, not assumption) — not yet reported in + full; the two data nets and their series resistors have been traced (see + the fixed observations above). +3. **Trace D+/D- end to end**, identifying every intervening component — + series resistors, ESD arrays, common-mode chokes, vias, connectors, + harness wires — and where the pair leaves the board. **Status: performed + for both data nets** — each net is `SSC338Q-side -> ~100 ohm series + resistor -> module D+/D-`, each resistor measuring ~100 ohm across its + own endpoints, de-energized. No other intervening component was reported + on the data nets. + +**Safety rule for all continuity/ohmmeter work:** only with **all power +removed and rails discharged** (unplug, then verify the rails are at 0 V +before touching meter probes to pads). No powered measurements are proposed +at this stage. + +### Series-damping experiment — COMPLETED AND SUCCESSFUL (2026-10, Piotr) + +**Result:** instead of the planned parallel-resistor step, Piotr performed a +direct A/B replacement: **both 100 ohm per-line series resistors were +replaced with matched 12 ohm parts**, and `/sys/bus/usb/devices/1-1/speed` +returned **`480`** immediately afterward. This **proves the original 100 +ohm-per-line network blocked High-Speed negotiation** on this unit. The +proposed parallel route below is **superseded** (never executed) and is kept +only as the historical rationale for why the series value was the prime +suspect. + +Rationale (historical): if the ~100 ohm per-line series resistors over-damp +the pair, reducing the effective per-line series resistance into the range +of common external USB 2.0 practice may let the HS chirp/eye reach the host +squelch/timing margins again. This was a **bounded, fully reversible** +framing: the target value was an example chosen from common practice, +**not** the documented SSC338Q PHY/reference-design requirement, which +remains undocumented in this repository. + +Proposed steps as planned (historical — superseded by the direct +replacement actually performed; retained for reproducibility of the method): + +Pre-flight gate (no soldering before this is done): + +1. Confirm the two resistors' **package size** and mark their **exact + locations** (photograph before touching anything). +2. Confirm the workmanship/ESD plan for soldering on the carrier. + +Experiment (reversible — nothing is removed, parts are added in parallel): + +1. With **all power removed and rails discharged and verified at 0 V** + (same rule as above). The work setup itself must not be able to feed + voltage onto the unpowered board — including through the soldering + iron's supply path — so use an isolated or battery-powered iron or + equivalent isolation. Solder **one matched resistor in parallel across + each** existing 100 ohm part — **D+ and D- must be treated + identically**. +2. Example value: 33 ohm in parallel with 100 ohm gives an effective + (33 x 100) / (33 + 100) = 3300 / 133 = **24.8 ohm per line** (~25 ohm). + Any parallel pair follows R_eff = (R1 x R2) / (R1 + R2); keep the same + value on both lines. +3. Inspect under magnification for **bridges, solder balls or damage** to + the parts and neighbours; the two lines must look identical. +4. **Before restoring power**, measure each modified net again (de-energized) + and confirm both read the same effective value, within part tolerance. +5. Restore power **only after inspection** and run a fresh USB enumeration + check (`cat /sys/bus/usb/devices/1-1/speed`). + +**Acceptance criterion:** actual **480** Mbit/s negotiation. The +enumeration result is the only judge of this test: no final line impedance +or eye-quality outcome is assumed without signal-integrity measurement (a +later diagnostic above). If behaviour regresses in any way or HS is **not** +achieved, **revert immediately**: remove the parallel parts to restore the +original ~100 ohm per line, and record what was observed. Until HS is +actually demonstrated, keep the **4096 kbit/s** operating limit (see the +conclusion) regardless of this experiment. (That historical condition is +now met — the current rule for the 4096 kbit/s limit is the acceptance +gates in the next subsection, not this paragraph.) + +### Acceptance gates after the successful rework (outstanding, owner-run) + +Immediate HS restoration is **not yet full acceptance**. The 12 ohm parts +stay installed, and **no further resistance changes** are to be made until +all three of these gates are recorded on this unit: + +1. **Fresh dmesg** shows a new high-speed enumeration for the radio without + relevant USB errors. +2. A **full `soc:Sstar-ehci-1` platform-driver unbind/bind** (step 5 in the + on-device section below, over Ethernet/console) still returns `480`. +3. The **established wifibroadcast baseline operates stably** with no USB + disconnect/reset events during operation. + +The **4096 kbit/s** conservative limit stays in force until all three pass; +do not infer higher WFB settings or long-term signal margin from the single +immediate `480` read. Safety/rework provenance as documented above applies: +all board work was and remains de-energized work with verified discharged +rails. + +Isolation diagnostics (historical — moot on this unit now that the root +cause is fixed and HS is restored; retained for future units of this +carrier or if symptoms return; all of them need rework access — the radio +is pad-connected, not socketed, so this may mean a temporary rework socket +or piggyback harness): + +- Try a **known-good HS USB device** (any USB 2.0 flash disk) on the same + host pads. HS on the disk but not on the radio points at the + carrier/module side; FS on both points at the board-side pair. +- Try the **RTL8812EU carrier on a different known-good HS host** (a PC). + HS there isolates the fault to this board's physical path. +- With suitable equipment, capture the HS chirp amplitude/eye at the host + pads 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. + +Evidence status: the platform-driver re-probe (step 5 below), the +input-supply-capacity change, the module-input voltage measurement, the +per-line series-resistor tracing (de-energized resistance checks), and the +series-resistor replacement (100 ohm -> matched 12 ohm per line, both data +nets) were performed on hardware (2026-10, Piotr). The replacement restored +`480` immediately; the three acceptance gates above are **outstanding**. +The register-read diagnostics (steps 1-4 below) have not been reported; the +parallel-resistor variant was never executed. + +## 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`, +`drivers/sstar/include/ms_platform.h:24`, plus `registers.h:37-38`). Register +number `n` sits at byte offset `2*n`, except odd `n` which sits at `2*n - 1` +(exactly what `hcd_readb` does, `hub.c:116-129`). All reads are byte or +16-bit reads at these byte addresses. + +| Block | Base (physical) | Derived from | +| --- | --- | --- | +| UTMI0 | `0x1F284200` | `_MSTAR_UTMI0_BASE = 0xFD200000 + 0x42100*2` (`ehci-mstar-chip.h:37`) | +| USBC0 | `0x1F284600` | `+ 0x42300*2` (`ehci-mstar-chip.h:39`) | +| UHC0 (EHCI) | `0x1F284800` | `+ 0x42400*2` (`ehci-mstar-chip.h:40`) | + +1. **Current enumerated speed** + ``` + cat /sys/bus/usb/devices/*/speed # expect 12 (FS symptom) or 480 (HS fixed) + dmesg | grep -E 'new (full|high)-speed USB device' + ``` +2. **Force-full-speed latch check** (stuck FS from a past failed HS enum) + ``` + devmem 0x1F284880 8 # UHC+0x40 bit7: 0x00/0x80 + ``` + Expected if healthy: bit7 clear. If bit7 is set, a previous enumeration + failure latched FS; disconnect/reconnect the module's power (the + root-hub reinit on disconnect clears it) and repeat. +3. **Port / line state** (all UHC0 = EHCI bank, `hcd->ehc_base`; bit + semantics as used by the driver: `hub.c:4998` enable=bit2, `urb.c:532` + connect=bit0, `message.c:88` csc=bit1, `hub.c:5801-5802` line state) + ``` + devmem 0x1F284860 8 # UHC+0x30: bit0 connect, bit1 csc, bit2 enable + devmem 0x1F284881 8 # UHC+0x41: bits2:1 line state (odd reg -> 2n-1) + devmem 0x1F284908 8 # UHC+0x84: bit7 of the speed report + devmem 0x1F28490A 8 # UHC+0x85: bits3:0 of the speed report + ``` + Speed-report composition (`hub.c:3007-3030`; the kernel-side cross-check + is compiled out — these are raw hardware registers): + `spd = (bit7 of UHC+0x84) | ((UHC+0x85 & 0xf) << 1)`; `0x0c` = high + speed, `0x06` = full speed. +4. **UTMI tuning as left by the driver** + ``` + devmem 0x1F284254 8 # UTMI+0x2a squelch: expect 0x62 idle + devmem 0x1F284278 16 # UTMI+0x3c CA calibration (16-bit) + ``` + `CA_FAIL` signature (as the driver checks it, `ehci-mstar.c:337-339`): + 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) — 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 + echo > /sys/bus/platform/drivers/Sstar-ehci-1/bind + ``` + Safety: `wlan0` on this device is the USB radio itself (`8812eu`, + `S40network:6`), so unbinding the EHCI **takes wlan0 down** — run this + from Ethernet or a serial console, never over the USB radio's link. The + radio disappears and re-enumerates after `bind`; if `wlan0` does not come + back on its own, re-run the network init (`/etc/init.d/S40network` + 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 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. 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). 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.