USB keyboard in U-Boot on P5020

[adriancox]

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

(Re)start USB...

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:

=> errata

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?

[adriancox]

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.

[scottwood]

I don't think mainline U-Boot currently has any workaround for A-005275, so you may run into problems if you attach a high-speed device.

[adriancox]

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

--- a/common/usb.c

+++ b/common/usb.c

@@ -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);

+       mdelay(10);

        dev->status = USB_ST_NOT_PROC; /*not yet processed */

        if (submit_control_msg(dev, pipe, data, size, setup_packet) < 0)

[scottwood]

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.

[scottwood]

I don't think that is Freescale's official position.  I've submitted a bug report internally.

[yipingwang]

SDK 1.5 u-boot doesn't provide HID USB driver, probably you could download a related patch from open source, apply it to u-boot source code and rebuild u-boot.

[adriancox]

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:

sdk/u-boot.git - Freescale PowerPC u-boot Tree

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));

+ else

+ endpt |= QH_ENDPT1_EPS(ehci_encode_speed(QH_FULL_SPEED));