Verdin iMX8MP u-boot OTG

Technical Support
, , ,
1

Greetings,

Do you have any information on the support status for USB-OTG on USB3_0 in u-boot on the iMX8MP?

After some investigation, it looks like when dr_mode is specified as “otg” in the u-boot devicetree, the default behaviour is device mode (e.g. ums mmc 2 works as expected and mounts the SoM eMMC over USB). However, attempting to connect a flash drive to the USB port and running usb start, the port is never scanned (only USB3_1 is scanned), and thus no devices are found. The only way I can get it to work is by forcing dr_mode=“host”, which (as expected) breaks the ums ability.
The port is fully functional as a DRP when Linux has booted, so the ID pins and related bits are all correct.

for context, I am attempting to understand whether the bootcmd_usb0 functionality can be restored on the 8MP; previously on an iMX6 based device we were leveraging this as an “emergency-unbrick” procedure that doesn’t rely on the complexity of walking someone through USB tethering and SDP to load TEZI and then flash an image to the device; instead we could supply an all-in-one USB drive package from which the device could boot TEZI and also find the image to reflash.

Certainly we could force USB3_0 into host-only mode in u-boot to support this, but it’s unclear to me whether that’s wise without first understanding why the 8MP default is “peripheral” mode. Is that purely to support ums for convenience, or is there additional functionality here I’m not aware of?

Thanks in advance for any information you can provide!
~BW908

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 the available documentation, I can provide some relevant information about USB behavior in U-Boot on Toradex modules, though the specific USB-OTG configuration details for iMX8MP in U-Boot aren’t fully covered in the current sources.

USB Issues in U-Boot

From the community discussions, there are known USB enumeration issues in U-Boot on iMX8-based modules. One user reported similar USB device recognition problems where some USB devices work properly while others fail with errors like “USB device not accepting new address (error=80000000)” (1). This suggests there may be broader USB compatibility issues in the U-Boot USB stack for iMX8 platforms.

USB Configuration Challenges

The community discussions also show that enabling additional USB ports in U-Boot requires specific device tree modifications and may need custom initialization code. For example, enabling USBH2 and USBH3 on Apalis iMX8QM required significant device tree changes and custom board initialization functions (2).

Device Tree Overlay Considerations

When modifying USB configurations through device tree overlays, it’s important to avoid pin conflicts that could affect other peripherals. The documentation shows examples where GPIO configurations can inadvertently break UART functionality if pins are not properly managed (3).

Recommendation

Given the complexity of USB-OTG configuration in U-Boot and the potential for conflicts, I’d recommend:

  1. Check your specific hardware setup: Could you let me know which Toradex SoM and carrier board you’re using, and which OS version you’re running? You can use the tdx-info command to get this information - see this guide.

  2. Consider alternative approaches: Since you mentioned this is for an “emergency-unbrick” procedure, you might want to explore whether Toradex Easy Installer’s recovery mechanisms could serve your needs without requiring USB-OTG host mode in U-Boot.

The specific behavior you’re observing with dr_mode=“otg” defaulting to device mode may be intentional to prioritize UMS functionality, but without more detailed U-Boot configuration documentation for your specific platform, I cannot provide definitive guidance on the trade-offs involved.

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

Greetings @bw908,

Just to understand you’re asking why usb_dwc3_0 in the U-Boot device tree is set to otg mode by default?

Far as I can tell I don’t seem to notice any specific technical reason. I believe it’s more of a compatibility reason. To explain, our U-Boot device tree just mirrors the Linux device tree. In the Linux device tree we also have usb_dwc3_0 set to otg as well: Making sure you're not a bot!

As for why this is otg by default, this is more due to following the standard in the Verdin family specification. This is a excerpt from the Verdin i.MX8M Plus device tree:

The i.MX 8M Plus SoC features two identical USB 2.0 ports which are both OTG capable. However, in the Verdin standard, only the USB_1 port is an OTG port, while USB_2 is only a host port. Therefore, it is recommended to use only the USB_1 as an OTG port

Our default device trees usually stick to the family standard for max portability/compatibility between modules within the same family. But, of course users can deviate from the standard as long as they understand what this entails.

So it should be okay to change the mode of this I would assume. Of course we only test the default configuration of these interfaces, so any issues would be unforeseen by us unless reported by others.

Best Regards,
Jeremias

4

Hi Jeremias,

Thanks for the response - mostly I am looking to gain any insight I can into support for OTG functionality (or lack thereof) in u-boot, on the iMX8 MP. My tests appear to suggest it does not work as expected in that USB_1 does not dynamically switch roles when a storage device is connected and remains “stuck” in device mode. If this is expected, that is fine, but I figured an external sanity-check on my observations might be helpful to make sure it is not something specific to our hardware.

I do appreciate the info provided; it does answer my question as to ‘known’ implications of forcing host-only mode on USB_1 for our own purposes - it seems like that should be reasonably safe to do (at the expense of being able to use ums for development convenience). Certainly there are other options we could do instead that are more “compatible” such as potentially storing a copy of TEZI on a built-in SD card and avoiding the need to boot from USB.

5

My tests appear to suggest it does not work as expected in that USB_1 does not dynamically switch roles

So I looked into this a bit, and I believe this is just something that is missing in U-Boot.

As you said DRP is functional in Linux. So I took a look there, in the device-tree for Linux there is this property usb-role-switch, which signifies that the USB device is capable of dynamic role switching: Making sure you're not a bot!

However, this property is also seen in the U-Boot device-tree: Making sure you're not a bot!

Though it’s possible this was just something that was copied over. Looking into the drivers we see some differences. In Linux the corresponding DWC USB driver is specific to i.MX8MP: Making sure you're not a bot!

While in U-boot it’s generic: Making sure you're not a bot!

Furthermore, the core of the DWC3 USB driver in Linux has logic to handle the usb-role-switch property: Making sure you're not a bot!

While the equivalent in U-Boot does not: Making sure you're not a bot!

This leads me to believe that the dynamic role switching for DWC USB devices was just never added to U-Boot, by anyone.

Best Regards,
Jeremias

6

Thanks for the confirmation! :slight_smile: For now we will probably force host-mode on USB_1 and if time permits I may tinker around a bit to see whether it can be backported.

7

Glad I was able to help clarify.

Best Regards,
Jeremias

1 Like