Verdin-imx8mp USB Type-C Not detect in U-Boot

Technical Support
, , ,
1

Hello All,

I am using Verdin-imx8mp SoM with custom carrier board and below software currently using:

Torizon OS : Reference Minimal Image (Yocto build)
Toradex BSP : Toradex BSP version 7.4.0
Linux Kernel : Linux Kernel version 6.6.94 LTS
Machine : verdin-imx8mp
Yocto Release : Yocto 5.0 (Scarthgap)
Distro (Distribution) : tdx-xwayland
Architecture : ARM64

To upgrade the SoM we tested by using SD card with tezi installer and our build package. Now I am trying to do same thing using USB Type-C Pen drive but it not detecting in U-Boot. check the below log of u-boot command:

U-Boot 2024.07-7.4.0-devel+git.3f772959501c (Jul 01 2024 - 18:07:18 +0000)

CPU:   Freescale i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz)
CPU:   Industrial temperature grade (-40C to 105C) at 51C
Reset cause: POR
DRAM:  4 GiB
Core:  177 devices, 31 uclasses, devicetree: separate
WDT:   Started watchdog@30280000 with servicing every 1000ms (60s timeout)
MMC:   FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... Reading from MMC(2)... OK
get_tdx_eeprom: cannot find EEPROM by node
MISSING TORADEX CARRIER CONFIG BLOCKS
get_tdx_eeprom: cannot find EEPROM by node
In:    serial@30880000
Out:   serial@30880000
Err:   serial@30880000
Model: Toradex 0063 Verdin iMX8M Plus Quad 4GB IT V1.1B
Serial#: 15677546
SEC0:  RNG instantiated
Setting variant to nonwifi
U-Boot FW Ver: 00.00.02
Boot Selection GPIOs: 0000 (config=0)
eMMC Default Primary Boot Selected.
Net:   pca953x gpio-expander@21: Error reading output register
Could not get PHY for mdio: addr 7
Could not get PHY for FEC1: addr 7
pca953x gpio-expander@21: Error reading output register
Could not get PHY for mdio: addr 7
Could not get PHY for FEC1: addr 7
eth0: ethernet@30bf0000 [PRIME]
Hit any key to stop autoboot:  0
Verdin iMX8MP # usb start
starting USB...
Bus usb@38200000: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@38200000 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Verdin iMX8MP # usb tree
USB device tree:
  1  Hub (5 Gb/s, 0mA)
     U-Boot XHCI Host Controller

Verdin iMX8MP # usb storage
No storage devices, perhaps not 'usb start'ed..?
Verdin iMX8MP #

We created our own custom carrier device tree and for USB here is below:

/* Verdin USB_1 Type-C Port used on 2460 MB */
&usb3_0 {
	status = "okay";
};

/* Verdin USB_1 Type-C Port used on 2460 MB */
&usb3_phy0 {
	status = "okay";
};

/* Verdin USB_1 Type-C Port used on 2460 MB */

&usb_dwc3_0 {
    status = "okay";
    dr_mode = "host";
    maximum-speed = "high-speed";
    vbus-supply = <&reg_usb1_vbus>;

    /delete-property/ usb-role-switch;
    /delete-property/ role-switch-default-mode;
    /delete-node/ connector;
};

Could you please check the above information and provide the suggestions how to resolve this issue?

Thanks in advance..!!

Thanks,

Vishal

2

Hi, I’m the Toradex AI Assistant.

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

Based on your U-Boot log, the USB controller is starting successfully but not detecting your USB Type-C pen drive. Let me help you troubleshoot this issue.

Analysis of Your Setup

Your U-Boot log shows:

Bus usb@38200000: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@38200000 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found

This indicates the USB controller is initializing, but no storage devices are being detected.

Potential Issues with Your Device Tree Configuration

