• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 913 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.

Linux/AM6548: Disabling PCIe0 disables USB0

Matthew McKee
Intellectual 926 points

Part Number: AM6548

Tool/software: Linux

Hello,

I am trying to debug an issue with USB0 on the AM654x EVM with SDK v5.02.00.10. If PCIe0 is enabled, USB0 works fine at USB2.0 speeds. If I disable PCIe0, USB0 ceases to work.with the following error message:

[   38.264599] usb usb1-port1: connect-debounce failed

I have narrowed this down to the serdes_am654_enable_pll() function in the phy-ti-am654.c Linux driver. If this function is commented out, USB0 stops working. If any pathway to this function is disabled, USB0 stops working. E.g., if I remove the serdes0 "phys" entry in k3-am654-pcie-usb2.dtso, the serdes0 phy is not registered and serdes_am654_power_on is not called which means serdes_am654_enable_pll is not called.

Is it possible for USB0 to work without PCIe0 being enabled? As far as I can tell, the clock configuration in k3-am6.dtsi should be enough to not have to rely upon the undocumented Wiz configuration registers, but it doesn't work.

Thanks,

Matt McKee

  • 0
    TI__Guru**** 170625 points

    Hi Matthew,

    AM65x EVM board is using serdes ref clock signals to supply USB0 (USB3.1), thus SERDES module should be enabled for USB0 to work properly. Refer to the EVM user guide for details:

    www.ti.com/.../spruim7.pdf

    Check also if below pointers will be in help:

    software-dl.ti.com/.../Foundational_Components_Kernel_Drivers.html

    e2e.ti.com/.../774510

    "Is it possible for USB0 to work without PCIe0 being enabled? "

    Yes, but SERDES should be enabled.

    WIZ_PLL_CTRL is SERDES0 PLL_CTRL register at full addr 0x00901FF4. For more details refer to AM65x TRM sections:

    12.2.4 Serializer/Deserializer (SerDes)

    12.2.4.5.156 PLL_CTRL Register (Offset = 1FF4h) [reset = X]



    Regards,
    Pavel

  • 0 in reply to Pavel Botev
    Intellectual 926 points

    Hi Pavel,

    Thank you for the response. I still don't understand what about the clock configuration requires USB0 to source its clocks from SERDES0. Table 12-4814 in the TRM "USBSS Clocks and Resets" indicates that USB3SS0 and USB2PHY0 are using Serdes clocks only in input USB3SS0 module input PIPE3_TXB_CLK which can be muxed between a SERDES0 source or a WKUP_RC_OSC_12M source. Figure 12-1780 in the TRM "USB3SS0 Integration" shows that the WKUP_RC_OSC_12M source to the PIPE3_TXB_CLK mux isn't sourced from SERDES0.

    In the same figure I do see USB0_REFCLKP/N being fed into SERDES0, but if that clock is necessary for USB2.0 operation then why is there no comparable clock input to the USB1 detailed in the TRM? The relevant DTS files configuring dwc3_0, usb0, and usb0_phy also indicate that the SERDES clock is not being used, unless the PIPE3_TXB_CLK input depends upon SERDES0 being enabled.

    Can you provide some more details?

    Thanks,

    Matt McKee

  • 0 in reply to Matthew McKee
    TI__Guru**** 170625 points
    Matthew,

    Only USB3SS0 (USB0) is using SERDES0, while USB3SS1 (USB1) is NOT using any SERDES module.

    Even if you use RC_OSC_12M for clock source of USB0 PIPE3_TXB_CLK clock (not SERDES0 module) you still need SERDES0 module enabled and functional. SERDES0 module is doing more things than just providing the PIPE3_TXB_CLK clock to USB0. SERDES0 is related to PIPE3 and VBUS operations.

    Regards,
    Pavel
  • 0 in reply to Pavel Botev
    Intellectual 926 points

    Hi Pavel,

    Thank you for that explanation. It's hard to tell from the documentation alone that USB0 has a dependency upon SERDES0 even in USB2.0 mode using USB2PHY0.

    Does TI have any plans for adapting the Linux USB driver(s) so that one could point it, via the device tree, to the serdes0 instance and have serdes0 configured properly for USB0 support? Just to reiterate: since PCIe0 is handling SERDES0 as its PHY, if PCIe0 is disabled in the device tree then USB0 stops working. Directing the USB driver to use serdes0 as its USB3 PHY doesn't solve this issue.

    Thanks,

    Matt McKee

  • 0 in reply to Matthew McKee
    TI__Mastermind 27890 points
    Matthew,
    I'm back from vacation and digging into this a bit more. I'll let you know what I find.
  • 0 in reply to Matthew McKee
    TI__Mastermind 27890 points

    Matthew,

    It appears that this is possible as reports from the BOOTROM and RTOS teams show it to be working. It may be a Linux-induced artifact and is in active debug.

    As a temporary work-around, could you try manually switching the lane function to PCIe (or SGMII) with SERDES0 disabled? Set CTRLMMR_SERDES0_CTRL.LANE_FUNC_SEL = 1. From the Linux shell this is 'devmem2 0x104080h w 1'

    -DK

  • 0 in reply to -DK-
    Intellectual 926 points

    DK,

    That worked and with that suggestion I was able to put together a more permanent solution.

    Thanks!