DRA722: USB Gadget Driver: Host not able to enumerate the board

Hi Krishna,

Can you share the kernel logs generated when performing the above steps?

We see that usb@488d0000 is being used for the test, so can run below share the output log:

-1- With the otg cable connected b/n the board and the PC

lsusb
cat /sys/kernel/debug/488d0000.usb/mode
modprobe g_zero
cat /sys/kernel/debug/488d0000.usb/mode

-2- Run the same without connecting the cable.

Thanks

Hi Praveen,

Please find below the logs:

Scenario 1 (Not Working)

Description=> OTG cable connected to USB2 and then boot the board. Board will boot in host mode. Please note, the other side of OTG cable is not connected anywhere.

dra7xx-evm login: root
root@dra7xx-evm:~# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@dra7xx-evm:~#                                        
root@dra7xx-evm:~#
root@dra7xx-evm:~# cat /sys/kernel/debug/488d0000.usb/mode
host
root@dra7xx-evm:~#
root@dra7xx-evm:~#
root@dra7xx-evm:~# modprobe g_zero
[   66.312609] udc-core: couldn't find an available UDC - added [zero] to list of pending drivers
root@dra7xx-evm:~#
root@dra7xx-evm:~#
root@dra7xx-evm:~# cat /sys/kernel/debug/488d0000.usb/mode
host
root@dra7xx-evm:~#
root@dra7xx-evm:~#
root@dra7xx-evm:~# echo device > /sys/kernel/debug/488d0000.usb/mode
root@dra7xx-evm:~# [  106.657766] xhci-hcd xhci-hcd.2.auto: remove, state 4
[  106.664387] usb usb4: USB disconnect, device number 1
[  106.675228] xhci-hcd xhci-hcd.2.auto: USB bus 4 deregistered
[  106.687375] xhci-hcd xhci-hcd.2.auto: remove, state 4
[  106.692475] usb usb3: USB disconnect, device number 1
[  106.706557] xhci-hcd xhci-hcd.2.auto: USB bus 3 deregistered
[  106.733387] zero gadget: Gadget Zero, version: Cinco de Mayo 2008
[  106.741648] zero gadget: zero ready

root@dra7xx-evm:~#
root@dra7xx-evm:~#
root@dra7xx-evm:~#
root@dra7xx-evm:~#
root@dra7xx-evm:~#
root@dra7xx-evm:~#
root@dra7xx-evm:~# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@dra7xx-evm:~#

Now remove the OTG cable and connect the board to a PC with a normal micro USB cable. PC will not be able to detect any USB device. There is no kernel log coming on the board after connecting it to PC.

Scenario 2 (Working)

Description=> Boot the board with no cable connected to the USB2. The board will boot in device mode. Load the USB gadget driver and connect the board to PC with a normal micro USB cable.

dra7xx-evm login: root
root@dra7xx-evm:~# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@dra7xx-evm:~#
root@dra7xx-evm:~#
root@dra7xx-evm:~# cat /sys/kernel/debug/488d0000.usb/mode
device
root@dra7xx-evm:~#
root@dra7xx-evm:~#
root@dra7xx-evm:~# modprobe g_zero
[   50.055968] zero gadget: Gadget Zero, version: Cinco de Mayo 2008
[   50.064767] zero gadget: zero ready
root@dra7xx-evm:~#
root@dra7xx-evm:~#
root@dra7xx-evm:~# cat /sys/kernel/debug/488d0000.usb/mode
device
root@dra7xx-evm:~#
root@dra7xx-evm:~#

*************** After connecting the board to my PC ********************

root@dra7xx-evm:~# [   71.956415] zero gadget: high-speed config #3: source/sink

root@dra7xx-evm:~#

In this case (Scenario 2), my PC detects the USB device. lsusb output from my PC: Bus 001 Device 052: ID 0525:a4a0 Netchip Technology, Inc. Linux-USB "Gadget Zero"

Please note, USB1 (usb@48890000) is configured in host mode. Only USB2 (usb@488d0000) is configured in otg mode. So all gadget driver loaded will bind itself to USB2.

Regards,

Krishna

Hi Krishna,

Thanks for the logs.

It is clear why 

> Now remove the OTG cable and connect the board to a PC with a normal micro USB cable.

Can you tell me what is the difference b/n the OTG cable and the normal micro USB cable? Can you share the details of both these cable and if possible the photos of the same.

For scenario 1, Looks like the connected OTG cable is causing the USB driver to switch to host mode. So it means that the ID pin is ground by the OTG cable connected. So when you force a device switch, it seems the driver is switching to device mode, but it looks like there is some issue and it has not fully switched to device mode.

For scenario 2, with the cables connected, I would have expected the board to be in the "otg" mode after bootup and we are not sure why it in "device" mode. So can you share the DTS file you are using or can you provide the log after running:

cat /sys/firmware/devicetree/base/ocp/omap_dwc3_2@488c0000/usb@488d0000/dr_mode

lsmod

Hi Praveen,

=> Can you tell me what is the difference b/n the OTG cable and the normal micro USB cable? Can you share the details of both these cable and if possible the photos of the same.

•   
• Left One: Regular mini-USB cable; Right One: OTG cable

=>For scenario 1, Looks like the connected OTG cable is causing the USB driver to switch to host mode. So it means that the ID pin is ground by the OTG cable connected. So when you force a device switch, it seems the driver is switching to device mode, but it looks like there is some issue and it has not fully switched to device mode.

• Yes. For our use case, we need the the device to switch the USB role properly with the OTG cable connected. This was working fine in older Processor SDK (3.00.00.03).

