Odyssey STM32MP157C: Cannot activate full-speed USB OTG

Dear support team,

using Yocto images for the Odyssey STM32MP157C board built exactly according to the meta-st-odyssey instructions, I have problems to get USB OTG (for using the board as an USB client/peripheral) to run properly.

In order to enable USB OTG on the USB C port in addition to the two USB host ports, I tried to activate OTG in full-speed mode by changing the usbotg_hs-override in stm32mp157c-odyssey.dts to:

&usbotg_hs {
        compatible = "st,stm32mp15-fsotg", "snps,dwc2";
        pinctrl-names = "default";
        /* configure OTG ID and full-speed data pins */
        pinctrl-0 = <&usbotg_hs_pins_a &usbotg_fs_dp_dm_pins_a>;
        dr_mode = "peripheral";
//      vbus-supply = <&vbus_otg>;
        status = "okay";
};

This is according to the instructions in the STM32 wiki.
vbus-supply shouldn’t be necessary since dr_mode = "peripheral", but I also tried to enable it without any luck.

The kernel log contains the following:

# uname -a
Linux stm32mp1 5.10.10 #1 SMP PREEMPT Sat Jan 23 15:04:06 UTC 2021 armv7l armv7l armv7l GNU/Linux
# dmesg | grep -i 'usb\|otg'
[    0.116607] usbcore: registered new interface driver usbfs
[    0.116698] usbcore: registered new interface driver hub
[    0.116775] usbcore: registered new device driver usb
[    1.597671] usb33: supplied by regulator-dummy
[    1.651070] pegasus: v0.9.3 (2013/04/25), Pegasus/Pegasus II USB Ethernet driver
[    1.651170] usbcore: registered new interface driver pegasus
[    1.651256] usbcore: registered new interface driver asix
[    1.651322] usbcore: registered new interface driver ax88179_178a
[    1.651404] usbcore: registered new interface driver cdc_ether
[    1.651489] usbcore: registered new interface driver smsc75xx
[    1.651572] usbcore: registered new interface driver smsc95xx
[    1.651638] usbcore: registered new interface driver net1080
[    1.651702] usbcore: registered new interface driver cdc_subset
[    1.651764] usbcore: registered new interface driver zaurus
[    1.652034] usbcore: registered new interface driver cdc_ncm
[    1.653206] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.653742] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    1.654665] usbcore: registered new interface driver usb-storage
[    1.666519] usbcore: registered new interface driver usbhid
[    1.666537] usbhid: USB HID core driver
[    3.033713] dwc2 49000000.usb-otg: supply vusb_d not found, using dummy regulator
[    3.040039] dwc2 49000000.usb-otg: supply vusb_a not found, using dummy regulator
[    3.059805] dwc2 49000000.usb-otg: dwc2_core_reset: HANG! Soft Reset timeout GRSTCTL_CSFTRST
[    3.067320] dwc2: probe of 49000000.usb-otg failed with error -16
[    3.215653] vdd_usb: supplied by vin
[    3.241790] vbus_otg: supplied by bst_out
[    3.367847] stm32-usbphyc 5a006000.usbphyc: registered rev:1.0
[    3.382950] ehci-platform 5800d000.usbh-ehci: EHCI Host Controller
[    3.391177] ehci-platform 5800d000.usbh-ehci: new USB bus registered, assigned bus number 1
[    3.406750] ehci-platform 5800d000.usbh-ehci: irq 59, io mem 0x5800d000
[    3.442739] ehci-platform 5800d000.usbh-ehci: USB 2.0 started, EHCI 1.00
[    3.451542] hub 1-0:1.0: USB hub found
[    3.465121] ohci-platform 5800c000.usbh-ohci: Generic Platform OHCI controller
[    3.470949] ohci-platform 5800c000.usbh-ohci: new USB bus registered, assigned bus number 2
[    3.496722] ohci-platform 5800c000.usbh-ohci: irq 52, io mem 0x5800c000
[    3.577692] hub 2-0:1.0: USB hub found

