• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 834 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OMAP4430: Trouble setting up USB EHCI Port 2 with external ULPI PHY

Matt Thomas2
Prodigy 60 points

Hello,

We are using an OMAP4430 and have successfully used the OMAP's first USB host controller device in EHCI mode by hooking up the ULPI bus to an external SMSC 3320 transceiver. We know this is working because downstream hub and devices can be detected.

We have the second usbb2 ulpi connected to a second SMSC 3320 transceiver. However the second USB host controller device (ie "root hub") does not enumerate in Linux. We tinkered with the second USB3320 transceiver, checking it's clock and resets and it seems ok. That got us thinking that the OMAP isn't initialized properly, especially since we don't see a second root controller get enumerated in the dmesg logs, so I am wondering if it is not enabled somehow.

I am using Linux 3.4 with a BSP from our vendor Phytec. I posted a similar question in their forums, and am still waiting for a response. In case this is an OMAP initialization problem I wanted to try posting over here as well

I setup the OMAP mux pads for usbb1 and usbb2 ehci phy operation. In the board file:
    struct usbhs_omap_platform_data {
        .port_mode[0] = OMAP_EHCI_PORT_MODE_PHY;
        .port_mode[1] = OMAP_EHCI_PORT_MODE_PHY;
    }

This is similar to what is done on many other boards.

http://lxr.free-electrons.com/source/arch/arm/mach-omap2/board-omap4panda.c#L160

This doesn't seem to activate a second root hub, however. When loading the ehci_hcd driver, only 1 root port is enumerated. A second EHCI controller and bus should show up in Linux, correct? I am using dmesg, lsusb, and /proc/bus/usb to determine what devices have been detected so far. I only get messages describing one host controller/bus (with 3 ports):

    [    3.520000] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
    [    3.520000] ehci-platform: EHCI generic platform driver
    [    3.530000] ehci-platform ehci-platform: EHCI Host Controller
    [    3.530000] ehci-platform ehci-platform: new USB bus registered, assigned bus number 1

I have also used debugfs to look at the modes of the mux pads for usbb2 (cat /sys/kernel/debug/omap_mux/usbb2_ulpi*) and they are all in mode1, which is correct according to the TRM. (usbb1 is in mode4, which is also correct according to the TRM).

Is there something I'm missing? I have been studying the TRM but cannot find what I am missing. Perhaps I need to set the OMAP's second usb host controller to be an ehci device instead of ohci? I wonder about this since when I load ohci_hcd, Linux detects a second host controller as an ohci port. That doesn't really work for me as this needs to be an EHCI bus over the external ULPI PHY.

Thanks for any help!

  • 0
    Prodigy 60 points

    We solved this problem internally.

    The main issue was the clock from our USB transceiver (SMSC 3320) was not properly routed to the usbb2_ulpiphy_clk signal on the OMAP. Our vendor's system-on-module (Phytec) had a jumper that needed to be changed.

    The secondary issue was making sure the OMAP's mux pads were in the right configuration. Using the debugfs omap_mux directory was helpful in identifying a problem with the mux configuration. There was a problem in usb-host.c in an older version of linux where the mux mode was set incorrectly.

  • 0 in reply to Matt Thomas2
    Prodigy 250 points

    This is the same exact problem I'm having in my OMAP4470 and SMSC3320! Difference is, I am sure that I have properly routed the REFCLK clock from SMSC3320 to USBB2_ULPIPHY_CLK signal on OMAP.

    I am also sure that I had the right OMAP's mux pads configuration, as I copied Pandaboard's working config for its USB3320.

    I also did correct some usb-host mux modes.

    Even after all this, I can't detect the USB (no controller just like how you checked, also, I've been monitoring via /sys/kernel/debug/usb/devices).

    Can you inform me what mux modes you used for USB2, and which files did you set it? What fref_clk*_out did you use for your USB 2?

    Also, what other modifications did you have to do in usb-host.c which are not mux-related?

    My original post is here btw:

    http://e2e.ti.com/support/omap/f/849/p/313537/1105395.aspx

    Thank you in advance!

  • 0 in reply to Maggie Roxas
    Prodigy 60 points

    Maggie,

    I posted a reply over in your original thread. Some more notes:

    We didn't use fref_clk from the OMAP. We generated the 3320 transceiver's clock externally.

    The problems with bus 2 in usb-host.c were specific to a branch of the kernel I had (around 3.0 or 3.2). Basically it was not setting the pin mux correctly for bus 2. But you can rule this out quickly using debugfs and the omap_mux directory. No amount of screwing around with the board files will beat a runtime examination of the OMAP registers, made possible and easy because of debugfs and the omap_mux node.