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.

7

Hi @sahil.tx @ToradexAI

When I added below in U-boot device then it start detecting USB in U-boot with side B orientation.

snps,dis_u2_susphy_quirk;
snps,dis_enblslpm_quirk;
snps,dis-u2-freeclk-exists-quirk;

But still when I trying to upgrade SoM image using USB option then Side B not working getting stuck below. If I used same USB with Side A orientation then it works and successfully upgraded the SoM firmware.

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 30C
Reset cause: POR
DRAM:  4 GiB
Core:  174 devices, 30 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
2460 U-Boot FW Ver: 00.00.03
read_mac_from_gp: word7=0x98002000 word8=0x00000000
OTP-derived MAC = 00:20:00:98:00:00 -> assigning to eth1addr
Saving Environment to MMC... Writing to MMC(2)... OK
2460 Boot Selection GPIOs: 1001 (config=9)
eMMC USB Mass Storage 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
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
42213651 bytes read in 297 ms (135.5 MiB/s)
## Loading kernel from FIT Image at 44200000 ...
   Using 'conf-freescale_imx8mp-verdin-nonwifi-dev.dtb' configuration
   Trying 'kernel-1' kernel subimage
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  gzip compressed
     Data Start:   0x442000f4
     Data Size:    7740927 Bytes = 7.4 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x48200000
     Entry Point:  0x48200000
     Hash algo:    sha256
     Hash value:   e7c4412f40fcc05b94b3035414c1106e201ee794838fcc38925709b70d38e228
   Verifying Hash Integrity ... sha256+ OK
## Loading ramdisk from FIT Image at 44200000 ...
   Using 'conf-freescale_imx8mp-verdin-nonwifi-dev.dtb' configuration
   Trying 'ramdisk-1' ramdisk subimage
     Description:  tezi-initramfs
     Type:         RAMDisk Image
     Compression:  uncompressed
     Data Start:   0x44a49310
     Data Size:    33517568 Bytes = 32 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x52300000
     Entry Point:  unavailable
     Hash algo:    sha256
     Hash value:   9111bf9a3b20a1a53dbb564af8bbfc8a72696db70bab9e0a9740d72b6c896ba2
   Verifying Hash Integrity ... sha256+ OK
   Loading ramdisk from 0x44a49310 to 0x52300000
## Loading fdt from FIT Image at 44200000 ...
   Using 'conf-freescale_imx8mp-verdin-nonwifi-dev.dtb' configuration
   Trying 'fdt-freescale_imx8mp-verdin-nonwifi-dev.dtb' fdt subimage
     Description:  Flattened Device Tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x4497789c
     Data Size:    87352 Bytes = 85.3 KiB
     Architecture: AArch64
     Load Address: 0x50200000
     Hash algo:    sha256
     Hash value:   792db6a3d582a3cc0cd78dacebe963ca08ba68a78418b24249de5c1081231beb
   Verifying Hash Integrity ... sha256+ OK
   Loading fdt from 0x4497789c to 0x50200000
   Booting using the fdt blob at 0x50200000
Working FDT set to 50200000
   Uncompressing Kernel Image to 48200000
   Loading Device Tree to 00000000feaa1000, end 00000000feab9537 ... OK
Working FDT set to feaa1000

Starting kernel ...

[    0.179874] imx-drm display-subsystem: no available port
[    0.207140] nvmem imx-ocotp0: cell mac-address raw len 6 unaligned to nvmem word size 4
[    0.215181] nvmem imx-ocotp0: cell mac-address raw len 6 unaligned to nvmem word size 4
[    0.270417] rtc-ds1307 0-0032: hctosys: unable to read the hardware clock
Running /etc/rc.local...
Toradex Easy Installer 7.3.0+build.7 ()
Starting udev
[    1.349257] pca953x 3-0021: failed writing register
[    1.355059] ina2xx 3-0040: error configuring the device: -6
[    1.393900] imx-bus-devfreq 32700000.interconnect: failed to fetch clk: -2
System time was Thu Jan  1 00:00:03 UTC 1970.
Setting the System Clock using the Hardware Clock as reference...
hwclock: RTC_RD_TIME: Invalid argument
System Clock set. System local time is now Thu Jan  1 00:00:03 UTC 1970.
Fri Mar  9 12:34:56 UTC 2018
Saving the System Clock time to the Hardware Clock...
Hardware Clock updated to Fri Mar  9 12:34:56 UTC 2018.

Welcome to the Toradex Easy Installer

This is a Linux based installer for Toradex modules. Currently, the installer
does not have a serial console interface. You can use the Toradex Easy Installer
via any of the available display interfaces using USB mouse/keyboard or via a
network connection using VNC. Use:
  # ip addr show
to display the Ethernet IP address(es) or use USB NCM at IP 192.168.11.1.

Check our documentation at:
  https://developer.toradex.com/software/toradex-easy-installer
~ #

Could you suggest and guide me why in Tezi getting stuck only if used side B orientation?

Thanks.

8

Based on your logs, you’ve successfully resolved the U-Boot USB detection issue with the quirks, but now you’re experiencing a different problem: Toradex Easy Installer (TEZI) is getting stuck after booting when using USB orientation B.

Analysis of the Current Issue

Your log shows that:

  1. U-Boot successfully detects the USB drive in orientation B (2 USB devices found, 1 storage device found)
  2. The kernel loads successfully from the USB drive
  3. TEZI boots and starts but then appears to hang at the shell prompt

The key difference from orientation A is that TEZI is not launching its GUI/main application - it just drops to a shell prompt and stops.

Root Cause

This suggests that after the kernel boots, TEZI is losing access to the USB storage device. This is a Linux kernel USB driver issue, not a U-Boot issue. The USB drive needs to remain accessible in Linux for TEZI to read the installation images.

Troubleshooting Steps

1. Check USB Device Status in TEZI Shell

When you reach the TEZI shell prompt with orientation B, run these commands to diagnose:

# Check if USB storage is still detected
lsusb

# Check block devices
lsblk

# Check USB mass storage
ls -la /dev/sd*

# Check kernel messages for USB errors
dmesg | grep -i usb

# Check if the USB mount point exists
mount | grep usb

This will help determine if the USB device is still visible to Linux or if it has disconnected.

2. Add Linux Kernel USB Quirks to Device Tree

Since the issue occurs in Linux (not U-Boot), you need to add the same quirks to your Linux device tree (not just U-Boot):