Unfortunately, there is not even an UDC controller in /sys/class/udc. As far as I understand this is because the dwc2 driver fails (“probe of 49000000.usb-otg failed with error -16”).
Creating USB gadgets via configfs subsequently cannot work.

Anybody knows how to fix this?

PS: Perhaps in a related matter, I cannot get both USB host ports to work even with an unmodified device tree. See also this ticket, which I created in meta-st-odyssey.

Following this. I’ll update w/progress as well.

BTW, I went to find the working device tree from the aforementioned debian image. It is here: linux/stm32mp1-seeed-npi-full.dts at stm32-4.19.y · Seeed-Studio/linux · GitHub

I compared to stm32mp157c-odyssey.dts (from yocto build) and there were some glaring differences. I’ve made changes to make it more similar and will report back on success/failure.

@Ben_Beckwith Did OTG work with the Debian image?

Yes, it worked for me. I have the 2nd USB port working (by changing the ehci/ohci entries to this to my .dts file):

&usbh_ehci {
phys = <&usbphyc_port0> , <&usbphyc_port1 1>;
phy-names=“usb”,“usb2”;
status = “okay”;
};

&usbh_ohci{
status = “okay”;
phy-names=“usb”,“usb2”;
phys = <&usbphyc_port0>, <&usbphyc_port1 1>;
};

I have the 2nd USB port working

Great to know you figured it out. I wrote a reply on the linked Github issue with all the details, not seeing you beat me to it by an hour here.

Which Debian image are you two talking about? I’m developing for a different device (custom SoM+MB) and I cannot directly use your images, I think. A link to the sources would be nice. I see a repo with kernel fork and device-trees, but what about the boot chain (TF-A, U-Boot)?

I have a feeling that TF-A and/or U-Boot maps my pins PA10/PA11/PA12 to I2C5 and I2C6 per my device trees, and then Linux pinctrl denies claiming then to USBOTG FS PHY, though gpio debug userspace tools say “Unclaimed”, ultimately leading to a USBOTG DWC2 core not leaving reset state.

I won’t be able to immediately test this by the end of the month, even though I have all the sources and Developer SDK installed. I only had time to rule out the M4 coprocessor core messing with my pin muxing by simply not loading its firmware before kernel boots.

1 Like

Thanks! That also fixes the second USB port for me. Did you figure out how to enable OTG with the newer stm32mp157c-odyssey.dts device tree? It still doesn’t work for me. I now get the following messages during bootup:

