I'm having problems gettting USB working in u-boot on our P5020 (2.0 silicon) board. This does not seem to be a hardware problem, as USB is working flawlessly in Linux.
Our u-boot is based on the sdk-v1.5x branch of the Freescale git tree. When I scan USB, my storage devices are detected correctly, but my USB mouse and keyboard only produce this error:
=> usb reset
USB0: USB EHCI 1.00
scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80
2 USB Device(s) found
USB1: USB EHCI 1.00
scanning bus 1 for devices... 2 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
According to u-boot the following erratum workarounds are already enabled:
Work-around for Erratum DDR-A003473 enabled
Work-around for Erratum ESDHC111 enabled
Work-around for Erratum DDR-A003 enabled
Work-around for Erratum A004510 enabled
Work-around for Erratum SRIO-A004034 enabled
Work-around for Erratum USB138 enabled
Work-around for Erratum ELBC MULTIBIT ECC enabled
Work-around for Erratum I2C-A004447 enabled
Work-around for Erratum A006261 enabled
Has anybody got USB keyboards working in u-boot on a P5020 or similar device?
I've made progress on this - the bug doesn't exist in the mainline u-boot code from Denx. As the master branch of u-boot seems to contain almost all the patches from the Freescale repository, I'm happy with this as a solution.
No problems in initial testing, but I'll probably port the A-005275 workaround in to my u-boot tree for broadest compatibility. What's the impact of A-005275 once Linux is running - does Linux have enough error recovery in the USB layer to ignore the problem?
I have one remaining issue, which I can work-around but not explain. Unless I add a delay in the place below, the USB keyboard driver sees spurious HID packets containing zeros in-between the genuine packets which encode the keypress state. As a result, it's impossible to type a single character without repeating. I have no logical explanation yet as to why this patch cures the problem, and I'm sure there's a much cleaner fix possible:
diff --git a/common/usb.c b/common/usb.c
index 60daa10..b9e2d05 100644
@@ -191,6 +191,7 @@ int usb_control_msg(struct usb_device *dev, unsigned int pipe,
debug("usb_control_msg: request: 0x%X, requesttype: 0x%X, " \
"value 0x%X index 0x%X length 0x%X\n",
request, requesttype, value, index, size);
dev->status = USB_ST_NOT_PROC; /*not yet processed */
if (submit_control_msg(dev, pipe, data, size, setup_packet) < 0)
Linux needs the workaround as well. The erratum is not seen on all instances of affected SoC types, so I wouldn't rely on testing alone to ensure that there isn't a problem.
SDK 1.5 does contain the normal u-boot USB keyboard driver at common/usb_kbd.c. Do you mean that the Freescale SDK does not support low-speed USB, and is that Freescale's official position?
I've found one bug in the USB driver here, but this isn't a complete fix, as USB probing is still unreliable after correcting this:
These lines force all endpoints to full speed, even if the device is a keyboard and only capable of low speed. Only QH_HIGH_SPEED devices should be slowed to QH_FULL_SPEED:
+ /* Force FS for fsl HS quirk */
+ if (!ctrl->has_fsl_erratum_a005275)
+ endpt |= QH_ENDPT1_EPS(ehci_encode_speed(dev->speed));
+ endpt |= QH_ENDPT1_EPS(ehci_encode_speed(QH_FULL_SPEED));