Hello,
I traced and worked around a USB enumeration failure on an X96S TV stick (Amlogic S905Y2, 4 GB RAM / 32 GB eMMC). I am posting this as an RFC and test request, not as an upstream-ready Armbian patch.
Important environment note
• Userspace: Armbian OS 26.05.0 Noble
• Kernel: Linux 6.12.91 from the OPhub/unifreq TV-box tree, not an official Armbian kernel package
• Exact source baseline: unifreq Linux commit 7f96286d7ef097465fe46dbea8002fa27a6a6bbc
• DT reports model "AMedia X96 Max" and compatible "amediatech,x96-max", "amlogic,g12a". This is not an accurate X96S-specific identity.
Symptoms
HDMI and Wi-Fi worked, but USB2 devices would not enumerate. The physical USB2 port detected connect/disconnect events, yet a reset write did not latch. PORTSC remained at 0x000006e1: Powered, Connected, Disabled, Polling. USB storage and HID devices therefore never appeared.
Comparison with CoreELEC
The same unit and USB devices work with CoreELEC's Amlogic 4.9 kernel. That vendor xHCI path reports two USB2 ports and zero USB3 ports when the vendor "super_speed_support" property is absent. Linux 6.12 instead exposes the controller capability as two USB2 ports plus one USB3 port, although this X96S has no usable SuperSpeed route.
Finding and workaround
After xHCI supported-protocol parsing, I forced the USB3 root-hub port count to zero while retaining the two-HCD/root-hub topology. This matches the working vendor-kernel structure. It is guarded by an off-by-default kernel parameter:
xhci_hcd.x96s_vendor_usb2_only=1
The relevant change in drivers/usb/host/xhci-mem.c is:
static bool x96s_vendor_usb2_only;
module_param_named(x96s_vendor_usb2_only,
x96s_vendor_usb2_only, bool,
S_IRUGO | S_IWUSR);
...
if (unlikely(x96s_vendor_usb2_only)) {
xhci_warn(xhci,
"X96S diagnostic: suppressing %u USB3 root-hub port(s)\n",
xhci->usb3_rhub.num_ports);
xhci->usb3_rhub.num_ports = 0;
xhci->allow_single_roothub = 0;
}
This block is placed at the end of xhci_setup_port_arrays(), after the supported-protocol loop and before the "No ports on the roothubs?" check. The patch also includes linux/module.h and linux/moduleparam.h and adds a MODULE_PARM_DESC.
Result
With the patched kernel and the opt-in command-line parameter:
• The USB2 reset completes: 0x000006e1 -> 0x00200e03 (PRC, Enabled, U0, high-speed).
• A PicoN USB flash drive (0a6b:000f) enumerates at 480 Mbit/s.
• Direct read throughput was about 29.4 MB/s.
• Cold-boot enumeration and repeated hotplug both work.
• HDMI remains connected and Wi-Fi/SSH continue to work.
• The USB3 root hub remains present but has zero ports, as in the working vendor 4.9 topology.
Reproduction outline
1. Apply the change to the exact kernel source/config used by the image.
2. Build and install a matching Image, modules and initramfs; do not mix kernel modules from another release.
3. Add xhci_hcd.x96s_vendor_usb2_only=1 to the existing kernel command line.
4. Cold boot, then verify uname -r, /proc/cmdline, lsusb -t and dmesg.
5. Expect the log "X96S diagnostic: suppressing 1 USB3 root-hub port(s)" and USB2 devices at 480M.
Limitations / upstream direction
I tested one X96S unit/revision only. Do not enable this workaround on a G12A device with a real USB3 path. The X96S-specific module parameter is useful for diagnosis and recovery, but it is probably not the right final upstream interface. A proper fix may belong in the DWC3/xHCI integration and should be DT/controller-driven, for example by correctly honoring a USB2-only maximum speed or absence of a SuperSpeed PHY. It also needs regression testing on genuine USB3-capable G12A boards.
The standard maximum-speed = "high-speed" DT property alone did not change the xHCI root-hub port count in this setup.
Test request
If anyone has another X96S, especially a different board revision, please report:
tr -d '\0' </proc/device-tree/model; echo
tr '\0' '\n' </proc/device-tree/compatible
uname -r
lsusb -t
Please also say whether USB HID, storage, hubs, cold boot and hotplug work with or without the workaround. Results from a comparable G12A board with working USB3 would be especially useful before designing a generic fix.
Background X96S thread:
https://forum.armbian.com/topic/16014-tv-stick-x96s-with-amlogic-s905y2/
Thanks.