# dmesg | grep 'otg\|usb'
[    0.120414] usbcore: registered new interface driver usbfs
[    0.120508] usbcore: registered new interface driver hub
[    0.120588] usbcore: registered new device driver usb
[    1.844697] usb33: supplied by regulator-dummy
[    1.897352] usbcore: registered new interface driver pegasus
[    1.897438] usbcore: registered new interface driver asix
[    1.897504] usbcore: registered new interface driver ax88179_178a
[    1.897570] usbcore: registered new interface driver cdc_ether
[    1.897654] usbcore: registered new interface driver smsc75xx
[    1.897749] usbcore: registered new interface driver smsc95xx
[    1.897822] usbcore: registered new interface driver net1080
[    1.897888] usbcore: registered new interface driver cdc_subset
[    1.897951] usbcore: registered new interface driver zaurus
[    1.898045] usbcore: registered new interface driver cdc_ncm
[    1.900683] usbcore: registered new interface driver usb-storage
[    1.912861] usbcore: registered new interface driver usbhid
[    1.912881] usbhid: USB HID core driver
[    3.340515] dwc2 49000000.usb-otg: supply vusb_d not found, using dummy regulator
[    3.346946] dwc2 49000000.usb-otg: supply vusb_a not found, using dummy regulator
[    3.480623] vdd_usb: supplied by vin
[    3.506994] vbus_otg: supplied by bst_out
[    3.645858] stm32-usbphyc 5a006000.usbphyc: registered rev:1.0
[    3.655808] dwc2 49000000.usb-otg: supply vusb_d not found, using dummy regulator
[    3.662855] dwc2 49000000.usb-otg: supply vusb_a not found, using dummy regulator
[    3.830297] dwc2 49000000.usb-otg: failed to enable usb33d supply: -110
[    3.837818] dwc2: probe of 49000000.usb-otg failed with error -110
[    3.848106] ehci-platform 5800d000.usbh-ehci: EHCI Host Controller
[    3.852908] ehci-platform 5800d000.usbh-ehci: new USB bus registered, assigned bus number 1
[    3.861802] ehci-platform 5800d000.usbh-ehci: irq 62, io mem 0x5800d000
[    3.895454] ehci-platform 5800d000.usbh-ehci: USB 2.0 started, EHCI 1.00
[    3.910855] ohci-platform 5800c000.usbh-ohci: Generic Platform OHCI controller
[    3.916760] ohci-platform 5800c000.usbh-ohci: new USB bus registered, assigned bus number 2
[    3.925526] ohci-platform 5800c000.usbh-ohci: irq 52, io mem 0x5800c000
[   34.395441] usb33: disabling

Thanks. The pin allocation is a good lead.

This is what I get from dmesg grepping for otg:
[ 1.931352] dwc2 49000000.usb-otg: supply vusb_d not found, using dummy regulator
[ 1.931637] dwc2 49000000.usb-otg: supply vusb_a not found, using dummy regulator
[ 2.032841] vbus_otg: supplied by bst_out
[ 2.119148] dwc2 49000000.usb-otg: supply vusb_d not found, using dummy regulator
[ 2.119504] dwc2 49000000.usb-otg: supply vusb_a not found, using dummy regulator
[ 2.122645] dwc2 49000000.usb-otg: EPs: 9, dedicated fifos, 952 entries in SPRAM

Curious i don’t get the probe error. Maybe it isn’t probing?

Do you have something in /sys/class/udc?

I do now after implementing what @altracer recommended on the Seeed github ticket:

However, I get the following from dmesg:
[ 1.931551] dwc2 49000000.usb-otg: supply vusb_d not found, using dummy regulator
[ 1.931839] dwc2 49000000.usb-otg: supply vusb_a not found, using dummy regulator
[ 2.032266] vbus_otg: supplied by bst_out
[ 2.116406] dwc2 49000000.usb-otg: supply vusb_d not found, using dummy regulator
[ 2.116708] dwc2 49000000.usb-otg: supply vusb_a not found, using dummy regulator
[ 2.244131] dwc2 49000000.usb-otg: EPs: 9, dedicated fifos, 952 entries in SPRAM
[ 2.245269] dwc2 49000000.usb-otg: DWC OTG Controller
[ 2.245326] dwc2 49000000.usb-otg: new USB bus registered, assigned bus number 1
[ 2.245396] dwc2 49000000.usb-otg: irq 57, io mem 0x49000000
[ 2.245421] dwc2 49000000.usb-otg: invalid fifo sizes

“Invalid fifo sizes” is troublesome, but the rest is promising.

I corrected the “compatible” string from “stm32mp1” to “stm32mp15” in the .dts file like so:

&usbotg_hs {
compatible = “st, stm32mp15-fsotg”, “snps,dwc2”;
pinctrl-names = “default”;
pinctrl-0 = <&usbotg_hs_pins_a &usbotg_fs_dp_dm_pins_a>;
vbus-supply = <&vbus_otg>;
dr_mode = “otg”;
status = “okay”;
};

[ 3.830297] dwc2 49000000.usb-otg: failed to enable usb33d supply: -110

Do you have a proper regulator supply declared?
Check these commits from ST:

has usb33d-supply = <&usb33>;

