USB Device Detection Regression on X8 Bottom Port After Moving from Kirkstone to Scarthgap (Apalis iMX8QP + Ixora)

Hello Toradex team,

I’m reopening this topic because the issue described in the previous post
SuperSpeed USB storage device not detected on X8 (Bottom) with Apalis iMX8QM
doesn’t fully explain the behavior we’re observing.

Hardware setup

  • Module: Apalis iMX8QP v1.1E (also tested with v1.0B)
  • Carrier: Ixora v1.2A (also tested with v1.3A)
  • Ports: X8 Top (USB 3.0 SuperSpeed) and X8 Bottom (USB 2.0 High Speed)
  • Devices tested: Various USB 2.0 and 3.0 storage devices

Also to be notted, the apalis module we are using are iMX8QP v1.1E without wifi module and iMX8QP v1.0B with wifi module.

Software setup

  • Previously: Yocto Kirkstone based Toradex BSP (Boot2Qt)
    • Both X8 Top and Bottom ports detected USB sticks correctly
    • Top port enumerated SuperSpeed devices (as expected)
    • Bottom port enumerated High-Speed devices (also as expected)
  • Now: Yocto Scarthgap based Toradex BSP (Boot2Qt)
    • X8 Top still works correctly (SuperSpeed)
    • X8 Bottom no longer detects any USB device at all

What we already know
According to the Ixora documentation and prior responses, the X8 Bottom port is physically USB 2.0-only (shared with USB_OTG). That’s clear and expected.
However, this doesn’t explain the regression — since under Kirkstone, USB 2.0 devices and USB 3.0 sticks (enumerating as HS) were both detected fine, while under Scarthgap they are not detected at all.

Why this might be software-related

  • The behavior changed only after migrating to Scarthgap (same hardware combination).
  • The issue appears specifically on Apalis iMX8QP v1.1E + Ixora v1.2A (other combinations might not be affected, possibly due to wifi module presence?).

Thanks in advance for your help in investigating this regression.

Best regards,

I am also joining the demsg related to usb detection on kirkstone and scarthgap branches
apalis-imx8_usb-detection (2.9 KB)

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.


USB Configuration on Ixora Carrier Board

Based on the Ixora V1.2 and V1.3 datasheets, I can confirm your understanding of the hardware configuration. The X8 connector is a stacked USB 3.0 Type-A connector where:

  • X8 Top (U1-U9): Connected to USBH4 interface (USB 3.0 SuperSpeed) (1)(2)
  • X8 Bottom (L1-L9): Connected to USBO1 interface (USB 2.0 High Speed shared with OTG) (1)(2)

Hardware Configuration Details

The Ixora V1.2 datasheet confirms that the bottom part of connector X8 uses the USBO1 interface, which can be controlled via jumper JP2 (2):

  • JP2 Open: X8 bottom is not powered, X9 (Micro-AB) is used as OTG
  • JP2 Closed: Both X8 bottom and X9 are configured as HOST only

LED3 indicates when VCC_USBO1 voltage is enabled, confirming the bottom port is powered (2).

BSP Version Information

According to the BSP documentation, there are significant differences between the versions you’re using (3):

  • Kirkstone (BSP 6.0): Based on Yocto Project 4.0 LTS
  • Scarthgap (BSP 7.0): Based on Yocto Project 5.0 LTS

Assembly Options Consideration

The Ixora datasheets document assembly options that affect USB routing. By default, the configuration connects (1)(2):

  • USBH3 interface to USB Host connector (X7)
  • USBH2 interface to Mini PCIe Connector (X25)

However, assembly resistors can be modified to change this routing. The specific resistors mentioned are R96, R103, R118, R119 and R50, R69, R120, R126 (1)(2).

Potential Investigation Areas

Given that this is a regression from Kirkstone to Scarthgap on the same hardware, the issue is likely related to:

  1. Device Tree Changes: USB controller or hub initialization differences between BSP versions
  2. Power Management: Changes in USB power control between kernel versions
  3. Driver Updates: USB subsystem changes in the newer BSP

