Hello! I own a D-Link DBT-120 Bluetooth Adapter, which has a CSR firmware running in a so called “HID proxy mode”. This firmware pretends to be a USB keyboard (and mouse) and thus allows to use a Bluetooth keyboard in U-Boot.
Unfortunately it acts as a low-speed device and there seems to be some well known troubles about low-speed USB keyboards. There is a FAQ entry for openSUSE about this: https://en.opensuse.org/HCL:Raspberry_Pi3#I_cannot_use_keyboard_in_U-Boot_and_Grub_but_it_works_in_Linux I spend some effort to solve this issue. There are three tiny changes to get my Bluetooth keyboard working reliably as a low-speed USB keyboard. Sometimes the Bluetooth adapter needs a bit longer to power on and send its descriptor. As I use a Raspberry Pi 3b, I modified include/configs/rpi.h to add "usb_pgood_delay=100\0" to the CONFIG_EXTRA_ENV_SETTINGS define. However this is actually not a necessary change, even without it, most of the time there is no issue. Then the Bluetooth adapter needs one millisecond delay before accepting a new address, to avoid the error “USB device not accepting new address”. This is in common/usb.c at line 1047: https://github.com/u-boot/u-boot/blob/master/common/usb.c#L1047 dev->devnum = addr; mdelay(1); err = usb_set_address(dev); /* set address */ And finally, assuming the use of CONFIG_SYS_USB_EVENT_POLL=y (which is the default), in common/usb_kbd.c at line 520 this first interrupt IN message must not be send: https://github.com/u-boot/u-boot/blob/master/common/usb_kbd.c#L520 if (usb_int_msg(dev, data->intpipe, data->new, data->intpktsize, data->intinterval, false) < 0) { #endif printf("Failed to get keyboard state from device %04x:%04x\n", dev->descriptor.idVendor, dev->descriptor.idProduct); /* Abort, we don't want to use that non-functional keyboard. */ return 0; } Due to the #if stuff around, its a bit ugly. I solved it simply by modifying the if-statement in line 520: if (0) { With these two fixes my keyboard is working reliably. There is no need to press a key upfront and no error message any longer, as described for openSUSE. A chain-loaded GRUB-EFI is always usable now. I’m pretty sure that these changes will solve the issues for other low-speed USB keyboards as well. However, with that first interrupt IN message still sent, it seemed to me that there was a NYET loop in chunk_msg() in drivers/usb/host/dwc.c once complete_split got set. I guessed that “done += actual_len;” happens to often and possibly to early for an unfinished split transaction. With the recent fix 9dcab2c4d2cb50ab1864c818b82a72393c160236 introducing the nonblock argument, a split transfer gets restarted at a higher level, once there were to many NYET responses. But for this first interrupt IN message this nonblock argument is set to false, and in _submit_int_msg() we run into the timeout. If I understand it correctly, once a NYET message is received, it may take up to a millisecond before a response from a low-speed device is received (one low-speed frame). And a high-speed host has a frame length of 125 ms. That means that it can take up to 8 high-speed frames before a response from a low-speed device is received. Bit chunk_msg() returns already after > 4 high-speed frames. I would expect to wait at least 8 frames. The check after that first interrupt IN message got added by 5da2dc9789abecb1b018beb0c93f4c38c2985bc6 to workaround non-working keyboards. My suggested change will kind of revert that workaround. So there is some trade-off. Stefan