@Ben_Beckwith Increase the USB OTG gadget EP FIFOs like this commit:

-			g-rx-fifo-size = <256>;
+			g-rx-fifo-size = <512>;
			g-np-tx-fifo-size = <32>;
-			g-tx-fifo-size = <128 128 64 64 64 64 32 32>;
+			g-tx-fifo-size = <256 16 16 16 16 16 16 16>;

Maybe it’s easier to directly use ST’s kernel fork not mainline, or at least apply the 20 unified patches from their Developer SDK for OpenSTLinux ecosystem.

Yes, this patch is already applied. I am usually using the meta-st-stm32mp hardknott-branch.

this is now my .dts:
&usbotg_hs {
pinctrl-names = “default”;
pinctrl-0 = <&usbotg_hs_pins_a &usbotg_fs_dp_dm_pins_a>;
vbus-supply = <&vbus_otg>;
usb-role-switch;
status = “okay”;
};

dmesg output:

dmesg |grep otg

[ 1.941851] dwc2 49000000.usb-otg: supply vusb_d not found, using dummy regulator
[ 1.942155] dwc2 49000000.usb-otg: supply vusb_a not found, using dummy regulator
[ 2.043179] vbus_otg: supplied by bst_out
[ 2.128365] dwc2 49000000.usb-otg: supply vusb_d not found, using dummy regulator
[ 2.128707] dwc2 49000000.usb-otg: supply vusb_a not found, using dummy regulator
[ 2.264131] dwc2 49000000.usb-otg: EPs: 9, dedicated fifos, 952 entries in SPRAM
[ 2.264851] dwc2 49000000.usb-otg: DWC OTG Controller
[ 2.264905] dwc2 49000000.usb-otg: new USB bus registered, assigned bus number 1
[ 2.264975] dwc2 49000000.usb-otg: irq 57, io mem 0x49000000

No luck getting a hub or any other device connected. :frowning:

These are my ST layers;
meta-st-odyssey = master:9c7bedd1fc343de3ddda2adc0ee1ef82c509c40c
meta-st-openstlinux = HEAD:d6947f5a1898744aa15a96b68e8945f4f553175e
meta-st-stm32mp = HEAD:7b55c34159fcfd57b4965f7aa9284200eea09d20
meta-st-stm32mp-addons = HEAD:81065195a63e98be8f423ab422960e9d7896f4d5

Can you point me to these patches please?

Thanks,
Ben

Good.

I rebuilt the kernel with two copies of dwc2.ko, one stock and one with the ST patch regarding PHYSEL. The unpatched one always fails probing, the patched one always works. I did modprobe/modprobe -r experiments without rebooting on the same device. I think I even tried it on STM32MP157D-DK1 kit.

It had nothing to do with TF-A BL2 or U-Boot or even coprocessor firmware, although it was nice to revisit these sources. Your device should work now as well.

However, both the DK1 and our device has nasty pull-ups on I2C5 (and I2C6), so it shows +3.3V on USB D+ and D- when I hook up an oscilloscope and a STM32F072B-Disco board by its’ PA11/PA12 to the pins. So I cannot confirm operation either.

You can poke around the debugfs, try forcing host/peripheral mode, monitor the OTG_ID (or disable it) and Vbus_sense, if it’s relevant, to actually use the type-C port. There are adapters type-C/type-A, if you wanted to connect a third peripheral FS device to STM32MP1 as host.

Feel free to mention me if I can help you with anything, without me having the NPi device.

Great, thanks for this! I will try it out and report back.

Cheers,

Ben

BTW, can you point to that patch please?

Any chance you can point me to the PHYSEL patch?

Thanks,
Ben

I linked to that patch from ST forums in the Github issue in my first post. You might have seen it.

Once again, anyways: ST Community

Cut the plaintext diff and git apply from Kernel source root dir, or even paste the code block manually, cutting the plus signs.