USB3 mass storage issues on Verdin IMX8MP

Technical Support
,
1

Hi,

We’ve recently encountered some unusual behavior related to USB3 on our custom product based on the Verdin iMX8MP and linux kernel 5.15 (based on Toradex/NXP downstream Linux repo).
Specifically, USB3 mass storage devices either take a long time to be detected (30–60 seconds) or are not detected at all. Interestingly, when we force the device into USB2 mode by using a USB 2.0 cable, the issue disappears entirely.

This behavior was not present with earlier kernel versions.

To simplify reproduction, I tested the issue using a Toradex Dahlia carrier board with a Verdin iMX8MP module, running the downstream Linux Multimedia Reference Images.

I flashed versions 6.8.1, 6.8.2, and 6.8.3 of the reference image and tested detection of a USB3 mass storage device (SanDisk Ultra Flair) both during boot and via hotplug. I repeated the tests using a USB 2.0 cable to force USB2 mode. Detection was verified via kernel logs and lsusb.

Please see the table below for detailed results.

Image Version USB 3.0 Device (Plugged in before boot) USB 3.0 Device (Hot plug) USB 3.0 Device in USB 2.0 Mode (Plugged in before boot) USB 3.0 Device in USB 2.0 Mode (Hot plug)
6.8.1 Detected Detected Detected Detected
6.8.2 Detected Not detected or delayed Detected Detected
6.8.3 Detected Not detected or delayed Detected Detected

Do you have any insights in whether this functionality got broken, and what can be done to fix it? Thanks in advance!

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:

USB3 Detection Issues on Verdin iMX8MP

Based on your test results, you’re experiencing USB3 detection issues specifically with hotplug scenarios starting from BSP version 6.8.2. The Dahlia Carrier Board provides USB functionality through its USB DRP connector (X3) which is configured as a dual-role port with output current limited to 1A (1).

USB Port Configuration on Dahlia

The Dahlia Carrier Board uses the TUSB321AI chip to handle USB dual-role port operations, functioning as upstream-facing port (UFP), downstream-facing port (DFP), or dual-role port (DRP) (1). The USB DRP connector (X3) provides USB Type-C connectivity with the following key signals (1):

  • USB_1_D_CON_P: Positive differential USB 2.0 signal (SODIMM Pin 165)
  • USB_1_D_CON_N: Negative differential USB 2.0 signal (SODIMM Pin 163)
  • +V5_VBUS_USB_1: +5V USB power output (SODIMM Pin 159)

USB Host Mode Control Options

For troubleshooting USB detection issues, you can use the uhubctl tool to control USB hub ports (2). This allows you to switch off unused USB devices to save power or power cycle USB devices (2). You can check which hubs support port switching with:

uhubctl

(2)

To power cycle a USB port, you can first remove the USB device from the runtime configuration and then switch off power (2):

echo 1 > /sys/bus/usb/devices/[device-path]/remove
uhubctl -l [hub] -p [port] -a off
uhubctl -l [hub] -p [port] -a on

(2)

Hardware Version Considerations

The Verdin iMX8M Plus modules have undergone hardware revisions that affect USB functionality. Automatic role switching for the USB_1 (OTG) Verdin interface was not functional with previous hardware versions but is supported and functional when used with BSP 5.6.0 Quarterly Release or newer (3)(4).

Recommendations

  1. Power Cycling: Try using uhubctl to power cycle the USB port when detection fails
  2. USB Speed Configuration: The USB host configuration allows limiting the maximum speed during negotiation (2) - you might want to investigate if there are speed-related configuration changes between BSP versions
  3. Hardware Revision Check: Verify your Verdin iMX8MP hardware version to ensure compatibility with the BSP version you’re using

The fact that USB2 mode works consistently suggests this may be related to USB3-specific initialization or timing changes introduced in BSP 6.8.2.

Best regards, Toradex AI Assistant.

3

Hello @mathijs,

Thanks for the detailed description of the problem.
We will try to reproduce the issue and get back to you with more information.

Best Regards,
Bruno

4

Hello @mathijs,

I was able to see the same behavior you described.
I have raised this internally to our domain experts who will look into what may have caused this problem.

Once there are further updates I will send them here.

Best Regards,
Bruno

1 Like
5

Hi,

One thing that seems to be a workaround for this issue (atleast, on our custom board where we use only USB0), is to disable the suspend/power management:

&usb_dwc3_0 {
    snps,dis_u3_susphy_quirk; // Disable USB3 suspend
    snps,dis_u2_susphy_quirk; // Disable USB2 suspend
};

When I apply this, then usb detection reacts within 1s.

Of course, this is a workaround, and we would love a more thorough solution. Is there any news from the domain experts?

Thanks in advance,

Mathijs

6

Hello @mathijs,

Thanks for the update.
I have let our team know about this workaround.

Regarding the current state, our domain expert was able to reproduce the issue as well.
Gathering some more information on the symptoms of the issue.
Our BSP team is currently working on a fix.
Once a fix is available, I will send an update here.

Best Regards,
Bruno

7

Hello @mathijs,

Our team has identified a bug in the power down portion of the USB controller driver.
A proposed fix is currently under review.
When the fix is merged, I will send an update here.

Best Regards,
Bruno

8

Hello @mathijs,

The fix has been merged: linux-toradex.git - Linux kernel for Apalis, Colibri and Verdin modules

Nightly pre-releases of 6.8.4 from today or tomorrow should already have the fix.
The next release with the fix will be 6.8.4.

Best Regards,
Bruno

9

I rebased our kernel on the changes and it indeed seems to solve it. Thanks!

Kind regards,

Mathijs

10

Hello @mathijs,

Thanks for the update, that is good to know.

Best Regards,
Bruno