PROCESSOR-SDK-AM62X: USB initialization issue

Hi Libor,

Please attach the USB0 section of your board schematics, showing all the connections from AM62x USB0 port to the USB receptable.

Please show the USB0 DT setting in your kernel device tree file.

Hi Bin,

USB0_D_P/N are connected directly to USB 2.0 connector. So VBUS is +5V.

USB0_VBUSSNS is connected to VBUS via 20k, so there is resistor divider 20k to VBUS, 10k to GND (R481).

USB0_DRVVBUS is connected to USB power switch (EN pin).

USB1 signals have no other connections than the resistors R36, R37.

The USB setting in kernel device tree is:

&usb0 {
        dr_mode = "host";
        pinctrl-names = "default";
        pinctrl-0 = <&main_usb0_pins_default>;
};

 &usbss0 {
        ti,vbus-divider;
};

main_usb0_pins_default: main-usb0-pins-default {
                pinctrl-single,pins = <
                        AM62X_IOPAD(0x0254, PIN_OUTPUT, 0) /* (C20) USB0_DRVVBUS */
>;
        };

Also, we measured USB signal integrity, voltage swing could be a bit bigger but the result is pass.

Hi Libor,

My apologies for the late response. I started to review the kernel code to understand where this '-110' error come from and look into from there.

I know the SK-AM62 board USB0 is type-C, but have you tried to replicate the issue on SK-AM62 EVM?

Hi Libor,

Can you please add '#define DEBUG' in the very beginning of drivers/usb/host/xhci.c, before all the header files, rebuild the kernel and attach the failure log? I'd like to get an idea where the ETIMEDOUT happened.

Hi Bin,

we have not tried EVM, if SW version 08.05.00.21 is used then we've had this issue only if no device in USB, EVM board (PROC114E1) has USB hub on USB0. So I just removed the hub and we are going to test it. I'll let you know.

Hi Bin,

we know where it happened but we will try to repeat it and send you the failure log.

xhci_gen_setup() has section:

    /* Reset the internal HC memory state and registers. */
    retval = xhci_reset(xhci, XHCI_RESET_LONG_USEC);
    if (retval)
        return retval;

where is xhci_reset call, and the section below is inside this call.

    xhci_dbg_trace(xhci, trace_xhci_dbg_init, "// Reset the HC");
    command = readl(&xhci->op_regs->command);
    command |= CMD_RESET;
    writel(command, &xhci->op_regs->command);

     /* Existing Intel xHCI controllers require a delay of 1 mS,
     * after setting the CMD_RESET bit, and before accessing any
     * HC registers. This allows the HC to complete the
     * reset operation and be ready for HC register access.
     * Without this delay, the subsequent HC register access,
     * may result in a system hang very rarely.
     */
    if (xhci->quirks & XHCI_INTEL_HOST)
        udelay(1000);

     ret = xhci_handshake(&xhci->op_regs->command, CMD_RESET, 0, timeout_us);
    if (ret)
        return ret;

The CMD_RESET is issued, but is never cleared, so the xhci_handshake ends after the timeout, 10s in this case. A power cycle is necessary to clear the CMD_RESET.

Hi Libor,

Thanks for the details, If you already know the ETIMEDOUT happens in xhci_handshake(), you don't have to capture the log again. I noticed this reset routine when reviewing the kernel code yesterday.

    if (xhci->quirks & XHCI_INTEL_HOST)
        udelay(1000);

This is a 1ms delay between setting CMD_RESET and clearing it, but only enabled when XHCI_INTEL_HOST quirk is set. Have you tried to add this delay in your case (by removing the 'if' line above) to see if this can solve the ETIMEDOUT problem?

Hi Bin,

we tried it but it didn't help.

Hi Libor,

Does your EVM board test have any result yet?

Hi Libor,

I am able to replicate the "can't setup: -110" issue on SK-AM62 (E2) within about 50 reboots. 

I will report it to our sw dev team to look into it.

Hi Bin,

we have tested EVM board where I removed USB hub, SW version 08.05, but it is running fine, so we have not been able to reproduce the issue yet.

Hi Bin,

it is great you are able to reproduce the issue. So we just wait for a feedback from TI dev team.

Hello Libor

We have reported the issue back to our SDK development team, since we were able to reproduce the issue. We currently do not have time lines on when this will be fixed as the issue still needs to be debugged and root caused. We will keep you posted on the progress. 

I heard that this severely impacting your development or production testing - if so- can you please elaborate further on the use-case on how you are using it etc?

Additionally from some offline communication I heard you maybe evaluating Ethernet Boot , if so, please be aware of the following errata

i2329 — MDIO: MDIO interface corruption (CPSW)

This may preclude you from using Ethernet Boot reliably

Regards

Mukul 

Hi Mukul,

we use USB just to bring up and run system on empty board. SW/FW is uploaded and then boot mode is switched to eMMC.

The idea is that we'll keep using USB boot for u-boot, then Linux will boot up from Ethernet. I believe we can apply the workaround for MDIO corruption issue in that case. We will try it..

Thanks a lot!

Best regards

Libor

Hi Bin,

we have successfully tested the patch, we have not been able to reproduce the issue on our board if patch is implemented. Thanks!

Best regards

Libor

Hi Libor,

I am glad the issue is resolved. Thanks for the update.