T2080 Hangs during USB scan in U-Boot

[vladimirboroda]

The custom T2080-based board with u-boot-qoriq 2017.09 hangs solidly when I am attempting to run "usb start".   Sometimes it hangs on USB0, but if not there, then definitely on USB1.

USB0:   USB EHCI 1.00
scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80
unable to get device descriptor (error=-1)
1 USB Device(s) found
USB1:   USB EHCI 1.00
scanning bus 1 for devices...

If nothing is plugged into USB0, u-boot always hangs on USB1, which connects the CPU to a eMMC via an embedded USB hub.

When trying to debug the issue, I got it down to enabling the Async Schedule in ehci_submit_async() in ehci-hcd.c:

        usbsts = ehci_readl(&ctrl->hcor->or_usbsts);
        ehci_writel(&ctrl->hcor->or_usbsts, (usbsts & 0x3f));

        /* Enable async. schedule. */
        cmd = ehci_readl(&ctrl->hcor->or_usbcmd);
        cmd |= CMD_ASE;
        ehci_writel(&ctrl->hcor->or_usbcmd, cmd); <- Hung here!

        ret = handshake((uint32_t *)&ctrl->hcor->or_usbsts <...>

The system doesn't hang every time it goes through this logic, but it is always hung on the second or third time the ehci_submit_async() function is called.  The 24 MHz reference clock to USB seems solid. 

[vladimirboroda]

Pavel,

There was no schematic error, as far as we could see.  Seems that there is a major problem with dcache in U-Boot, which is basically left unsolved.  See the series of commits for arch/powerpc/lib/ppccache.S - the cache flushing support for MPX85XX was enabled, then disabled, then enabled again.  It appears that the authors of these patches do not realize the impact on other platforms, and on other hardware configurations.  When I tried to use the U-Boot with the flash_dcache_range enabled, the P1021-based product would just hang in MMC SPL boot. So I disabled it, and on the T2080-based product the USB stopped working.   However, when I re-enabled these functions just for the T2080, the U-Boot would not complete booting, with things seeming starting to fall apart around the Network interfaces configuration, when the malloc() functions suddenly all fail.  I suspect that the event occurs somewhere at the point when the FMAN microcode is read from MMC. 

So I ended up enabling the flush/invalidate_dcache_range just for the USB scan, which is a crazy hack, but I have not found any other way to solve this issue globally.  I suspect the dcache is not working properly for T2080, and we might be better off disabling it altogether.  Or all the drivers need to be fixed to support it.   Our configuration seems to work when the dcache flushing is enabled to USB scan, and disabled for everything else. 

The other hack we had to do to get the external USB working on the T2080 board was to add a usb_pgood_delay=1000 to the environment.  The USB scan would miss most (but not all) flash drives unless this was added.

Thanks,

Vlad

[Pavel]

Perhaps hardware on your board produces this problem.

Compare the T2080RDB USB schematic and your board.

Have a great day,
Pavel Chubakov

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------