I notice several potential issues with your custom carrier board device tree configuration:

  1. Missing Pin Control Configuration: Your device tree snippet doesn’t include pinctrl definitions for USB, which are typically required for proper USB operation.

  2. VBUS Regulator Reference: You’re referencing &reg_usb1_vbus - please verify this regulator is properly defined in your device tree and is actually providing power to the USB port.

  3. Deleted Properties: You’ve removed usb-role-switch, role-switch-default-mode, and the connector node. While this may be intentional for your use case, ensure these deletions align with your hardware design.

Troubleshooting Steps

1. Verify Hardware Connections

  • Confirm the USB Type-C port on your custom carrier board is properly wired
  • Check that VBUS power is reaching the USB connector
  • Verify the USB data lines are correctly routed

2. Check VBUS Regulator

Ensure your reg_usb1_vbus regulator is:

  • Properly defined in your device tree
  • Enabled and providing the correct voltage
  • Not conflicting with other regulators

3. Compare with Reference Design

I recommend comparing your device tree configuration with the Toradex reference carrier boards. You can find these in the kernel source under arch/arm64/boot/dts/freescale/.

4. Test in Linux

After U-Boot, does the USB port work correctly in Linux? This can help determine if the issue is U-Boot-specific or a hardware/device tree problem.

5. Enable U-Boot USB Debug

Try enabling USB debug output in U-Boot to get more detailed information:

setenv usbverbose 1
usb reset

6. Try Different USB Devices

Test with different USB storage devices to rule out device-specific compatibility issues.

Additional Questions

To provide more targeted assistance, could you clarify:

  1. Does the USB port work correctly once Linux boots?
  2. Have you verified the VBUS regulator is providing power?
  3. Are you using a USB Type-C to USB-A adapter, or is your pen drive natively USB Type-C?
  4. What specific changes did you make from the Toradex reference carrier board device tree?

The U-Boot environment variables and boot process are documented in the U-Boot article(1), which may help with further debugging.

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.

3
  1. @ToradexAI Here is below answers:
    Does the USB port work correctly once Linux boots? Yes I detected and read/write works.
  2. Have you verified the VBUS regulator is providing power?
    Yes I checked the VBUS_DET pin of TUSB320L and getting 5V in linux as well as in U-boot also.
  3. Are you using a USB Type-C to USB-A adapter, or is your pen drive natively USB Type-C? Pen drive and natively Type-C port.
  4. What specific changes did you make from the Toradex reference carrier board device tree?

Refer the below latest device tree changes:

/* Verdin USB_1 Type-C Port used on MB */
&usb3_0 {
	status = "okay";
};

/* Verdin USB_1 Type-C Port used on MB */
&usb3_phy0 {
	status = "okay";

	/* This below regulator is included here beacuse from usb_dwc3_0 node
	   we deleted  /delete-node/ connector; that's why here required to get 5V bus */
	vbus-supply = <&reg_usb1_vbus>;
};

&reg_usb1_vbus {
    regulator-boot-on;
    regulator-always-on;
};

/* Verdin USB_1 Type-C Port used on MB */

&usb_dwc3_0 {
    status = "okay";
	/* Will use only host mode Type-C Port Pendrive */
    dr_mode = "host";
    maximum-speed = "high-speed";

    snps,dis_u2_susphy_quirk;
    snps,dis_enblslpm_quirk;

    /delete-property/ usb-role-switch;
    /delete-property/ role-switch-default-mode;
    /delete-node/ connector;
};

I am trying to debug in u-boot but USB_1_EN output pin which is connected to SoM SODIMM 155
I trying to write this pin to 1 but always getting 0 value, why?
Log as below

USB1_EN regulator not found (ret=-19), fallback to GPIO
USB1_EN manual GPIO level: 0
Boot Selection GPIOs: 0000 (config=0)
eMMC Default Primary Boot Selected.
Net:   pca953x gpio-expander@21: Error reading output register
Could not get PHY for mdio: addr 7
Could not get PHY for FEC1: addr 7
pca953x gpio-expander@21: Error reading output register
Could not get PHY for mdio: addr 7
Could not get PHY for FEC1: addr 7
eth0: ethernet@30bf0000 [PRIME]
Hit any key to stop autoboot:  0
Verdin iMX8MP # usb start
starting USB...
Bus usb@38200000: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@38200000 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Verdin iMX8MP #