/* Linux device tree - NOT U-Boot */
&usb_dwc3_0 {
    status = "okay";
    dr_mode = "host";
    maximum-speed = "high-speed";
    
    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. Increase USB Power-On Delay in Linux

Add a longer stabilization delay in your Linux device tree:

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

4. Check TEZI Kernel Messages

The error messages in your log are concerning:

[    1.349257] pca953x 3-0021: failed writing register
[    1.355059] ina2xx 3-0040: error configuring the device: -6

These suggest I2C communication issues that might be related to power management or initialization timing. The -6 error typically means -ENXIO (No such device or address).

5. Modify TEZI Image Device Tree

The TEZI image contains its own device tree (shown in your log as fdt-freescale_imx8mp-verdin-nonwifi-dev.dtb). You need to ensure your USB quirks are present in this device tree as well.

To do this:

  1. Extract the TEZI image
  2. Modify the device tree blob to include your USB configuration
  3. Repackage the TEZI image

Alternatively, you can rebuild TEZI with your custom device tree included(1).

6. Test USB Stability in Linux

Boot into your regular Linux system (not TEZI) and test USB orientation B stability:

# Plug in USB drive in orientation B
# Check if it stays connected
watch -n 1 'lsblk; echo "---"; dmesg | tail -5'

# Try some I/O operations
dd if=/dev/sda of=/dev/null bs=1M count=100

# Check for disconnections
dmesg | grep -i "usb disconnect"

7. Verify USB Type-C Orientation Detection

Check if the USB Type-C orientation detection is working correctly in Linux:

# Check USB Type-C port status
cat /sys/class/typec/port0/data_role
cat /sys/class/typec/port0/power_role

# Monitor orientation changes
watch -n 0.5 'cat /sys/class/typec/port0/*'

Recommended Solution Path

  1. First: Verify the USB device remains accessible in the TEZI shell (step 1 above)
  2. Second: Apply the USB quirks to your Linux device tree (not just U-Boot)
  3. Third: Rebuild your TEZI image with the modified device tree
  4. Fourth: Test with the updated TEZI image

Additional Considerations

Hardware Signal Integrity

Since orientation B works in U-Boot but fails in Linux, this suggests:

  • The USB controller initialization differs between U-Boot and Linux
  • Linux may be more sensitive to signal integrity issues on the alternate CC line
  • Power delivery timing may be different between U-Boot and Linux

Workaround

As a temporary workaround until you resolve the root cause:

  • Always use orientation A for TEZI installations
  • Add clear labeling or documentation for your production process

Questions for Further Diagnosis

To help narrow down the issue:

  1. Does the USB drive remain visible when you run lsblk at the TEZI shell prompt with orientation B?
  2. Are there any USB disconnect messages in dmesg when using orientation B?
  3. Does orientation B work correctly in your regular Linux system (outside of TEZI)?
  4. Have you verified that your Linux device tree (not just U-Boot) includes the USB quirks?

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.

9

@ToradexAI

We added USB quirks in linux device tree and upgrade the SoM firmware using side A it work but same when i changed USB to side B then still same problem.
Here is my linux device tree can you check below:

/* 1. Ensure your physical VBUS Regulator is enabled */
&reg_usb1_vbus {
    status = "okay";
    regulator-min-microvolt = <5000000>;
    regulator-max-microvolt = <5000000>;
    /* Controls the 5V power distribution switch to the Type-C port */
    /* Verdin USB_1_EN (SODIMM 155) */
	gpio = <&gpio1 12 GPIO_ACTIVE_HIGH>;
    enable-active-high;
	startup-delay-us = <500000>;  /* 500ms delay */
};

/* 2. Configure the USB3 controller to look for SuperSpeed lanes */
&usb3_0 {
    status = "okay";
    fsl,disable-port-power-control;
    fsl,over-current-active-low;
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_usb_1_oc_n>;
};

/* 3. Configure the physical High-Speed / SuperSpeed PHY pipeline */
&usb3_phy0 {
    status = "okay";
    vbus-supply = <&reg_usb1_vbus>;
};

/* 4. Force the Core DWC3 controller into permanent Linux Host Mode */
&usb_dwc3_0 {
    status = "okay";
    dr_mode = "host";             /* Explicitly forces Linux into Host-Only mode */
    maximum-speed = "high-speed"; /* Activates USB 3.0 5Gbps data pathways */
    vbus-supply = <&reg_usb1_vbus>;

	snps,dis_u2_susphy_quirk;
    snps,dis_enblslpm_quirk;
    snps,dis-u2-freeclk-exists-quirk;

    /* Clean up the dynamic software OTG components from the base tree */
    /delete-property/ usb-role-switch;
    /delete-property/ role-switch-default-mode;
    /delete-node/ connector;

    /* * Define a fixed Type-C connector layout. This tells the Linux kernel 
     * that even though role-switching is disabled, the physical port is a 
     * Type-C socket, allowing the kernel to process both USB 2.0 and USB 3.0 lines.
     */
    connector {
        compatible = "usb-c-connector";
        label = "Type-C Fixed Host";
        type = "c";
    };
};



/* Verdin USB_2 this second USB port not using on 2460 MB */
&usb3_1 {
	status = "disabled";
};

/* Verdin USB_2 this second USB port not using on 2460 MB */
&usb3_phy1 {
	status = "disabled";
};

/* Verdin USB_2 this second USB port not using on 2460 MB */
&usb_dwc3_1 {
	status = "disabled";
};

Here is my below log:
I checked with lsusb with side B and when used side A then it detected as HP USB stick.

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 38C
Reset cause: POR
DRAM:  4 GiB
Core:  174 devices, 30 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#: 08817574
SEC0:  RNG instantiated
Setting variant to nonwifi
2460 U-Boot FW Ver: 00.00.03
read_mac_from_gp: word7=0x98002000 word8=0x00000000
OTP-derived MAC = 00:20:00:98:00:00 -> assigning to eth1addr
Saving Environment to MMC... Writing to MMC(2)... OK
2460 Boot Selection GPIOs: 1001 (config=9)
eMMC USB Mass Storage 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
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
42213651 bytes read in 297 ms (135.5 MiB/s)
## Loading kernel from FIT Image at 44200000 ...
   Using 'conf-freescale_imx8mp-verdin-nonwifi-dev.dtb' configuration
   Trying 'kernel-1' kernel subimage
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  gzip compressed
     Data Start:   0x442000f4
     Data Size:    7740927 Bytes = 7.4 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x48200000
     Entry Point:  0x48200000
     Hash algo:    sha256
     Hash value:   e7c4412f40fcc05b94b3035414c1106e201ee794838fcc38925709b70d38e228
   Verifying Hash Integrity ... sha256+ OK
## Loading ramdisk from FIT Image at 44200000 ...
   Using 'conf-freescale_imx8mp-verdin-nonwifi-dev.dtb' configuration
   Trying 'ramdisk-1' ramdisk subimage
     Description:  tezi-initramfs
     Type:         RAMDisk Image
     Compression:  uncompressed
     Data Start:   0x44a49310
     Data Size:    33517568 Bytes = 32 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x52300000
     Entry Point:  unavailable
     Hash algo:    sha256
     Hash value:   9111bf9a3b20a1a53dbb564af8bbfc8a72696db70bab9e0a9740d72b6c896ba2
   Verifying Hash Integrity ... sha256+ OK
   Loading ramdisk from 0x44a49310 to 0x52300000
## Loading fdt from FIT Image at 44200000 ...
   Using 'conf-freescale_imx8mp-verdin-nonwifi-dev.dtb' configuration
   Trying 'fdt-freescale_imx8mp-verdin-nonwifi-dev.dtb' fdt subimage
     Description:  Flattened Device Tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x4497789c
     Data Size:    87352 Bytes = 85.3 KiB
     Architecture: AArch64
     Load Address: 0x50200000
     Hash algo:    sha256
     Hash value:   792db6a3d582a3cc0cd78dacebe963ca08ba68a78418b24249de5c1081231beb
   Verifying Hash Integrity ... sha256+ OK
   Loading fdt from 0x4497789c to 0x50200000
   Booting using the fdt blob at 0x50200000
Working FDT set to 50200000
   Uncompressing Kernel Image to 48200000
   Loading Device Tree to 00000000feaa1000, end 00000000feab9537 ... OK
Working FDT set to feaa1000

Starting kernel ...

[    0.180188] imx-drm display-subsystem: no available port
[    0.207745] nvmem imx-ocotp0: cell mac-address raw len 6 unaligned to nvmem word size 4
[    0.215789] nvmem imx-ocotp0: cell mac-address raw len 6 unaligned to nvmem word size 4
Running /etc/rc.local...
Toradex Easy Installer 7.3.0+build.7 ()
Starting udev
[    1.365918] pca953x 3-0021: failed writing register
[    1.387735] ina2xx 3-0040: error configuring the device: -6
[    1.388677] imx-bus-devfreq 32700000.interconnect: failed to fetch clk: -2
System time was Fri Mar  9 12:35:51 UTC 2018.
Setting the System Clock using the Hardware Clock as reference...
System Clock set. System local time is now Fri Mar  9 12:35:51 UTC 2018.

Welcome to the Toradex Easy Installer

This is a Linux based installer for Toradex modules. Currently, the installer
does not have a serial console interface. You can use the Toradex Easy Installer
via any of the available display interfaces using USB mouse/keyboard or via a
network connection using VNC. Use:
  # ip addr show
to display the Ethernet IP address(es) or use USB NCM at IP 192.168.11.1.

Check our documentation at:
  https://developer.toradex.com/software/toradex-easy-installer
~ # lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux 6.6.94-7.3.0 xhci-hcd xHCI Host Controller
Bus 002 Device 001: ID 1d6b:0003 Linux 6.6.94-7.3.0 xhci-hcd xHCI Host Controller
Bus 003 Device 001: ID 1d6b:0002 Linux 6.6.94-7.3.0 xhci-hcd xHCI Host Controller
Bus 004 Device 001: ID 1d6b:0003 Linux 6.6.94-7.3.0 xhci-hcd xHCI Host Controller
~ # lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux 6.6.94-7.3.0 xhci-hcd xHCI Host Controller
Bus 002 Device 001: ID 1d6b:0003 Linux 6.6.94-7.3.0 xhci-hcd xHCI Host Controller
Bus 003 Device 001: ID 1d6b:0002 Linux 6.6.94-7.3.0 xhci-hcd xHCI Host Controller
Bus 004 Device 001: ID 1d6b:0003 Linux 6.6.94-7.3.0 xhci-hcd xHCI Host Controller
~ #
~ #
~ #
~ #
~ #
~ #
~ #
~ # lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux 6.6.94-7.3.0 xhci-hcd xHCI Host Controller
Bus 002 Device 001: ID 1d6b:0003 Linux 6.6.94-7.3.0 xhci-hcd xHCI Host Controller
Bus 003 Device 001: ID 1d6b:0002 Linux 6.6.94-7.3.0 xhci-hcd xHCI Host Controller
Bus 003 Device 002: ID 03f0:2003 HP USB Flash Drive
Bus 004 Device 001: ID 1d6b:0003 Linux 6.6.94-7.3.0 xhci-hcd xHCI Host Controller
~ #
~ # lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux 6.6.94-7.3.0 xhci-hcd xHCI Host Controller
Bus 002 Device 001: ID 1d6b:0003 Linux 6.6.94-7.3.0 xhci-hcd xHCI Host Controller
Bus 003 Device 001: ID 1d6b:0002 Linux 6.6.94-7.3.0 xhci-hcd xHCI Host Controller
Bus 003 Device 002: ID 03f0:2003 HP USB Flash Drive
Bus 004 Device 001: ID 1d6b:0003 Linux 6.6.94-7.3.0 xhci-hcd xHCI Host Controller
~ # [   84.175517] imx2-wdt 30280000.watchdog: Device shutdown.
[   84.182025] reboot: Power down
10

Based on your log, I can see the critical issue: The USB device appears after TEZI boots, but it’s too late for TEZI to detect it as the installation source.

Key Observation from Your Log

~ # lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux 6.6.94-7.3.0 xhci-hcd xHCI Host Controller
...
~ # lsusb
...
~ # lsusb
Bus 003 Device 002: ID 03f0:2003 HP USB Flash Drive  ← Device appears AFTER boot

The USB drive (HP USB Flash Drive) only appears on Bus 003 after several seconds, which is after TEZI has already initialized and looked for installation media. This explains why TEZI drops to a shell - it didn’t find any installation source during its initial scan.

Root Cause

With orientation B, there’s a delayed enumeration in the Linux kernel. The device takes significantly longer to enumerate compared to orientation A, causing TEZI to miss it during startup.

Solution: Modify TEZI Device Tree

Since your Linux device tree modifications work (the device eventually appears), the issue is that TEZI uses its own embedded device tree (fdt-freescale_imx8mp-verdin-nonwifi-dev.dtb shown in your boot log).

You need to modify the TEZI image’s embedded device tree to include your USB quirks and delays.

Steps to Fix TEZI

1. Extract TEZI Image

# Mount your USB drive
mkdir -p /tmp/usb
mount /dev/sda1 /tmp/usb

# Navigate to where the kernel FIT image is stored
cd /tmp/usb

2. Extract and Modify the Device Tree

You need to extract the FIT image, modify the embedded device tree, and repackage it. However, this is complex. A better approach is to rebuild TEZI from source with your custom device tree(1).

3. Alternative: Use Device Tree Overlay in TEZI

TEZI supports device tree overlays. Create a device tree overlay file with your USB configuration:

usb-orientation-fix.dtso:

/dts-v1/;
/plugin/;

/ {
    compatible = "toradex,verdin-imx8mp";
};

&reg_usb1_vbus {
    startup-delay-us = <500000>;
};

&usb_dwc3_0 {
    snps,dis_u2_susphy_quirk;
    snps,dis_enblslpm_quirk;
    snps,dis-u2-freeclk-exists-quirk;
};

Compile it:

dtc -@ -I dts -O dtb -o usb-orientation-fix.dtbo usb-orientation-fix.dtso

Place it on your TEZI USB drive and configure TEZI to load it.

4. Increase TEZI USB Scan Timeout

TEZI may have a timeout for detecting USB storage. You might need to rebuild TEZI with a longer detection timeout.

Immediate Workaround

Option 1: Add Kernel Boot Parameter

Modify the TEZI boot command to add a delay before TEZI starts:

In U-Boot, before booting TEZI:

setenv bootargs_append "rootdelay=10"

This tells the kernel to wait 10 seconds before mounting the root filesystem, giving USB more time to enumerate.

Option 2: Manual TEZI Launch

Since the USB device does appear eventually (as shown in your lsusb output), you can manually trigger TEZI after the device appears:

# Wait at the shell prompt until lsusb shows the HP USB Flash Drive
lsusb

# Once it appears, manually mount and run TEZI
mount /dev/sda1 /mnt
/mnt/tezi.sh  # Or whatever the TEZI startup script is called

Hardware Investigation

The orientation-dependent delay suggests a potential issue with:

  1. USB Type-C CC pin detection circuit - The CC1/CC2 detection may be slower in one orientation
  2. VBUS power sequencing - Power delivery timing differs between orientations
  3. USB data line signal integrity - One set of USB data lines (orientation B) may have signal quality issues

Verify Hardware

Check your carrier board design:

  1. CC pin resistors - Ensure Rd pull-down resistors are properly placed on both CC1 and CC2(2)
  2. VBUS switching - Verify the VBUS enable circuit responds equally fast for both orientations
  3. USB data line routing - Check impedance matching and trace lengths for both USB2.0 differential pairs

Recommended Next Steps

  1. Immediate: Use orientation A for production until resolved
  2. Short-term: Implement the rootdelay kernel parameter workaround
  3. Long-term:
    • Rebuild TEZI with your custom device tree including USB quirks
    • Investigate hardware CC pin detection timing
    • Consider adding a hardware delay circuit if the issue is orientation detection speed

Questions for Further Diagnosis

  1. How long does it take for the USB device to appear in lsusb with orientation B vs orientation A?
  2. Can you measure the VBUS enable signal timing with an oscilloscope for both orientations?
  3. Does the same delay occur with different USB Type-C devices, or only this HP USB stick?

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.

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.

11

Hi @vishalborle92 ,

Sorry for catching up late on this.

From what I can see, the discussion has evolved significantly since the original issue was reported.

Initially, the USB Type-C mass storage device was not detected in U-Boot, although it worked correctly in Linux. After modifying both the Linux and U-Boot device trees (enabling host mode and configuring reg_usb1_vbus), it was found that USB1_EN was not being asserted in U-Boot.

The issue has since changed to an orientation-dependent problem:

  • In one USB Type-C orientation, the mass storage device is detected consistently.

  • In the other orientation, detection is intermittent, with errors such as:

    • XHCI timeout on event type 33

    • USB device not accepting new address (error=80000000)

You also mentioned that adding the following in the U-Boot device tree improved detection in one orientation:

snps,dis_u2_susphy_quirk;
snps,dis_enblslpm_quirk;
snps,dis-u2-freeclk-exists-quirk;

However, there are still issues during the later boot stages (TEZI/Linux), depending on the cable orientation.

Since the current issue is different from the original one, could I kindly request that you create a new thread describing the latest issue?

12

@sahil.tx @ToradexAI
My current issue is in U-boot not detecting USB2.0 even when I used high-speed property in U-boot device tree.

In Tezi also same problem if Side B connected then not detected for USB2.0 or USB3.0.

Could you please guide me where I am doing wrong?

Thanks,

13

Based on your description and the evolution of this issue, let me provide a focused analysis of the orientation-dependent USB detection problem you’re experiencing in both U-Boot and TEZI.

Summary of Current Issue

You have:

  • :white_check_mark: Orientation A (Side A): Works consistently in U-Boot and TEZI
  • :cross_mark: Orientation B (Side B): Fails or delays detection in both U-Boot and TEZI, despite adding USB quirks

Key Observations

  1. U-Boot: With quirks added, orientation B detection improved but remains unreliable
  2. TEZI: USB device appears too late (after TEZI initialization) in orientation B
  3. Linux: Both orientations eventually work, but orientation B has delayed enumeration
  4. Speed: You’re forcing high-speed (USB 2.0) mode, but the issue persists

Root Cause Analysis

The orientation-dependent behavior strongly suggests a hardware-level issue with your USB Type-C implementation, specifically:

1. USB Type-C Orientation Detection (CC Pins)

USB Type-C uses CC1 and CC2 pins to detect cable orientation and establish the connection. Your symptoms indicate:

  • CC1 detection path (orientation A) works quickly and reliably
  • CC2 detection path (orientation B) is slower or has signal integrity issues

2. Potential Hardware Issues

Check your carrier board design for:

  • CC pin pull-down resistors: Both CC1 and CC2 should have identical 5.1kΩ Rd resistors to ground
  • VBUS enable circuit: Verify the USB1_EN signal path responds equally for both CC pins
  • USB data line routing: Check that both USB 2.0 differential pairs (D+/D- for each orientation) have:
    • Matched impedance (90Ω differential)
    • Equal trace lengths
    • Proper termination

3. USB Type-C Controller/Mux

If your carrier board uses a USB Type-C controller or mux IC (like TUSB320L mentioned in your earlier messages), verify:

  • The controller is properly configured
  • Both orientation detection paths are functioning
  • The mux switching time is consistent

Device Tree Configuration Review

Your current device tree looks correct, but let’s verify a few critical points:

U-Boot Device Tree

&usb_dwc3_0 {
    status = "okay";
    dr_mode = "host";
    maximum-speed = "high-speed";
    
    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;
};

&reg_usb1_vbus {
    startup-delay-us = <500000>;  /* 500ms */
    regulator-boot-on;
    regulator-always-on;
};

Try increasing the delay further:

&reg_usb1_vbus {
    startup-delay-us = <1000000>;  /* Increase to 1000ms (1 second) */
    regulator-boot-on;
    regulator-always-on;
};

Additional Quirks to Try

Add these additional quirks that may help with orientation-dependent timing:

&usb_dwc3_0 {
    status = "okay";
    dr_mode = "host";
    maximum-speed = "high-speed";
    
    snps,dis_u2_susphy_quirk;
    snps,dis_enblslpm_quirk;
    snps,dis-u2-freeclk-exists-quirk;
    snps,dis_u3_susphy_quirk;           /* Add this */
    snps,dis-del-phy-power-chg-quirk;   /* Add this */
    snps,parkmode-disable-ss-quirk;     /* Add this */
    
    /delete-property/ usb-role-switch;
    /delete-property/ role-switch-default-mode;
    /delete-node/ connector;
};

Debugging Steps

1. Test USB Type-C Controller

If you’re using a TUSB320L or similar USB Type-C controller, verify its operation:

# In U-Boot or Linux, check I2C communication with the controller
i2cdetect -y <bus_number>

# Read the orientation detection register
i2cget -y <bus_number> <controller_address> <register>

2. Monitor VBUS Enable Signal

Use an oscilloscope to measure:

  • USB1_EN (SODIMM 155) signal timing for both orientations
  • VBUS (5V) rise time for both orientations
  • Any difference in timing between orientation A and B

3. Check USB Data Lines

With an oscilloscope, verify:

  • Signal quality on both USB D+/D- pairs
  • Eye diagram quality for both orientations
  • Any reflections or impedance mismatches

4. Test Multiple Devices

Test with different USB Type-C devices to determine if the issue is:

  • Device-specific (only certain USB sticks)
  • Universal (all USB devices show the same behavior)

Workarounds

Immediate Solution

For production, standardize on orientation A only until the root cause is resolved:

  • Mark the USB connector or cable with orientation indicators
  • Document the requirement in your production procedures

Software Workaround for TEZI

Add a kernel boot parameter to delay root filesystem mounting:

In U-Boot, before booting TEZI:

setenv bootargs_append "rootdelay=5"
saveenv

This gives the USB subsystem 5 extra seconds to enumerate devices before TEZI looks for installation media.

Next Steps

  1. Hardware verification: Check your carrier board schematic and layout for the items mentioned above
  2. Increase delays: Try the 1-second VBUS delay in both U-Boot and Linux device trees
  3. Add additional quirks: Test the additional DWC3 quirks provided above
  4. Oscilloscope analysis: Measure VBUS and USB1_EN timing for both orientations
  5. Contact Toradex support: If hardware verification shows no issues, this may require deeper investigation by Toradex support with your specific carrier board design

Important Note

Since this is an orientation-dependent hardware issue rather than a pure software configuration problem, the ultimate solution likely requires either:

  • Hardware design modifications to your carrier board
  • Additional buffering/conditioning of the USB Type-C signals
  • Firmware updates to your USB Type-C controller (if applicable)

Could you provide:

  1. Your carrier board schematic (USB Type-C section)
  2. The specific USB Type-C controller IC you’re using (if any)
  3. Oscilloscope measurements of USB1_EN and VBUS for both orientations

This information would help narrow down whether this is a software configuration issue or requires hardware changes.

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.

14

@sahil.tx @ToradexAI
Please find the attached our USB C section schematic as below:

image
image1258×813 62.2 KB

image
image1448×413 46.3 KB

We completely stuck issue with USB C Type detection with side B orientation. We also tried to update the TEZI device tree as below and checked with high-speed and super-speed property but nothing work.

usb-phy@381f0040 {
			compatible = "fsl,imx8mp-usb-phy";
			reg = <0x381f0040 0x40>;
			clocks = <0x02 0x100>;
			clock-names = "phy";
			assigned-clocks = <0x02 0x93>;
			assigned-clock-parents = <0x02 0x02>;
			power-domains = <0x6e 0x01>;
			#phy-cells = <0x00>;
			status = "okay";
			phandle = <0x87>;
		};

		usb@32f10100 {
			compatible = "fsl,imx8mp-dwc3";
			reg = <0x32f10100 0x08 0x381f0000 0x20>;
			clocks = <0x02 0x10c 0x02 0x140>;
			clock-names = "hsio\0suspend";
			interrupts = <0x00 0x94 0x04>;
			power-domains = <0x6e 0x00>;
			#address-cells = <0x01>;
			#size-cells = <0x01>;
			dma-ranges = <0x40000000 0x40000000 0xc0000000>;
			ranges;
			status = "okay";
			fsl,disable-port-power-control;
			fsl,over-current-active-low;
			pinctrl-names = "default";
			pinctrl-0 = <0x86>;
			phandle = <0x120>;

			usb@38100000 {
				compatible = "snps,dwc3";
				reg = <0x38100000 0x10000>;
				clocks = <0x02 0xff 0x02 0x92 0x02 0x140>;
				clock-names = "bus_early\0ref\0suspend";
				interrupts = <0x00 0x28 0x04>;
				phys = <0x87 0x87>;
				phy-names = "usb2-phy\0usb3-phy";
				snps,gfladj-refclk-lpm-sel-quirk;
				snps,parkmode-disable-ss-quirk;
				adp-disable;

				/* Added: Restricts controller to USB 2.0 */
				dr_mode = "host";
				hnp-disable;
				maximum-speed = "super-speed";
				//role-switch-default-mode = "peripheral";
				srp-disable;
				//usb-role-switch;
				phandle = <0x121>;

				connector {
					compatible = "gpio-usb-b-connector\0usb-b-connector";
					id-gpios = <0x4d 0x0a 0x00>;
					label = "Type-C";
					pinctrl-names = "default";
					pinctrl-0 = <0x88>;
					self-powered;
					type = "micro";
					vbus-supply = <0x89>;
				};
			};
		};

		usb-phy@382f0040 {
			compatible = "fsl,imx8mp-usb-phy";
			reg = <0x382f0040 0x40>;
			clocks = <0x02 0x100>;
			clock-names = "phy";
			assigned-clocks = <0x02 0x93>;
			assigned-clock-parents = <0x02 0x02>;
			power-domains = <0x6e 0x02>;
			#phy-cells = <0x00>;
			status = "okay";
			vbus-supply = <0x8a>;
			phandle = <0x8b>;
		};

		usb@32f10108 {
			compatible = "fsl,imx8mp-dwc3";
			reg = <0x32f10108 0x08 0x382f0000 0x20>;
			clocks = <0x02 0x10c 0x02 0x140>;
			clock-names = "hsio\0suspend";
			interrupts = <0x00 0x95 0x04>;
			power-domains = <0x6e 0x00>;
			#address-cells = <0x01>;
			#size-cells = <0x01>;
			dma-ranges = <0x40000000 0x40000000 0xc0000000>;
			ranges;
			status = "okay";
			fsl,disable-port-power-control;
			fsl,permanently-attached;
			phandle = <0x122>;

			usb@38200000 {
				compatible = "snps,dwc3";
				reg = <0x38200000 0x10000>;
				clocks = <0x02 0xff 0x02 0x92 0x02 0x140>;
				clock-names = "bus_early\0ref\0suspend";
				interrupts = <0x00 0x29 0x04>;
				phys = <0x8b 0x8b>;
				phy-names = "usb2-phy\0usb3-phy";
				snps,gfladj-refclk-lpm-sel-quirk;
				snps,parkmode-disable-ss-quirk;
				dr_mode = "host";

				/* Added:Restricts controller to USB 2.0 */
				maximum-speed = "high-speed"; 
				phandle = <0x123>;
			};

@sahil.tx Could you please take this our ticket on priority and suggest proper guidance where could be the issue?

For clarification problem definition is:

  1. When used USB side A orientation then working flow is U-boot detected (USB2.0) –> Tezi loaded and upgraded the SoM image via USB. Once boot in Linux USB detected (USB2.0)
  2. But same USB stick if used with Side B orientation then working flow is U-boot detected (USB3.0) –> Tezi loaded but not upgraded the SoM image because USB not detected see the below log. Once power cycle with previous same image boot in Linux USB detected (USB3.0)
U-Boot 2024.07-7.4.0-devel+git.6efbe8974952 (Jul 17 2026 - 10:06:04 +0000)
 
CPU:   Freescale i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz)
CPU:   Industrial temperature grade (-40C to 105C) at 52C
Reset cause: POR
DRAM:  4 GiB
Core:  174 devices, 30 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
U-Boot FW Ver: 00.00.03
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 #
Verdin iMX8MP #
Verdin iMX8MP #
Verdin iMX8MP # setenv bootargs "quiet rootfstype=squashfs root=/dev/ram autoinstall console=ttymxc2,115200"
Verdin iMX8MP #
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 #
Verdin iMX8MP # load usb 0:1 0x44200000 tezi.itb
42793423 bytes read in 178 ms (229.3 MiB/s)
Verdin iMX8MP #
Verdin iMX8MP # bootm 0x44200000#conf-freescale_imx8mp-verdin-nonwifi-dev.dtb
## Loading kernel from FIT Image at 44200000 ...
   Using 'conf-freescale_imx8mp-verdin-nonwifi-dev.dtb' configuration
   Trying 'kernel-1' kernel subimage
     Description:  Linux kernel
     Type:         Kernel Image
     Compression:  gzip compressed
     Data Start:   0x442000f8
     Data Size:    7827608 Bytes = 7.5 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x48200000
     Entry Point:  0x48200000
     Hash algo:    sha256
     Hash value:   83e9dfc62831678dd09838238e88bd164927a8b6bb1eecaaa370267f32184a72
   Verifying Hash Integrity ... sha256+ OK
## Loading ramdisk from FIT Image at 44200000 ...
   Using 'conf-freescale_imx8mp-verdin-nonwifi-dev.dtb' configuration
   Trying 'ramdisk-1' ramdisk subimage
     Description:  tezi-initramfs
     Type:         RAMDisk Image
     Compression:  uncompressed
     Data Start:   0x44a8aa44
     Data Size:    33828864 Bytes = 32.3 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x52300000
     Entry Point:  unavailable
     Hash algo:    sha256
     Hash value:   bd2be0a3ac44ba3a3e43bec2ea8ff3de29206d9415c3667bfed74d60f36de919
   Verifying Hash Integrity ... sha256+ OK
   Loading ramdisk from 0x44a8aa44 to 0x52300000
## Loading fdt from FIT Image at 44200000 ...
   Using 'conf-freescale_imx8mp-verdin-nonwifi-dev.dtb' configuration
   Trying 'fdt-freescale_imx8mp-verdin-nonwifi-dev.dtb' fdt subimage
     Description:  Flattened Device Tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x4498cc34
     Data Size:    87616 Bytes = 85.6 KiB
     Architecture: AArch64
     Load Address: 0x50200000
     Hash algo:    sha256
     Hash value:   6ed7b862198d4cf0d097c26e7d42ded03d166628ed9f8b55c5be2d3404d134f3
   Verifying Hash Integrity ... sha256+ OK
   Loading fdt from 0x4498cc34 to 0x50200000
   Booting using the fdt blob at 0x50200000
Working FDT set to 50200000
   Uncompressing Kernel Image to 48200000
   Loading Device Tree to 00000000feaa1000, end 00000000feab963f ... OK
Working FDT set to feaa1000
 
Starting kernel ...
 
[    0.178795] imx-drm display-subsystem: no available port
[    0.279662] pca953x 3-0021: failed writing register
Running /etc/rc.local...
Toradex Easy Installer 7.7.0+build.13 ()
Starting udev
[    1.376410] ina2xx 3-0040: error configuring the device: -6
[    1.383494] imx-bus-devfreq 32700000.interconnect: failed to fetch clk: -2
System time was Fri Mar  9 14:41:05 UTC 2018.
Setting the System Clock using the Hardware Clock as reference...
System Clock set. System local time is now Fri Mar  9 14:41:04 UTC 2018.
 
Welcome to the Toradex Easy Installer
 
This is a Linux based installer for Toradex modules. Currently, the installer
does not have a serial console interface. You can use the Toradex Easy Installer
via any of the available display interfaces using USB mouse/keyboard or via a
network connection using VNC. Use:
  # ip addr show
to display the Ethernet IP address(es) or use USB NCM at IP 192.168.11.1.
 
Check our documentation at:
https://developer.toradex.com/software/toradex-easy-installer
~ # lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux 6.6.142-7.7.0 xhci-hcd xHCI Host Controller
Bus 002 Device 001: ID 1d6b:0003 Linux 6.6.142-7.7.0 xhci-hcd xHCI Host Controller
Bus 003 Device 001: ID 1d6b:0002 Linux 6.6.142-7.7.0 xhci-hcd xHCI Host Controller
Bus 004 Device 001: ID 1d6b:0003 Linux 6.6.142-7.7.0 xhci-hcd xHCI Host Controller
~ #
~ #

Please provide your support to resolve this issue, we are waiting your reply.

Thanks,

15

Based on your schematic and detailed logs, I can now provide a more targeted analysis of your USB Type-C orientation issue.

Analysis of Your Hardware Design

Looking at your schematic, I can identify several potential issues:

1. USB Type-C Configuration Controller (TUSB320L)

Your design uses the TUSB320L USB Type-C configuration channel logic and port controller. This IC is responsible for:

  • Detecting cable orientation via CC1/CC2 pins
  • Controlling VBUS power delivery
  • Switching USB data lines based on orientation

Critical observations:

  • The TUSB320L controls orientation detection, but I don’t see evidence in your device tree that you’re properly initializing or communicating with this IC
  • The IC needs to be configured via I2C to properly handle both orientations

2. Missing TUSB320L Driver/Configuration

Your device tree modifications focus on the USB controller (usb_dwc3_0), but you haven’t configured the TUSB320L that actually controls the Type-C orientation detection.

The TUSB320L needs:

  • I2C communication to configure its registers
  • Proper initialization in both U-Boot and Linux
  • GPIO configuration for its control signals

3. Hardware Design Verification

From your schematic:

  • :white_check_mark: CC1 and CC2 have 5.1kΩ pull-down resistors (correct for UFP/device mode)
  • :white_check_mark: VBUS_DET is connected to the TUSB320L
  • :warning: The TUSB320L’s I2C address and bus need to be verified in your device tree

Root Cause: TUSB320L Not Initialized in TEZI

Your logs show:

[    0.279662] pca953x 3-0021: failed writing register
[    1.376410] ina2xx 3-0040: error configuring the device: -6

These I2C errors suggest that I2C communication is failing during TEZI boot. If the TUSB320L is on the same I2C bus and isn’t being initialized properly, it may not be switching the USB data lines correctly for orientation B.

Solution Steps

1. Add TUSB320L to Device Tree

You need to add the TUSB320L device node to both your U-Boot and Linux device trees:

For U-Boot device tree:

&i2c<X> {  /* Replace <X> with the correct I2C bus number */
    tusb320@47 {  /* Default I2C address is 0x47, verify from your schematic */
        compatible = "ti,tusb320";
        reg = <0x47>;
        vbus-supply = <&reg_usb1_vbus>;
        status = "okay";
    };
};

For Linux/TEZI device tree:

&i2c<X> {
    tusb320: tusb320@47 {
        compatible = "ti,tusb320";
        reg = <0x47>;
        vbus-supply = <&reg_usb1_vbus>;
        interrupt-parent = <&gpio>;
        interrupts = <X GPIO_ACTIVE_LOW>;  /* Configure based on your INT_N connection */
        status = "okay";
    };
};

2. Verify I2C Bus and Address

From your schematic, determine:

  • Which I2C bus the TUSB320L is connected to
  • The exact I2C address (typically 0x47 or 0x60 depending on ADDR pin)
  • Whether the INT_N signal is connected to a GPIO

3. Initialize TUSB320L in U-Boot

The TUSB320L may need explicit initialization in U-Boot. Add this to your board initialization code (board/toradex/verdin-imx8mp/verdin-imx8mp.c or equivalent):

#define TUSB320_I2C_ADDR 0x47
#define TUSB320_REG_CONTROL 0x0A

int board_usb_init(int index, enum usb_init_type init)
{
    struct udevice *bus, *dev;
    int ret;
    
    /* Get I2C bus */
    ret = uclass_get_device_by_seq(UCLASS_I2C, <bus_number>, &bus);
    if (ret) {
        printf("TUSB320: I2C bus not found\n");
        return ret;
    }
    
    /* Probe TUSB320 */
    ret = dm_i2c_probe(bus, TUSB320_I2C_ADDR, 0, &dev);
    if (ret) {
        printf("TUSB320: Device not found at 0x%02x\n", TUSB320_I2C_ADDR);
        return ret;
    }
    
    /* Configure TUSB320 for DFP (host) mode */
    dm_i2c_reg_write(dev, TUSB320_REG_CONTROL, 0x02);  /* Set to DFP mode */
    
    mdelay(100);  /* Allow time for orientation detection */
    
    return 0;
}

4. Increase TEZI Boot Delay

Since orientation B causes delayed enumeration, modify your TEZI boot command to add a delay:

In U-Boot:

setenv bootargs "quiet rootfstype=squashfs root=/dev/ram autoinstall console=ttymxc2,115200 rootdelay=5"
saveenv

This gives the USB subsystem 5 seconds to enumerate before TEZI looks for installation media.

5. Debug I2C Communication

At the TEZI shell prompt, verify I2C communication with the TUSB320L:

# Detect I2C devices
i2cdetect -y <bus_number>

# Read TUSB320 device ID register (should return 0x00 for TUSB320)
i2cget -y <bus_number> 0x47 0x00

# Read status register
i2cget -y <bus_number> 0x47 0x09

6. Modified TEZI Device Tree

Your TEZI device tree modifications look mostly correct, but ensure the TUSB320L is also defined. The key issue is that the TUSB320L must be initialized before the USB controller to properly detect orientation.

Why Orientation A Works but B Doesn’t

The likely scenario:

  1. Orientation A (CC1): The TUSB320L defaults to this orientation on power-up, so even without proper I2C initialization, it works
  2. Orientation B (CC2): Requires the TUSB320L to actively switch the USB data mux, which only happens if the IC is properly initialized via I2C

Verification Steps

  1. Verify TUSB320L I2C address and bus from your schematic
  2. Add TUSB320L device node to both U-Boot and Linux device trees
  3. Test I2C communication with the TUSB320L at the TEZI shell
  4. Add U-Boot initialization for the TUSB320L
  5. Increase rootdelay in TEZI boot arguments
  6. Rebuild and test with both orientations

Expected Behavior After Fix

After properly initializing the TUSB320L:

  • Both orientations should enumerate at the same speed
  • TEZI should detect the USB drive in both orientations
  • No delayed enumeration in orientation B

Could you:

  1. Confirm the I2C bus number and address for the TUSB320L from your schematic?
  2. Test I2C communication with the TUSB320L using the commands above?
  3. Check if there are any TUSB320L-related error messages in dmesg?

This should resolve your orientation-dependent USB detection issue.

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.

16

@ToradexAI We are not using the I2C communication mode for TUSB320L instead we used GPIO mode, PORT pin of TUSB320L chip is pullup with R81 10K is populated on board to enabled DFP(Host) mode only.

17

Hi @vishalborle92 ,

Sorry for the delay in getting back to you. I was occupied with some other work and was out of the office.

I am currently reviewing your schematics and trying to understand the USB Type-C implementation. From what I can see, you are implementing USB 3.x over a USB Type-C connector, and the TUSB320L is configured in GPIO mode as a DFP (Host).

I have one question regarding the USB 3.x implementation. Could you please clarify how the cable orientation is handled for the SuperSpeed (SSTX/SSRX) lanes when the Type-C cable is flipped?

In the TUSB320L datasheet, for GPIO mode, the outputs are described as:

  • OUT1 – Current mode detect

  • OUT2 – Current mode detect

  • OUT3 – Audio accessory detect

  • ID – Device attached

None of these appear to indicate the cable orientation. Could you please explain how the orientation information is used in your design to handle the USB 3.x SuperSpeed lane routing? Is there any additional hardware or logic involved?

18

@sahil.tx

Thanks for the reply.

In firmware for orientation detection we did not add any specific logic what ever the USB stack from Toradex BSP7.4.0 that we are using.

The OUT1 and OUT2 we are not doing anything on those pins. But today I rebuild the TEZI package device tree and updated the below changes then it start working in Tezi also.

See the below added comments to where I updated the Tezi device tree.

usb-phy@381f0040 {
			compatible = "fsl,imx8mp-usb-phy";
			reg = <0x381f0040 0x40>;
			clocks = <0x02 0x100>;
			clock-names = "phy";
			assigned-clocks = <0x02 0x93>;
			assigned-clock-parents = <0x02 0x02>;
			power-domains = <0x6e 0x01>;
			#phy-cells = <0x00>;
			status = "okay";

			/* Vishal Added: Enabled VBUS supply to resolve issue USB Side B not detected */
			vbus-supply = <0x89>;
			phandle = <0x87>;
		};

		usb@32f10100 {
			compatible = "fsl,imx8mp-dwc3";
			reg = <0x32f10100 0x08 0x381f0000 0x20>;
			clocks = <0x02 0x10c 0x02 0x140>;
			clock-names = "hsio\0suspend";
			interrupts = <0x00 0x94 0x04>;
			power-domains = <0x6e 0x00>;
			#address-cells = <0x01>;
			#size-cells = <0x01>;
			dma-ranges = <0x40000000 0x40000000 0xc0000000>;
			ranges;
			status = "okay";
			fsl,disable-port-power-control;
			fsl,over-current-active-low;
			pinctrl-names = "default";
			pinctrl-0 = <0x86>;
			phandle = <0x120>;

			usb@38100000 {
				compatible = "snps,dwc3";
				reg = <0x38100000 0x10000>;
				clocks = <0x02 0xff 0x02 0x92 0x02 0x140>;
				clock-names = "bus_early\0ref\0suspend";
				interrupts = <0x00 0x28 0x04>;
				phys = <0x87 0x87>;
				phy-names = "usb2-phy\0usb3-phy";
				snps,gfladj-refclk-lpm-sel-quirk;
				snps,parkmode-disable-ss-quirk;
				adp-disable;

				/* Vishal Added: Restricts controller USB Host mode only */
				dr_mode = "host";
				hnp-disable;
				maximum-speed = "super-speed";
				srp-disable;
				phandle = <0x121>;

				/* Vishal Added: Removed the connector node because for our board we are not using USB role switch
					only DFP or Host mode used hence comment this node */
				//role-switch-default-mode = "peripheral";
				//usb-role-switch;
				
				// connector {
				// 	compatible = "gpio-usb-b-connector\0usb-b-connector";
				// 	id-gpios = <0x4d 0x0a 0x00>;
				// 	label = "Type-C";
				// 	pinctrl-names = "default";
				// 	pinctrl-0 = <0x88>;
				// 	self-powered;
				// 	type = "micro";
				// 	vbus-supply = <0x89>;
				// };
			};
		};

		usb-phy@382f0040 {
			compatible = "fsl,imx8mp-usb-phy";
			reg = <0x382f0040 0x40>;
			clocks = <0x02 0x100>;
			clock-names = "phy";
			assigned-clocks = <0x02 0x93>;
			assigned-clock-parents = <0x02 0x02>;
			power-domains = <0x6e 0x02>;
			#phy-cells = <0x00>;
			status = "okay";
			vbus-supply = <0x8a>;
			phandle = <0x8b>;
		};

		usb@32f10108 {
			compatible = "fsl,imx8mp-dwc3";
			reg = <0x32f10108 0x08 0x382f0000 0x20>;
			clocks = <0x02 0x10c 0x02 0x140>;
			clock-names = "hsio\0suspend";
			interrupts = <0x00 0x95 0x04>;
			power-domains = <0x6e 0x00>;
			#address-cells = <0x01>;
			#size-cells = <0x01>;
			dma-ranges = <0x40000000 0x40000000 0xc0000000>;
			ranges;
			status = "okay";
			fsl,disable-port-power-control;
			fsl,permanently-attached;
			phandle = <0x122>;

			usb@38200000 {
				compatible = "snps,dwc3";
				reg = <0x38200000 0x10000>;
				clocks = <0x02 0xff 0x02 0x92 0x02 0x140>;
				clock-names = "bus_early\0ref\0suspend";
				interrupts = <0x00 0x29 0x04>;
				phys = <0x8b 0x8b>;
				phy-names = "usb2-phy\0usb3-phy";
				snps,gfladj-refclk-lpm-sel-quirk;
				snps,parkmode-disable-ss-quirk;
				dr_mode = "host";

				/* Vishal: Updated controller to USB 3.0 */
				maximum-speed = "super-speed"; 
				phandle = <0x123>;
			};

Again the question is why we need to do those changes in Tezi? Is this any open issue in Tezi?
Currently we are using Tezi version is Toradex Easy Installer 7.7.0+build.13 ().

Is there anything missing in hardware schematic?

One concern regarding this Tezi device tree solution is that the SoM firmware can be upgraded via the USB Boot option using the Side-B orientation only after Tezi has been updated.

However, when a new Verdin iMX8MP SoM is received from the factory, it already comes with the default Tezi image installed. In that case, how would this solution work for first-time programming or recovery if USB detection is not functioning in the Side-B orientation?

Could you please clarify the expected workflow and how this scenario is intended to be handled?

Thanks,

Vishal

19

Hi @vishalborle92 ,

I’m still trying to understand the USB Type-C implementation a bit better.
One possibility I’m trying to rule out is whether the connection is falling back to USB 2.0
From my understanding, the expected flow should be:

USB-C cable inserted
        │
        ▼
CC1/CC2 detected by TUSB320L
        │
        ▼
Cable orientation determined
        │
        ▼
Hardware uses this information to handle the USB 3.x SuperSpeed (SSTX/SSRX) lane routing
        │
        ▼
       SoC

From the hardware schematics shared so far, I could not identify how the SuperSpeed lane routing is handled after the TUSB320L detects the cable orientation.
It is possible that this portion of the design is present on another schematic page that has not yet been shared. If so, could you please share that section as well?

Additionally, could you verify whether the USB device is enumerating as USB 3.x or USB 2.0 ?
You can check this on the Verdin module by running:

lsusb -t

Regarding your question about first-time programming of a new SoM, could you also let me know how you plan to perform production programming?

Specifically:

  • Will you be programming the modules on your custom carrier board or on a Toradex evaluation/reference board?

  • Do you intend to flash the modules via USB recovery mode (TEZI), SD card, or using an Image Server / Easy Installer network installation?

20

@sahil.tx

Thanks for the prompt response..!!

Here is below SoM side interface:

image
image963×231 43.2 KB

Please note net name I2C_1_SCL and I2C_1_SDA is used and OUT1 and OUT2 coming from TUSB320L in GPIO mode.

I already verified by using “lsusb -t“ command and out put is:
When used side A orientation used:

root@verdin-imx8mp-15677546:~# lsusb -t
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 480M
    |__ Port 001: Dev 002, If 0, Class=Mass Storage, Driver=uas, 480M
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 5000M
root@verdin-imx8mp-15677546:~#
root@verdin-imx8mp-15677546:~#

When Side B orientation used:

root@verdin-imx8mp-15677546:~#
root@verdin-imx8mp-15677546:~# lsusb -t
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 480M
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci-hcd/1p, 5000M
    |__ Port 001: Dev 002, If 0, Class=Mass Storage, Driver=uas, 5000M
root@verdin-imx8mp-15677546:~#
  • Will you be programming the modules on your custom carrier board or on a Toradex evaluation/reference board?

We designed our own custom carrier board with Verdin-iMX8mp SOM.

  • Do you intend to flash the modules via USB recovery mode (TEZI), SD card, or using an Image Server / Easy Installer network installation?

We are flashing the SoM using C Type USB via TEZI without recovery mode. Our USB stick internal file structure is like below:

image
image726×602 125 KB

I hope the information will help for further analysis.

Thanks,