I will share the device tree details and corresponding logs soon.

Regards,

Krishna

Hi Praveen,

I am not sure if the attached pictures are visible. At least I cannot see them. Sharing amazon link for your reference.

OTG cable : https://www.amazon.in/Mini-USB-Cable-Digital-Cameras/dp/B07MXXL3MR/ref=sr_1_35?dchild=1&keywords=mini+otg+cable&qid=1596042640&sr=8-35

Regular mini USB cable: https://www.amazon.in/AmazonBasics-USB-2-0-Cable-Male/dp/B00NH13S44/ref=sr_1_4?dchild=1&keywords=mini+usb+cable&qid=1596042822&sr=8-4

Regards,

Krishna

Hi Praveen,

=>cat /sys/firmware/devicetree/base/ocp/omap_dwc3_2@488c0000/usb@488d0000/dr_mode

otg

=>lsmod

Module                  Size  Used by
xfrm_user              36864  2
xfrm4_tunnel           16384  0
ipcomp                 16384  0
xfrm_ipcomp            16384  1 ipcomp
esp4                   20480  0
ah4                    16384  0
af_key                 36864  0
xfrm_algo              16384  5 xfrm_user,esp4,ah4,af_key,xfrm_ipcomp
usb_f_ncm              20480  1
g_ncm                  16384  0
u_ether                20480  2 g_ncm,usb_f_ncm
libcomposite           53248  2 g_ncm,usb_f_ncm
xhci_plat_hcd          16384  0
xhci_hcd              143360  1 xhci_plat_hcd
usbcore               217088  2 xhci_plat_hcd,xhci_hcd
dwc3                   73728  0
udc_core               28672  4 usb_f_ncm,u_ether,libcomposite,dwc3
usb_common             16384  4 udc_core,libcomposite,usbcore,dwc3
rpmsg_rpc              32768  0
extcon_usb_gpio        16384  0
snd_soc_omap_hdmi      16384  0
pvrsrvkm              405504  2
c_can_platform         16384  0
c_can                  20480  1 c_can_platform
omap_aes_driver        24576  0
omap_sham              28672  0
can_dev                28672  1 c_can
omap_wdt               16384  0
ahci_platform          16384  0
libahci_platform       20480  1 ahci_platform
libahci                36864  2 ahci_platform,libahci_platform
libata                208896  3 ahci_platform,libahci_platform,libahci
phy_omap_usb2          16384  4
ti_vip                 49152  0
ti_vpe                 28672  0
ti_sc                  36864  2 ti_vpe,ti_vip
ti_csc                 16384  2 ti_vpe,ti_vip
ti_vpdma               24576  2 ti_vpe,ti_vip
dwc3_omap              16384  0
rtc_omap               20480  1
ti_cal                 36864  0
ov1063x                24576  0
ov490                  16384  0
omap_hdq               16384  0
v4l2_fwnode            20480  3 ov490,ti_cal,ti_vip
omap_des               20480  0
wire                   32768  1 omap_hdq
des_generic            28672  1 omap_des
crypto_engine          16384  2 omap_des,omap_aes_driver
omap_crypto            16384  2 omap_des,omap_aes_driver
omap_remoteproc        20480  0
virtio_rpmsg_bus       20480  0
remoteproc             49152  2 rpmsg_rpc,omap_remoteproc
sch_fq_codel           20480  4

Also, find the diff of "dra72-evm-common.dtsi" dts file

diff --git a/arch/arm/boot/dts/dra72-evm-common.dtsi b/arch/arm/boot/dts/dra72-evm-common.dtsi
index 81d778a2abd4..3b7ebdb02f14 100644
--- a/arch/arm/boot/dts/dra72-evm-common.dtsi
+++ b/arch/arm/boot/dts/dra72-evm-common.dtsi
@@ -443,12 +443,12 @@
 };
 
 &usb1 {
-       dr_mode = "otg";
+       dr_mode = "host";
        extcon = <&extcon_usb1>;
 };
 
 &usb2 {
-       dr_mode = "host";
+       dr_mode = "otg";
        extcon = <&extcon_usb2>;
 };

Regards,

Krishna

Hi Krishna,

Looks at the links shared for the cables, now it is clear to us. We refer "otg cable" as the "usb otg adapter cable" and when this is connected to the USB port, the DRA7xx USB instance will always switch to the host mode.

The DTS entries look right. 

We will investigate further on our end to see why the host to device switch (senario1) is not getting the device mode to be enumerated by the PC. We will let us know.

Thanks.

Hi Praveen,

Do we have any update on this?

Adding further findings from my end.

Based on the register  dump, I see that the USBLNKST field of USB_DSTS register is in suspended state in the  working case (scenario 2) whereas in scenario 1, USB link state is in disconnected state. As per the TRM, changes in USB_DCTL register reflects in USB_DSTS register (all the fields in USB_DSTS register are read only). USB_DCTL register value in both the scenarios are same.

Regards,

Krishna

Hi Krishna,

We think there seems to be an issue with the USB role-switch implementation on the Processor SDK 6.00.00.03 release. There is no further development planned or a new release schedule on this platform. One suggestion is to go back one release older (link)and check to see if the same issue exists. 

Thanks.

Hi Krishna,

Any update on this. Did you try the older SDK release? Please let us know if the issue got resolved.

Thanks.

Hi Praveen,

We don't see any issue with SDK 3.00.00.03. For now we will go ahead with it.

Regards,

Krishna

Thanks for confirming. We will close this ticket.