The fact that you observe this specifically with certain hardware combinations suggests it might be related to timing or initialization sequences that changed between the BSP versions.

Best regards, Toradex AI Assistant.


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

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

Hello @Romain.Donze !

Thank you for reaching out to Toradex support.

Did you have a chance to test the points mentioned under the “Hardware Configuration Details” section of the assistant’s reply, specifically:
Whether JP2 is set correctly (closed) so that the X8 bottom port is configured as HOST, and whether LED3 turns on when the board is powered, indicating that VCC_USBO1 (VBUS) is being enabled?
These two checks will help confirm if the port is physically being powered as expected.
Once you verify those, please let us know the results, as that will help determine whether the issue is on the power path or purely software/device-tree related.

Hi @joaom.tx,

Thanks for the reply.
Yes JP2 is closed and LED3 is turned on.

The process I followed to produce this bug was simply to install my kirkstone image with TEZI (yes I had to open JP2 to do so but I closed it afterward). As said with kirkstone I am able to detect USB devices on X8 bottom.

Then with TEZI I installed my scarthgap image (managing correctly JP2 as well) and then I can’t detect USB devices on X8 bottom.

If after that I reinstall my kirkstone image it works again so I think it is purely software related. I also tryed to disable my custom dto but it does not change.

As a reminder I only encounter this issue with apalis-imx8qp V1.1D (NON WB)

Regards,
Romain

This issue might be because of a device tree setup then. Could you please share the following so we can narrow down the cause?

  1. The Device Tree file that Scarthgap loads (from the boot log).
  2. The output of:
    lsusb -t
    and
    dmesg -w while hot-plugging a USB 2.0 stick into X8 bottom.

Hi @joaom.tx

First of all I noticed that the issue is only appearing with a USB3.0 stick, I just tested with USB2.0 stick and it works.

So here are the relevant outputs for both v1.0B and v1.1E under both kirkstone and scarthgap version

apalis-imx8qp_WB_v1.0B_kirkstone (2.6 KB)
apalis-imx8qp_v1.1E_kirkstone (2.3 KB)
apalis-imx8qp_WB_v1.0B_scarthgap (7.6 KB)
apalis-imx8qp_v1.1E_scarthgap (4.3 KB)

Notice that in scarthgap I am loading two dto for poweroff and reset (they are talked about here: GPIO Power-Off Overlay Not Working After Migration to Scarthgap (Apalis iMX8QP)) And it doesn’t change anything if I remove them.

Also for v1.0B I had to manually create device-tree in my yocto meta-layer because with scarthgap imx8qp-v1.0B does not fallback to imx8qm it tries to load imx8qp-apalis-eval.dtb by default, here is the content of recipes-kernel/linux in my meta-layer:
linux.zip (7.5 KB)

Based on those findings I think the problem comes from the fact that x8 bottom port is not falling back to high-speed usb when super-speed usb is plugged in but it simply ignores it. Wich in my opinion is a flaw. Especially because it only happens in this specific situation (imx8 v1.1E scarthgap)

Hi @joaom.tx,

Is there any news on this issue ?

Regards,
Romain

It’s possible that a device tree change between Kirkstone and Scarthgap is causing this issue.
Would you be able to try booting Scarthgap with the Kirkstone device tree for v1.1E to see if the problem with USB 3.0 sticks on the X8 bottom port still occurs? This test would help us confirm if the device tree is the root cause.

Hi @joaom.tx,

So I tested to boot with the kirkstone version of the device tree

Loading DeviceTree: imx8qp-apalis-v1.1-ixora-v1.2_kirkstone.dtb
171773 bytes read in 5 ms (32.8 MiB/s)
233 bytes read in 2 ms (113.3 KiB/s)
Working FDT set to 9d400000
Applying Overlay: apalis-imx8_hdmi_overlay.dtbo
2205 bytes read in 2 ms (1.1 MiB/s)
Applying Overlay: apalis-imx8_spi1_spidev_overlay.dtbo
551 bytes read in 2 ms (268.6 KiB/s)
Applying Overlay: apalis-imx8_spi2_spidev_overlay.dtbo
551 bytes read in 2 ms (268.6 KiB/s)
Applying Overlay: apalis-imx8_gpio-reset-moci_overlay.dtbo
1015 bytes read in 2 ms (495.1 KiB/s)
Applying Overlay: apalis-imx8_gpio-poweroff_overlay.dtbo
1017 bytes read in 2 ms (496.1 KiB/s)
Applying Overlay: apalis-imx8_rtc-rv8803_overlay.dtbo
991 bytes read in 2 ms (483.4 KiB/s)