Is there any changes required in device tree? Or any default u-boot device tree need to update?
Please suggest proper way to resolve this issue, We need to resolve this issue ASAP.

I have also attached the power up log with attached type-c pendrive and disconnected. But in u-boot not getting detect as storage device.

Thanks,

USB_Boot_Power_Up_Log.txt (39.0 KB)

4

Based on your additional information, the key issue is clear: the USB1_EN GPIO (SODIMM 155) is not being set high in U-Boot, which is preventing VBUS power from being supplied to the USB port.

Root Cause Analysis

Your log shows:

USB1_EN regulator not found (ret=-19), fallback to GPIO
USB1_EN manual GPIO level: 0

This indicates:

  1. U-Boot cannot find the reg_usb1_vbus regulator definition (error -19 = -ENODEV)
  2. It’s falling back to GPIO control
  3. The GPIO remains at level 0 (disabled) instead of 1 (enabled)

The Problem: U-Boot vs Linux Device Trees

Critical point: U-Boot and Linux use separate device tree files. Your Linux device tree modifications are working (which is why USB works in Linux), but U-Boot is using its own device tree that doesn’t include your changes.

Solution: Modify U-Boot Device Tree

You need to modify the U-Boot device tree, not just the Linux one. Here’s how:

1. Locate U-Boot Device Tree Source

For Verdin iMX8MP, the U-Boot device trees are in the U-Boot source code under:

  • arch/arm/dts/imx8mp-verdin*.dts* files

2. Apply Your Changes to U-Boot DTS

You need to add your USB configuration to the appropriate U-Boot device tree file. Based on your setup, you’ll need to modify the U-Boot device tree to include:

&reg_usb1_vbus {
    regulator-boot-on;
    regulator-always-on;
    status = "okay";
};

&usb3_0 {
    status = "okay";
};

&usb3_phy0 {
    status = "okay";
    vbus-supply = <&reg_usb1_vbus>;
};

&usb_dwc3_0 {
    status = "okay";
    dr_mode = "host";
    maximum-speed = "high-speed";
    
    /delete-property/ usb-role-switch;
    /delete-property/ role-switch-default-mode;
    /delete-node/ connector;
};

3. Ensure GPIO/Pinmux Configuration

Make sure the pinmux configuration for USB1_EN (SODIMM 155) is properly defined in your U-Boot device tree. The GPIO needs to be configured as an output and set high.

4. Rebuild U-Boot

After modifying the U-Boot device tree, you need to rebuild U-Boot. Follow the instructions for building U-Boot from source(1).

The key steps involve:

  1. Setting up your build environment with the correct toolchain(1)
  2. Configuring U-Boot for your platform
  3. Compiling U-Boot with your modified device tree
  4. Deploying the new U-Boot to your module

5. Alternative: Check U-Boot Configuration

Verify that your U-Boot configuration includes:

  • USB host support enabled
  • USB storage support enabled
  • The correct USB controller driver for iMX8MP

Additional Debugging

To further debug the GPIO issue in U-Boot, you can try:

  1. Check GPIO state manually in U-Boot console:
gpio status
gpio set <gpio_number>

  1. Verify regulator configuration:
    Check if reg_usb1_vbus is properly defined with all required properties in your U-Boot device tree.

  2. Enable U-Boot USB debugging:

setenv usbverbose 1
usb reset

Important Notes

  • Device tree changes for Linux (in /boot or compiled into the kernel) do not affect U-Boot behavior
  • U-Boot reads its device tree from the boot partition or has it compiled in
  • Both U-Boot and Linux device trees need to be updated separately for consistent behavior across boot stages

