From e28472c5bd0268543ce49fa72ea4538832dde294 Mon Sep 17 00:00:00 2001 From: Hermes Date: Fri, 2 Oct 2026 16:51:56 +0200 Subject: [PATCH 1/5] hilink: document the RTL8812EU USB full-speed enumeration investigation --- .../USB-HS-INVESTIGATION.md | 270 ++++++++++++++++++ 1 file changed, 270 insertions(+) create mode 100644 devices/ssc338q_fpv_openipc-urllc-aio/USB-HS-INVESTIGATION.md 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..e2fc559 --- /dev/null +++ b/devices/ssc338q_fpv_openipc-urllc-aio/USB-HS-INVESTIGATION.md @@ -0,0 +1,270 @@ +# RTL8812EU enumerating at 12 Mbit/s on `Sstar-ehci-1` — investigation record + +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 enumerates at **12 Mbit/s (full speed)** after USB + unbind/rebind cycles. +- The active device tree reports `dpdm_swap = <0>` and + `power-enable-pad = ` (0xffff). +- 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. + +## 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 + +The remaining candidates are analog/hardware and are 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. +- 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. +- 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. + +## Safe on-device verification (reads only, plus one reversible re-probe) + +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). + +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; replug the module (root-hub reinit 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)** + ``` + 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 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. +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: + 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. -- 2.54.0 From 17caa64ed7f75bfc91b9ede3c9b6983ad5ec4191 Mon Sep 17 00:00:00 2001 From: Hermes Date: Sat, 3 Oct 2026 12:27:25 +0200 Subject: [PATCH 2/5] hilink: record verified USB HS hardware results and bound the fault domain --- .../USB-HS-INVESTIGATION.md | 78 ++++++++++++++++--- 1 file changed, 67 insertions(+), 11 deletions(-) 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. -- 2.54.0 From 2f30ea2a7bc003899a1a515e104c155a8e6d4d83 Mon Sep 17 00:00:00 2001 From: Hermes Date: Mon, 12 Oct 2026 13:27:20 +0200 Subject: [PATCH 3/5] hilink: record module-input voltage measurement and set the next physical gate --- .../USB-HS-INVESTIGATION.md | 100 +++++++++++++----- 1 file changed, 71 insertions(+), 29 deletions(-) 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 157007b..5446f0a 100644 --- a/devices/ssc338q_fpv_openipc-urllc-aio/USB-HS-INVESTIGATION.md +++ b/devices/ssc338q_fpv_openipc-urllc-aio/USB-HS-INVESTIGATION.md @@ -17,6 +17,14 @@ USB 2.0 EHCI port (`Sstar-ehci-1`). 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). - 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. @@ -29,13 +37,19 @@ 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). + 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). - **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 / 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. + boundary detailed in the hardware section below. The supply findings above + rule out only those two specific points: power **quality** downstream of + the measured input — supply noise/ripple and the carrier's local regulator + output — remains untested and stays inside this open fault domain. Two caveats stay attached to this classification: it does not prove that every conceivable undocumented analog register in the vendor PHY block is @@ -43,6 +57,10 @@ 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. +Operating posture while the fault stands: keep the existing +4096 kbit/s limit appropriate to full-speed operation; do not raise it on +the assumption of high-speed throughput until HS is actually demonstrated. + ## Audited sources Audited 2026-10-02. Everything the firmware ships is stock upstream of this @@ -205,37 +223,61 @@ All tuning is compile-time; there are no runtime knobs in this repo. ## 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: continuity and symmetry from the - 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. +- 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. -- 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. -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 +**Next physical gate (before any rework):** + +1. **Macro photographs of both sides** of the carrier/module. +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). +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. + +**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. + +Further isolation diagnostics, only **after** the gate above (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, and the module-input voltage measurement were +performed on hardware (2026-10, Piotr) — none improved negotiation, and the +ingress voltage is in range; all 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. @@ -272,8 +314,8 @@ number `n` sits at byte offset `2*n`, except odd `n` which sits at `2*n - 1` devmem 0x1F284880 8 # UHC+0x40 bit7: 0x00/0x80 ``` Expected if healthy: bit7 clear. If bit7 is set, a previous enumeration - failure latched FS; replug the module (root-hub reinit clears it) and - repeat. + 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) -- 2.54.0 From dff6783b3f751b8f08d5ed0c596e170992fb96ae Mon Sep 17 00:00:00 2001 From: Hermes Date: Mon, 12 Oct 2026 14:19:22 +0200 Subject: [PATCH 4/5] hilink: trace per-line 100-ohm USB series resistors, gate reversible HS test --- .../USB-HS-INVESTIGATION.md | 87 +++++++++++++++++-- 1 file changed, 79 insertions(+), 8 deletions(-) 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 5446f0a..b00d7ac 100644 --- a/devices/ssc338q_fpv_openipc-urllc-aio/USB-HS-INVESTIGATION.md +++ b/devices/ssc338q_fpv_openipc-urllc-aio/USB-HS-INVESTIGATION.md @@ -25,6 +25,11 @@ USB 2.0 EHCI port (`Sstar-ehci-1`). 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. - 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. @@ -57,6 +62,16 @@ 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. +**First concrete physical candidate:** the traced per-line ~100 ohm series +resistors (see the hardware section below). FS signaling at 12 Mbit/s is +edge-slow and tolerant, while HS chirp/negotiation is amplitude- and +timing-critical, so excessive series damping on both lines is consistent +with exactly this failure signature — FS survives, HS chirp is missed. This +is a **hypothesis with a matching signature, not a proven root cause**, and +the commonly seen external USB 2.0 series damping practice (roughly 15-33 +ohm) is **not** a substitute for the exact SSC338Q PHY/reference-design +requirement, which is not documented in this repository. + Operating posture while the fault stands: keep the existing 4096 kbit/s limit appropriate to full-speed operation; do not raise it on the assumption of high-speed throughput until HS is actually demonstrated. @@ -245,19 +260,72 @@ scope: **Next physical gate (before any rework):** -1. **Macro photographs of both sides** of the carrier/module. +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). + 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. + 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. +### Gated, reversible experiment: reduce per-line series damping + +Rationale: if the ~100 ohm per-line series resistors over-damp the pair, +reducing the effective per-line series resistance by roughly four times +(100 ohm -> ~25 ohm) into the range of common external USB 2.0 practice may +let the HS chirp/eye reach the host squelch/timing margins again. This is a +**bounded, fully reversible test**, not a repair commitment: the target +value below is an example chosen from common practice, **not** the +documented SSC338Q PHY/reference-design requirement, which must be confirmed +from vendor material if the test succeeds. + +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. + Further isolation diagnostics, only **after** the gate above (all of them need rework access — the radio is pad-connected, not socketed, so this may mean a temporary rework socket or piggyback harness): @@ -275,11 +343,14 @@ 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, and the module-input voltage measurement were -performed on hardware (2026-10, Piotr) — none improved negotiation, and the -ingress voltage is in range; all 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. +input-supply-capacity change, the module-input voltage measurement, and the +per-line series-resistor tracing (de-energized resistance checks) were +performed on hardware (2026-10, Piotr) — none of the software-adjacent +steps improved negotiation, the ingress voltage is in range, and the traced +topology is as recorded above. The parallel-resistor experiment **has not +been performed yet**; 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. ## On-device verification (read-only diagnostics; step 5 re-probe already completed on hardware) -- 2.54.0 From 36e63aeff0758b6743488b46769b479bfa22a012 Mon Sep 17 00:00:00 2001 From: Hermes Date: Thu, 15 Oct 2026 10:30:50 +0200 Subject: [PATCH 5/5] hilink: matched 12-ohm rework restores immediate 480 Mbit/s; acceptance pending --- .../USB-HS-INVESTIGATION.md | 142 ++++++++++++------ 1 file changed, 92 insertions(+), 50 deletions(-) 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 b00d7ac..639e97d 100644 --- a/devices/ssc338q_fpv_openipc-urllc-aio/USB-HS-INVESTIGATION.md +++ b/devices/ssc338q_fpv_openipc-urllc-aio/USB-HS-INVESTIGATION.md @@ -1,4 +1,4 @@ -# RTL8812EU enumerating at 12 Mbit/s on `Sstar-ehci-1` — investigation record +# 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 @@ -6,8 +6,9 @@ USB 2.0 EHCI port (`Sstar-ehci-1`). ## Fixed observations (treated as inputs, not re-derived here) -- The radio repeatedly enumerates at **12 Mbit/s (full speed)** after USB - unbind/rebind cycles. +- 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` @@ -30,10 +31,15 @@ USB 2.0 EHCI port (`Sstar-ehci-1`). 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 (current fault-domain classification) +## 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 @@ -46,35 +52,38 @@ remaining software-adjacent candidates that are cheap to test: 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). -- **Remaining fault domain:** 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. The supply findings above - rule out only those two specific points: power **quality** downstream of - the measured input — supply noise/ripple and the carrier's local regulator - output — remains untested and stays inside this open fault domain. +- **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 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. +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). -**First concrete physical candidate:** the traced per-line ~100 ohm series -resistors (see the hardware section below). FS signaling at 12 Mbit/s is +**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, so excessive series damping on both lines is consistent -with exactly this failure signature — FS survives, HS chirp is missed. This -is a **hypothesis with a matching signature, not a proven root cause**, and -the commonly seen external USB 2.0 series damping practice (roughly 15-33 -ohm) is **not** a substitute for the exact SSC338Q PHY/reference-design -requirement, which is not documented in this repository. +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 while the fault stands: keep the existing -4096 kbit/s limit appropriate to full-speed operation; do not raise it on -the assumption of high-speed throughput until HS is actually demonstrated. +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 @@ -280,16 +289,27 @@ 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. -### Gated, reversible experiment: reduce per-line series damping +### Series-damping experiment — COMPLETED AND SUCCESSFUL (2026-10, Piotr) -Rationale: if the ~100 ohm per-line series resistors over-damp the pair, -reducing the effective per-line series resistance by roughly four times -(100 ohm -> ~25 ohm) into the range of common external USB 2.0 practice may -let the HS chirp/eye reach the host squelch/timing margins again. This is a -**bounded, fully reversible test**, not a repair commitment: the target -value below is an example chosen from common practice, **not** the -documented SSC338Q PHY/reference-design requirement, which must be confirmed -from vendor material if the test succeeds. +**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): @@ -324,11 +344,34 @@ 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. +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.) -Further isolation diagnostics, only **after** the gate above (all of them -need rework access — the radio is pad-connected, not socketed, so this may -mean a temporary rework socket or piggyback harness): +### 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 @@ -343,14 +386,13 @@ 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, and the -per-line series-resistor tracing (de-energized resistance checks) were -performed on hardware (2026-10, Piotr) — none of the software-adjacent -steps improved negotiation, the ingress voltage is in range, and the traced -topology is as recorded above. The parallel-resistor experiment **has not -been performed yet**; 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. +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) -- 2.54.0