And now X8 bottom is working fine, dmesg outputs this

[  167.594544] usb 1-1: new high-speed USB device number 2 using ci_hdrc
[  167.759993] usb 1-1: New USB device found, idVendor=0951, idProduct=1666, bcdDevice= 1.10
[  167.768258] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  167.775474] usb 1-1: Product: DataTraveler 3.0
[  167.779978] usb 1-1: Manufacturer: Kingston
[  167.784216] usb 1-1: SerialNumber: C87F54C69F5AE7C199780443
[  167.790986] usb-storage 1-1:1.0: USB Mass Storage device detected
[  167.797997] scsi host0: usb-storage 1-1:1.0
[  167.806736] fsl-asrc 59000000.asrc: failed to get asrck_2 clock
[  167.823930] usbcore: registered new interface driver uas
[  168.833043] scsi 0:0:0:0: Direct-Access     Kingston DataTraveler 3.0 PMAP PQ: 0 ANSI: 6
[  169.081318] sd 0:0:0:0: [sda] 121110528 512-byte logical blocks: (62.0 GB/57.8 GiB)
[  169.090018] sd 0:0:0:0: [sda] Write Protect is off
[  169.095640] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[  169.111385]  sda:
[  169.113562] sd 0:0:0:0: [sda] Attached SCSI removable disk
[  169.122962] fsl-asrc 59000000.asrc: failed to get asrck_2 clock
[  171.317154]  sda:

But now it is X8 top that does not work. So I think those issues are definitly device-tree related as said before.

Edit: I noticed something else with a usb 3.0 hub
On scarthgap device tree on X8 top I get this

[  284.968713] usb 4-1: new SuperSpeed USB device number 4 using xhci-hcd
[  285.001879] usb 4-1: New USB device found, idVendor=03f0, idProduct=0620, bcdDevice=69.61
[  285.015179] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  285.027275] usb 4-1: Product: USB3.1 Hub
[  285.036093] usb 4-1: Manufacturer: GenesysLogic
[  285.046861] hub 4-1:1.0: USB hub found
[  285.054189] hub 4-1:1.0: 4 ports detected
[  285.128603] usb 3-1: new high-speed USB device number 6 using xhci-hcd
[  285.287268] usb 3-1: New USB device found, idVendor=03f0, idProduct=0610, bcdDevice=69.61
[  285.299890] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  285.311285] usb 3-1: Product: USB2.1 Hub
[  285.319430] usb 3-1: Manufacturer: GenesysLogic
[  285.329782] hub 3-1:1.0: USB hub found
[  285.336076] hub 3-1:1.0: 4 ports detected

And on X8 bottom I get

[  366.343186] usb 1-1: new high-speed USB device number 6 using ci_hdrc
[  366.510487] usb 1-1: New USB device found, idVendor=03f0, idProduct=0610, bcdDevice=69.61
[  366.522775] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  366.533935] usb 1-1: Product: USB2.1 Hub
[  366.541978] usb 1-1: Manufacturer: GenesysLogic
[  366.551951] hub 1-1:1.0: USB hub found
[  366.560119] hub 1-1:1.0: 4 ports detected

So the hub is still detected but only in high-speed wich is expected. However then if I plug a superspeed device into the hub it is not detected but a high-speed device is working fine

With the kirkstone device tree. The hub is not even detected on X8 top but is working wine on X8 bottom with superspeed device being detected fine (as high-speed device of course)

PS: All those tests where run on the scarthgap version of my image with only the device-tree being changed

@joaom.tx

So what should I do now? Will toradex fix this issue, or at least provide a solution? Or should I try to fix this myself?