Since USB works correctly in Linux, your hardware is functioning properly. The issue is purely a U-Boot device tree configuration problem.

Could you confirm:

  1. Are you building U-Boot from source or using the pre-built version?
  2. Have you made any modifications to the U-Boot device tree files specifically?

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.

5

Hello @sahil.tx @ToradexAI
I am facing an issue with USB Type-C detection in U-Boot. The problem is described below.

When I connect the USB Type-C drive in Orientation A, it is detected successfully and works as expected. However, when I flip the same USB drive and connect it in Orientation B, the behavior is inconsistent. Sometimes the USB device is detected, while other times it is not.

Please find the U-Boot log below for your reference:

Verdin iMX8MP # usb start
starting USB…
Bus usb@38100000: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@38100000 for devices… 2 USB Device(s) found
scanning usb for storage devices… 1 Storage Device(s) found
Verdin iMX8MP # usb stop
stopping USB..
Verdin iMX8MP # usb start
starting USB…
Bus usb@38100000: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@38100000 for devices… XHCI timeout on event type 33…

  USB device not accepting new address (error=80000000)

1 USB Device(s) found
scanning usb for storage devices… 0 Storage Device(s) found
Verdin iMX8MP # usb reset
resetting USB…
Bus usb@38100000: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@38100000 for devices… 2 USB Device(s) found
scanning usb for storage devices… 1 Storage Device(s) found
Verdin iMX8MP # usb reset
resetting USB…
Bus usb@38100000: Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@38100000 for devices… XHCI timeout on event type 33…

  USB device not accepting new address (error=80000000)

1 USB Device(s) found
scanning usb for storage devices… 0 Storage Device(s) found
Verdin iMX8MP #

Here is my updated and latest device Tree for U-Boot to detect USB-C Type in U-Boot:

/* Force USB_1 controller into standard Host Mode for U-Boot */
&usb_dwc3_0 {
    status = "okay";
    dr_mode = "host";
    maximum-speed = "high-speed";
    vbus-supply = <&reg_usb1_vbus>;

    /delete-property/ usb-role-switch;
    /delete-property/ role-switch-default-mode;
    /delete-node/ connector;

};

/* Ensure the VBUS regulator and its underlying GPIO load cleanly during boot */
&reg_usb1_vbus {
    bootph-pre-ram;  /* Matches the updated U-Boot memory allocation property */
    regulator-boot-on;
    regulator-always-on;

    /* Adds a 200ms stabilization delay after power-up before scanning */
    startup-delay-us = <250000>;
    status = "okay";
};

&usb3_phy0 {
    status = "okay";
};

&usb3_0 {
    status = "okay";
};


/* Unused USB_2 */
&usb_dwc3_1 {
    status = "disabled";
};

&usb3_phy1 {
    status = "disabled";
};

&usb3_1 {
    status = "disabled";
};

I am getting this problem only in U-boot and in Linux it working both side A/B. I want to same work in U-boot because we are trying to Boot from USB to upgrade the Tezi image.

@rudhi.tx I also checked your reply on this thread USB device not accepting new address (error=80000000) in uboot - #8 by vix

Is this open issue in BSP 7.4.0? Can you please confirm?

Could you please review the above log and U-Boot device tree and provide your suggestion and guidance how to resolve this issue?

Thanks,

Vishal Borle

6

Based on your detailed description and logs, you’re experiencing an orientation-dependent USB Type-C detection issue in U-Boot that appears to be related to the USB XHCI controller’s handling of device enumeration when the connector is flipped.

Analysis of the Issue

Your logs show a clear pattern:

  • Orientation A: Works consistently
  • Orientation B: Intermittent failures with XHCI timeout on event type 33 and USB device not accepting new address (error=80000000)

This behavior suggests that while the USB Type-C connector’s physical orientation switching is working (since Linux handles both orientations correctly), U-Boot’s USB stack may have timing or initialization issues when handling the alternate orientation.

Known Issue Confirmation

Based on the community thread you referenced(1), similar USB enumeration issues have been reported with U-Boot on Toradex modules. The thread discusses USB devices not being accepted with the same error code (error=80000000) you’re experiencing(1).

However, I don’t have definitive confirmation that this is a documented open issue specifically in BSP 7.4.0 for orientation-dependent failures. The referenced thread suggests this may be related to USB device compatibility or timing issues in the U-Boot USB stack(1).

Device Tree Review

Your U-Boot device tree configuration looks generally correct:

&usb_dwc3_0 {
    status = "okay";
    dr_mode = "host";
    maximum-speed = "high-speed";
    vbus-supply = <&reg_usb1_vbus>;
    /delete-property/ usb-role-switch;
    /delete-property/ role-switch-default-mode;
    /delete-node/ connector;
};

&reg_usb1_vbus {
    bootph-pre-ram;
    regulator-boot-on;
    regulator-always-on;
    startup-delay-us = <250000>;
    status = "okay";
};

The startup-delay-us = <250000> (250ms) is a good addition for stabilization.

Recommended Troubleshooting Steps

1. Increase Startup Delay

Try increasing the startup delay further to allow more time for the USB subsystem to stabilize after orientation detection:

&reg_usb1_vbus {
    bootph-pre-ram;
    regulator-boot-on;
    regulator-always-on;
    startup-delay-us = <500000>;  /* Increase to 500ms */
    status = "okay";
};

2. Add USB Controller Quirks

Add additional quirks to the USB DWC3 controller that may help with enumeration timing:

&usb_dwc3_0 {
    status = "okay";
    dr_mode = "host";
    maximum-speed = "high-speed";
    vbus-supply = <&reg_usb1_vbus>;
    
    snps,dis_u2_susphy_quirk;
    snps,dis_enblslpm_quirk;
    snps,dis-u2-freeclk-exists-quirk;
    
    /delete-property/ usb-role-switch;
    /delete-property/ role-switch-default-mode;
    /delete-node/ connector;
};

3. Test with Multiple USB Devices

As suggested in the community thread(1), test with different USB Type-C storage devices from various manufacturers to determine if this is device-specific or a broader controller issue.

4. Enable U-Boot USB Debugging

Enable verbose USB debugging in U-Boot to get more detailed information about the enumeration process:

setenv usbverbose 1
usb reset

5. Check USB PHY Configuration

Ensure the USB3 PHY is properly configured in your U-Boot device tree:

&usb3_phy0 {
    status = "okay";
    vbus-supply = <&reg_usb1_vbus>;
};

6. Workaround: Multiple Reset Attempts

As a temporary workaround until a permanent fix is available, you could implement a script in U-Boot that attempts multiple USB resets:

setenv usb_retry 'usb reset || usb reset || usb reset'

Hardware Considerations

Since the issue is orientation-dependent, verify:

  1. USB Type-C orientation detection circuitry on your carrier board is functioning correctly
  2. Signal integrity for both CC lines (CC1 and CC2) that handle orientation detection
  3. Power delivery is stable in both orientations

Next Steps

  1. Apply the suggested device tree modifications (increased delays and quirks)
  2. Rebuild and deploy U-Boot with the updated device tree
  3. Test with multiple USB devices in both orientations
  4. Collect verbose USB logs for further analysis
  5. If the issue persists, consider reaching out to Toradex support with:
    • Complete U-Boot logs with usbverbose=1
    • Your custom carrier board schematic (USB section)
    • List of tested USB devices and their behavior

Regarding BSP 7.4.0 Status

I cannot definitively confirm if this is a known open issue in BSP 7.4.0 based on the available documentation. However, the community thread you referenced(1) suggests that USB enumeration issues in U-Boot have been reported by other users. I recommend checking the official Toradex release notes and known issues for BSP 7.4.0, or contacting Toradex support directly for confirmation.

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.