Torizon 7.1.0 USB Regulator Device Tree Settings

I have been working on getting USB working on my custom carrier board, and found some inconsistent behavior from the USB PWR Enable pins.

For both the AM62 and IMX8MP compute models I am evaluating, with a completely native OS 7.1.0 install, both USB enable pins (SODIMM 155 [USB_1_EN] and SODIMM 185 [USB_2_EN]) are active low (seems to be the verdin spec) during bootup. Once entering the OS, SODIMM 185 goes high and stays high, killing power to the usb port. SODIMM 155 stays low. I have the USB_1_ID (SODIMM 161) pin tied to ground, and it works and registers in the os as host mode, so I don’t think this is related to the OTG functions.

Its possible to go to the power management for the usb devices, as described in this article… Linux control USB power-enable switch

When reading the pm_qos_no_power_off setting of the usb devices, both are set as 1. When writing a 0 to the USB 2 port, SODIMM 185 goes low, giving power to the usb (but in my testing no comms, which is somewhat expected.)

I found an article about changing the pin settings in the device tree USB Host Power-Enable Polarity

When looking at imx8mp-verdin.dtsi, both usb regulators have the property of enable-active-high. If I remove this property from the usb2 regulator, then the port has power during u-boot, loses power when reaching the OS, and restores power after a few seconds.

USB 1 stays powered during the entire booting process. If I remove enable-active-high from the usb1 regulator, then it turns off after entering the OS.

This seems like inconstant behavior to me, and I didn’t see anything noting this kind of difference in the schematics or design guides I looked at. I can use the USB devices which the change to the device tree, but not sure why the pin polarity seems to be flipped between the 2 USB devices.

Below is a picture of my carrier board setup just to rule out any potential issues on that end. Both regulators are active low.

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


Hello,

Thank you for reaching out with your question about the USB enable pins on Verdin modules. Here’s a summary of their functionality:

For USB_1:

  • Pin 155 (USB_1_EN) serves as an enable signal for bus voltage output in host mode.
  • Pin 161 (USB_1_ID) is used for cable identification in OTG mode.
  • USB_1 is designed as an OTG port, capable of switching between host and device roles.

For USB_2:

  • Pin 185 (USB_2_EN) acts as an enable signal for bus voltage output.
  • USB_2 is configured as host-only in the Verdin standard.

Regarding the USB power management issues you are experiencing, these might be related to the USB hub port control functionality. Here are some steps you can take to troubleshoot:

  1. Use uhubctl to manually control port power and observe the behavior.
  2. Ensure devices are properly removed from the runtime USB configuration before making power changes.
  3. Verify the compatibility and configuration of your USB hub firmware.

Since you are using Torizon OS 7, please note that it utilizes a different BSP version, which could influence USB subsystem behavior. While specific polarity behavior isn’t explicitly documented, these steps should help you manage and troubleshoot your USB setup effectively.

I hope this information assists you in resolving the issues. If you have further questions, feel free to ask.

Best regards,
Toradex AI Assistant

Please, also check if these links can help you solve your problem:

RFC: Torizon OS 7 release will require a new branch · Issue #25 · toradex/torizon-samples · GitHub.

Could you please specify the OS you’re using more precisely by posting the output of the tdx-info command?

Software summary

Bootloader: U-Boot
Kernel version: 6.6.54-7.1.0-g3493ccd66900 #1-Torizon SMP PREEMPT Tue Dec 17 21:04:41 UTC 2024
Kernel command line: root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/500611918e07c8fe1cf9b3cc8f76327936d80d93ad461d3fe0da9c30624ff84b/0
Distro name: NAME=“Torizon OS”
Distro version: VERSION_ID=7.1.0-build.4
Distro variant: VARIANT=“Docker”
Hostname: verdin-imx8mp-15459942

Hardware info

HW model: Toradex Verdin iMX8M Plus on Mallow Board
Toradex version: 0063 V1.1B
Serial number: 15459942
Processor arch: aarch64

​According to the Verdin Family Specification, the USB_x_EN signal is active high, consistent with other Toradex module specifications such as Colibri and Apalis. During the operating system boot process, SODIMM pin 185 transitions high when the USB driver is fully loaded, ensuring that any already connected USB devices are properly enumerated. This high state persists, enabling USB VBUS power as implemented on all Toradex carrier boards.

I’d suggest to adhere to the recommendations outlined in the Verdin Carrier Board Design Guide rather than modifying the device tree.

For example recommended implementation for USB_2 looks this way:

If you want USB 2.0 host-only functionality on USB_1 as well, you can use the same schematic, leaving USB_1_ID floating and pulling USB_1_VBUS up to 3.3V.

Thanks for the info, that explains quite a few of the issues I was having. I am not sure why I chose that specific power chip now.

I did have a couple more questions specifically related to the OTG port though. Most of the references I have read have specifically stated that to enable host mode, the ID pin should be grounded, and that it is left floating for peripherals. That seems to be the opposite of your statement, so not sure I understand the intent, and unfortunately I haven’t found any great resources for describing how to work around the OTG functionality.

I also tried initially to edit the USB port to be host mode in the device tree, to completely ignore the ID pin (Or I assume that would work). That, and setting the port’s max speed doesn’t seem to be working for me. Is that possible to do with a device tree overlay, or is that specifically something that needs to be done at the board level?

If the callout on the enable pin polarity could be made a little more clear in the specifications, that would be great. I was so worried about the impedance and length matching, along with figuring out the OTG stuff that it completely slipped my mind to check that polarity. I also assumed all the problems with comms were related to that and not power for quite a long time (unfortunately the first time I got it to work on the first prototype board was due to managing to set the port speed lower on an older OS version, but it was probably several changes happening all at once).

Yes, in the case of USB host functionality, the ID pin can be left floating only if the role is defined by software.

You can see how this is implemented for USB_2 in Toradex device tree.
However, I highly recommend configuring USB_1 as dual-role so it can be used for recovery (serial mode) if needed.

You can connect a USB-A connector in parallel with a Micro-AB connector if you intend to use that port primarily as a host, similar to how it’s done on the Ixora board

Then I guess I am actually have a problem with USB port 1, because I do have the ID pin grounded making it a host, but it is turning on my active low device, when it shouldn’t. Or is it that USB 1 and USB 2 enable are supposed to have opposite polarity?

I am not concerned about matching the verdin spec for OTG. We can use a development board for recovery mode if needed. I also don’t quite see how changes to the device tree would affect recovery mode. Isn’t that a bootloader completely separate from the OS, that allows for reflashing uboot (or bootloader of choice). Sorry, I am not entirely familiar with this, and the previous board we used, recovery mode was only for restoring uboot using UUU when an update caused corruption.

Could you elaborate? If the ID pin is grounded, it should operate in host mode unless the device tree node has the dr_mode = "peripheral" property set.

USB_1 and USB_2 are functionally identical, except that the USB_2_ID pin is not routed to the X1 connector. This means you can configure its role only via software

This was my original problem, with USB_1_ID grounded, USB_1_EN stays low thru the entire boot process and entering OS. USB_2_EN begins low on boot, and transitions to high after entering the OS.

I thought the problem was USB_2 but I guess the problem was actually USB_1. The more concerning thing to me was that they behaved differently and I wanted to clarify that.

I went back and changed my device tree to make dr_mode = “host” instead of OTG to be sure and still experiencing the same behavior. This behavior only changed when removing the enable-active-high setting for the regulator.

I’ve tested Verdin iMX8M Plus WB on Verdin Development Board
Toradex version: 0058 V1.1B

With :

Kernel version:           5.15.148-6.8.1+git.1cbf48124747 #1 SMP PREEMPT Fri Dec 20 08:57:54 UTC 2024
Kernel command line:      root=PARTUUID=48702062-02 ro rootwait console=tty1 console=ttymxc2,115200 consoleblank=0 earlycon
Distro name:              NAME="TDX Wayland with XWayland"
Distro version:           VERSION_ID=6.8.1-build.15

and

Kernel version:           6.6.74-rt48-7.2.0-devel-gdb477bff45f0 #1-Torizon SMP PREEMPT_RT Thu Jan  1 00:00:00 UTC 1970
Kernel command line:      root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/fee7dcff3ecfc654ef7fe7bcf16b9c6837ac2f74f4654c501a30fb7a1795f1e4/0
Distro name:              NAME="Torizon OS with PREEMPT_RT"
Distro version:           VERSION_ID=7.2.0-devel-20250319-build.188

In both cases, when USB_1_ID was grounded, USB_1_EN went HIGH after the OS booted. It remained LOW when USB_1_ID was left floating.
Please double-check whether USB_1_ID is truly grounded in your setup (you can measure the voltage on Mallow’s R90), and ensure that you are using the correct Device Tree.

I need to experiment more, but I think I found the issue, and it appears it is probably related to some overlay stuff I was trying to do. After updating to OS 7.2 I found it working correctly until I moved over all the device tree overlays I was working with.

I added the following lines to an overlay I was working on, and this could potentially be part of the issue. I believe this is related to me thinking the ports would not be able to do full speed, and these where the changes that “fixed” it (made the pin stay low and actually enabled power).

&usb_dwc3_0 {
status = “okay”;
dr_mode = “host”;
maximum-speed = “full-speed”;
};

&usb_dwc3_1 {
status = “okay”;
dr_mode = “host”;
maximum-speed = “full-speed”;
};

&usb3_0 {
status = “okay”;
dr_mode = “host”;
maximum-speed = “full-speed”;
};

&usb3_1 {
status = “okay”;
dr_mode = “host”;
maximum-speed = “full-speed”;
};

I mistakenly thought this hadn’t been applied to the previous OS. I will double check on Friday that these settings are the culprit, and follow up from there. I will also order some of the enable high chips to replace on some boards, to make sure I have some things to test with the correct setup.

After further testing, the USB_1_EN pin stays low when

&usb_dwc3_0 {
dr_mode = “host”;
};

is added to a device tree overlay. Tested with USB_1_ID grounded or floating. Not a problem in my application, but that seems to not be the intended behavior.

looks like setting dr_mode = "host" alone is not enough to override the behavior tied to the usb-role-switch and connector configuration.
You can try at your overlay something like this:

/dts-v1/;
/plugin/;

/ {
fragment@0 {
target = <&usb_dwc3_0>;
overlay {
dr_mode = “host”;
maximum-speed = “high-speed”;

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

        connector {
            compatible = "usb-a-connector";
            label = "Type-A";
            type = "a";
            vbus-supply = <&reg_usb1_vbus>;
            self-powered;
        };
    };
};

};

This does fix my issue, and the usb configs seem to be working the expected way. Thanks for your help.

Small note in the config you posted, the dr_mode and max speed have different double quotes compared to the connector, which did cause some issues when I first tried the code. Not sure why it used left and right double quotes instead of just normal double quotes.

That probably applies to some of the configs I posted above too. Took me a while to figure out what the issue was.

Glad to hear your issue is resolved. Thank you for sharing!