Jump to content

USB3 Port Issues on Radxa Zero 3 (Armbian vs. Vendor Builds): USB hub fails, upside-down speed bug


Recommended Posts

Posted (edited)

I’ve noticed two USB-C/USB3 issues with the Radxa Zero 3{E,W} when running Armbian (Edge & Current), which don’t occur on Radxa’s vendor builds (kernel 6.1).

 

1. Issues

  • All branches (Vendor, Current, Edge)
    • Depending on cable orientation, USB3 devices register inconsistently on either:  
      • Bus 001 → USB 2.0 (480M)  
      • Bus 002 → USB 3.0 (5000M)  
    • Reference: previous forum post
       
  • Armbian dfb7c4fCurrent (6.12) & Edge (6.16)
    • My unpowered USB3 hub fails to work at all (it's fine on Radxa's builds & Vendor).
    • On touch, the hub feels more electrically charged than on vendor builds.
    • Plugging in a single device works, but it will still suffer from the cable “upside-down” speed bug.

 

2. Logs

  • Vendor branch
    • armbianmonitor -u: link
  • Edge branch (same behavior as Current)
    • armbianmonitor -u: link
  • Tried with U-Boot master and ATF mainline → no improvement  
    • build script diffs: link
    • U-Boot: 0c558bb
    • ATF: still v2.13, cannot set branch:master (or 9ee2ff1 directly) as Armbian's build script will fail
  • lsusb {-t} outputs: link
  • Build command used:
    ./compile.sh build BOARD=radxa-zero3 BRANCH=edge RELEASE=trixie \
      BUILD_DESKTOP=yes BUILD_MINIMAL=no \
      DESKTOP_ENVIRONMENT=gnome \
      DESKTOP_APPGROUPS_SELECTED="browsers desktop_tools" \
      KERNEL_CONFIGURE=no

 

3. Notes

  • My USB-PD passthrough adapter’s ethernet device does not appear on the OTG port (seems broken on both Armbian & Radxa vendor images).
  • No relevant fixes appear left in the kernel repos:

 

4. Device Tree References

 

I think this is due to the DT overlays, but this is a new topic for me. Could somebody please help me or point towards the next steps?

Edited by twwn
formatting
Posted

thank you for the extensive testing and superb documentation, @twwn  You do know how to compile your own images, right?  Did you try vendor kernels with an Armbian image already?

 

it's very odd that orientation of the USB-C cables matters.  I thought it was one of the design principles of USB-C that it shouldn't.

Posted

Yes, the vendor image was compiled by myself.

 

I'm not that bothered by the orientation bug, but the inability to operate a hub given a single USB port badly curtails the use of the SBC.

 

Unfortunately device tree issues are entirely out of my league.

 

I've also edited my post to update the build script diffs. For one, I wasn't actually using ATF master, apparently it was just a cached v2.13. Armbian's build script (at least the rockchip64 part) actually breaks if you set ATFBRANCH='branch:master'.

 

I'll try to get the minor fixes merged, but unfortunately BOOT_SCENARIO="binman-atf-mainline", while now working fine for current and edge, would break vendor as it needs to be set globally.

Posted
15 hours ago, twwn said:

Yes, the vendor image was compiled by myself.

 

20 hours ago, twwn said:

don’t occur on Radxa’s vendor builds (kernel 6.1).

 

Just to clarify, you did try the Armbian vendor build as well or only Radxa's vendor build?

Posted

@twwn

 

Add to rk3566-radxa-zero-3.dtsi -->  snps,usb2-lpm-disable;

https://github.com/armbian/build/blob/main/patch/kernel/archive/rockchip64-6.12/dt/rk3566-radxa-zero-3.dtsi#L495

 

 &usb_host0_xhci {
	dr_mode = "peripheral";
+	snps,usb2-lpm-disable;
 	status = "okay";
 };

 

See if it makes a difference.

 

Information:

https://www.kernel.org/doc/Documentation/devicetree/bindings/usb/dwc3.txt

Posted

This remembers me a recent set of changes to the DWC3 driver for RK3399 to fix exactly these kind of issues exposed here, including the single-orientation problem, plus some more issues with the displayport over usb type-c functionality.

 

The PR had a lot of comments but finally it got merged because both the author and me tested the whole apparatus and it proved to improve significantly the situation on rk3399: https://github.com/armbian/build/pull/8271


Patches should address some issues in the dwc3 driver in general, and I see from the device tree that rk356x uses the snps,dwc3 compatibility string, so probably also rk356x benefits from them as well. It would although require some device tree tinkering: I tested on Orange PI4 LTS board and the device tree fixes are within this hunk; rk356x-based devices can probably share several declarations but that depends upon the rk356x capabilities. I would start from changing dr_mode to otg and removing regulator-always-on; property from the vbus supply.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines