Reg_usb_host_vbus causes hang on boot

Technical Support
, , ,
1

Hi, I’m developing a custom carrier board based on imx8 apalis. We only need to use the USBH (usbh1). We added regulator-name in our devicetree and turned on the respective nodes

reg_usb_host_vbus: regulator-usb-host-vbus {
        regulator-name = "VCC USBH2(ABCD) / USBH(3|4)";
    };
...
...
&usbh1 {
    vbus-supply = <&reg_usb_host_vbus>;
    status = "okay";
};

&usbphynop2 {
    status = "okay";
};

just like the eval board example. However, the kernel hangs when booting when we only turned on usbh1 with the following serial prints:

[    0.000000] 000: efi: Getting EFI parameters from FDT:
[    0.000000] 000: efi: UEFI not found.
[    0.000000] 000: Reserved memory: created DMA memory pool at 0x0000000090400000, size 1 MiB
[    0.000000] 000: OF: reserved mem: initialized node vdevbuffer, compatible id shared-dma-pool
[    0.000000] 000: cma: Reserved 480 MiB at 0x00000000de000000
[    0.000000] 000: NUMA: No NUMA configuration found
[    0.000000] 000: NUMA: Faking a node at [mem 0x0000000080200000-0x00000000ffffffff]
[    0.000000] 000: NUMA: NODE_DATA [mem 0xffbc13c0-0xffbc2fff]
[    0.000000] 000: Zone ranges:
[    0.000000] 000:   DMA32    [mem 0x0000000080200000-0x00000000ffffffff]
[    0.000000] 000:   Normal   empty
[    0.000000] 000: Movable zone start for each node
[    0.000000] 000: Early memory node ranges
[    0.000000] 000:   node   0: [mem 0x0000000080200000-0x0000000083ffffff]
[    0.000000] 000:   node   0: [mem 0x0000000086400000-0x0000000087ffffff]
[    0.000000] 000:   node   0: [mem 0x000000009000000

The problem goes away when we turn on USB OTG1 as well. I can’t find any correlation between these two, so here are my questions:

  1. Does USBH (or reg_usb_host_vbus) depends on USB OTG1?
  2. How do I just turn on USBH?
2

Hi @wilsonkoe,

Please share BSP version you are working with?

This might be related to below issue(ELB-2957) not sure. Please check

Also please let us know is there any requirement for disabling USB OTG in your design/application ?

Best Regards
Ritesh Kumar

3

Hi @ritesh.tx ,

Thanks for the response. Here’s our manifest and the versions (commit hashes) of each package:

  <!-- bitbake: Branch 1.46 -->
  <!-- https://github.com/openembedded/bitbake/commit/e6d75e0beb95aa0cdf82bbc0a6b767c7f6cfcfc0 -->
  <project name="bitbake.git" path="layers/openembedded-core/bitbake" remote="oe" revision="e6d75e0beb95aa0cdf82bbc0a6b767c7f6cfcfc0" upstream="1.46"/>
  
  <!-- meta-openembedded: Branch dunfell -->
  <!-- https://github.com/openembedded/meta-openembedded/commit/ab9fca485e13f6f2f9761e1d2810f87c2e4f060a -->
  <project name="meta-openembedded.git" path="layers/meta-openembedded" remote="oe" revision="ab9fca485e13f6f2f9761e1d2810f87c2e4f060a" upstream="dunfell"/>
  
  <!-- meta-yocto: Branch dunfell -->
  <!-- https://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto/commit/?id=44647201cfcdb4dd11eb1651ab62c64ca2aacb10 -->
  <project name="meta-yocto" path="layers/meta-yocto" remote="yocto" revision="44647201cfcdb4dd11eb1651ab62c64ca2aacb10" upstream="dunfell"/>
  
  <!-- openembedded-core: Branch dunfell -->
  <!-- https://github.com/openembedded/openembedded-core/commit/01f256bc72fb45c80b6a6c77506bc4c375965a3a -->
  <project name="openembedded-core.git" path="layers/openembedded-core" remote="oe" revision="01f256bc72fb45c80b6a6c77506bc4c375965a3a" upstream="dunfell"/>
  
  <!-- meta-freescale-3rdparty: Branch dunfell -->
  <!-- https://github.com/Freescale/meta-freescale-3rdparty/commit/c52f64973cd4043a5e8be1c7e29bb9690eb4c3e5 -->
  <project name="meta-freescale-3rdparty.git" path="layers/meta-freescale-3rdparty" remote="githf" revision="c52f64973cd4043a5e8be1c7e29bb9690eb4c3e5" upstream="dunfell"/>
  
  <!-- meta-freescale-distro: Branch dunfell -->
  <!-- https://github.com/Freescale/meta-freescale-distro/commit/5d882cdf079b3bde0bd9869ce3ca3db411acbf3b -->
  <project name="meta-freescale-distro.git" path="layers/meta-freescale-distro" remote="githf" revision="5d882cdf079b3bde0bd9869ce3ca3db411acbf3b" upstream="dunfell"/>
  
  <!-- meta-freescale: Branch dunfell -->
  <!-- https://github.com/Freescale/meta-freescale/commit/e1e51ebbe8f24f51cb501584e4566421a3a0f1e3 -->
  <project name="meta-freescale.git" path="layers/meta-freescale" remote="githf" revision="e1e51ebbe8f24f51cb501584e4566421a3a0f1e3" upstream="dunfell"/>
  
  <!-- meta-toradex-bsp-common: Branch dunfell-5.x.y -->
  <!-- https://git.toradex.com/cgit/meta-toradex-bsp-common.git/commit/?id=a3debcd429139019c528932b0436854349b4fb86 -->
  <project name="meta-toradex-bsp-common.git" path="layers/meta-toradex-bsp-common" remote="tdx" revision="a3debcd429139019c528932b0436854349b4fb86" upstream="dunfell-5.x.y"/>
  
  <!-- meta-toradex-nxp: Branch dunfell-5.x.y -->
  <!-- https://git.toradex.com/cgit/meta-toradex-nxp.git/commit/?id=d26fac8da30aa1e530f11178f85ea285d329d442 -->
  <project name="meta-toradex-nxp.git" path="layers/meta-toradex-nxp" remote="tdx" revision="d26fac8da30aa1e530f11178f85ea285d329d442" upstream="dunfell-5.x.y"/>
  
  <!-- meta-toradex-tegra: Branch dunfell-5.x.y -->
  <!-- https://git.toradex.com/cgit/meta-toradex-tegra.git/commit/?id=a03fde04d777cb3f9549d6fbf234924211c867c2 -->
  <project name="meta-toradex-tegra.git" path="layers/meta-toradex-tegra" remote="tdx" revision="a03fde04d777cb3f9549d6fbf234924211c867c2" upstream="dunfell-5.x.y"/>
  
  <!-- meta-qt5: Branch dunfell -->
  <!-- https://github.com/meta-qt5/meta-qt5/commit/b4d24d70aca75791902df5cd59a4f4a54aa4a125 -->
  <project name="meta-qt5.git" path="layers/meta-qt5" remote="githq" revision="b4d24d70aca75791902df5cd59a4f4a54aa4a125" upstream="dunfell"/>
  
  <!-- meta-toradex-demos: Branch dunfell-5.x.y -->
  <!-- https://git.toradex.com/cgit/meta-toradex-demos.git/commit/?id=eeaa1fa0f22496a84d42c2b54e4ae23b567b07f2 -->
  <project name="meta-toradex-demos.git" path="layers/meta-toradex-demos" remote="tdx" revision="eeaa1fa0f22496a84d42c2b54e4ae23b567b07f2" upstream="dunfell-5.x.y"/>
  
  <!-- meta-toradex-distro: Branch dunfell-5.x.y -->
  <!-- https://git.toradex.com/cgit/meta-toradex-distro.git/commit/?id=432c37ce55d3d5c03bd67d17348d1e667070f661 -->
  <project name="meta-toradex-distro.git" path="layers/meta-toradex-distro" remote="tdx" revision="432c37ce55d3d5c03bd67d17348d1e667070f661" upstream="dunfell-5.x.y"/>

ELB-2957 looks related, but I don’t think it cause our issue. For our use case, reg_usb_host_vbus is indeed always on (with regulator-always-on node in device tree) and we only want to use USBH2 and USBH3 (usbh1 node). We also tried to turn everything on (USBH2, USBH3 and USBH4) but still face the same hang issue when USB OTG is off.

We are disabling USB OTG because the control pins 274 (USBO1_EN) and 262 (USBO1_OC#) are being muxed as GPIO for other usage.

Thank you.

4

Hi @wilsonkoe

Thanks for sharing details.
We are checking at our end allow us some time to further comment on this.

Best Regards
Ritesh Kumar

5

Thanks for following up @ritesh.tx, we look forward to your response! Let us know if you need more information.

Thank you.

6

Hi @ritesh.tx,

How is everything going? Probing to see if you guys have found out anything. Do let us know if you need more details.

Thank you.

7

Hi @wilsonkoe,

Yes we are able to reproduce issue at our end. We have informed concerned team to look into this.
Meanwhile as a workaround please keep otg node enabled and simply remove the EN and OC pin from node. This way you can use those pins as GPIO.

diff --git a/arch/arm64/boot/dts/freescale/imx8-apalis-v1.1.dtsi b/arch/arm64/boot/dts/freescale/imx8-apalis-v1.1.dtsi
index b29414e70d2f..caddc48bb6b4 100644
--- a/arch/arm64/boot/dts/freescale/imx8-apalis-v1.1.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8-apalis-v1.1.dtsi
@@ -587,6 +587,8 @@
                pinctrl_gpio4: gpio4grp {
                        fsl,pins = <
                                IMX8QM_M41_GPIO0_01_LSIO_GPIO0_IO13             0x06000021
+                               IMX8QM_USB_SS3_TC0_LSIO_GPIO4_IO03              0x06000021
+                                IMX8QM_USB_SS3_TC2_LSIO_GPIO4_IO05              0x06000021
                        >;
                };
@@ -1013,9 +1015,9 @@
                pinctrl_usbotg1: usbotg1 {
                        fsl,pins = <
                                /* Apalis USBO1_EN */
-                               IMX8QM_USB_SS3_TC0_CONN_USB_OTG1_PWR            0x00000021
+                               //IMX8QM_USB_SS3_TC0_CONN_USB_OTG1_PWR          0x00000021
                                /* Apalis USBO1_OC# */
-                               IMX8QM_USB_SS3_TC2_CONN_USB_OTG1_OC             0x04000021
+                               //IMX8QM_USB_SS3_TC2_CONN_USB_OTG1_OC           0x04000021
                        >;
                };

Regarding issue once Rnd team take on this they will share the timeline for same and we can update you on this.

Let me know if this works for you.

Best Regards
Ritesh Kumar

8

Dear @ritesh.tx,

Thanks for the workaround recommendation. It allows the EN and OC pins to be used as GPIO but we realized USBH is still unusable. We hope to hear from your engineering team soon. We wish to use EN and OC pins as GPIO without compromising USBH.

Thank you.

9

Hi @ritesh.tx,

It’s been a while, do you have any updates/solutions regarding the issue other than the proposed workaround? We are still hoping to be able to use EN and OC pins as GPIO and USBH at the same time.

Thank you.

10

Hi @wilsonkoe,

Regarding the update the issue has been verified and corresponding ticket has been created. It should be taken by team as per the process Once issue verified by them it will be visible below link

Let me know about your timeline for same, if you need this urgently I would suggest to take paid hour support.

Regarding workaround and usbh not working please test below overlay.

/dts-v1/;
/plugin/;
/ {
compatible = “toradex,apalis-imx8”;
};

&usbotg1 {
status = “disabled”;
};

&usbh1 {
fsl,usbphy = <&usbphy1>;
};

Best Regards
Ritesh Kumar

1 Like
11

Hi @ritesh.tx,

Thanks for the workaround, we will test it at our end and share the result later. We will also continue to evaluate the urgency to see if an escalation is needed.

Thank you.