* Fixing low-speed USB keyboard detection
@ 2020-02-25 17:45 Stefan
2020-02-26 11:04 ` Soeren Moch
0 siblings, 1 reply; 6+ messages in thread
From: Stefan @ 2020-02-25 17:45 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Fixing low-speed USB keyboard detection
2020-02-25 17:45 Fixing low-speed USB keyboard detection Stefan
@ 2020-02-26 11:04 ` Soeren Moch
2020-02-28 23:46 ` Marek Vasut
0 siblings, 1 reply; 6+ messages in thread
From: Soeren Moch @ 2020-02-26 11:04 UTC (permalink / raw)
To: u-boot
Adding Marek as USB maintainer. Otherwise this non-patch-email may get
lost when sent to the mailing list only.
Soeren
On 25.02.20 18:45, Stefan wrote:
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Fixing low-speed USB keyboard detection
2020-02-26 11:04 ` Soeren Moch
@ 2020-02-28 23:46 ` Marek Vasut
2020-02-29 12:04 ` Soeren Moch
0 siblings, 1 reply; 6+ messages in thread
From: Marek Vasut @ 2020-02-28 23:46 UTC (permalink / raw)
To: u-boot
On 2/26/20 12:04 PM, Soeren Moch wrote:
> Adding Marek as USB maintainer. Otherwise this non-patch-email may get
> lost when sent to the mailing list only.
Well, can you send these as proper patches ?
> Soeren
>
> On 25.02.20 18:45, Stefan wrote:
>> 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.
[...]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Fixing low-speed USB keyboard detection
2020-02-28 23:46 ` Marek Vasut
@ 2020-02-29 12:04 ` Soeren Moch
2020-02-29 12:42 ` Stefan
0 siblings, 1 reply; 6+ messages in thread
From: Soeren Moch @ 2020-02-29 12:04 UTC (permalink / raw)
To: u-boot
On 29.02.20 00:46, Marek Vasut wrote:
> On 2/26/20 12:04 PM, Soeren Moch wrote:
>> Adding Marek as USB maintainer. Otherwise this non-patch-email may get
>> lost when sent to the mailing list only.
> Well, can you send these as proper patches ?
Well, I can try to make a proposal for patches. But I cannot test
something since I neither own such D-Link DBT-120 Bluetooth Adapter, nor
a Raspberry Pi 3b as host system. I'm also not familiar with the details
of event polling / interrupt message NYET handling in u-boot, so
probably will not come up with a good commit message about this. I also
cannot judge which workaround or revert of such is appropriate.
Stefan, can you convert your fixes to proper patches yourself, or do you
want me to send a first proposal?
Thanks,
Soeren
>
>> Soeren
>>
>> On 25.02.20 18:45, Stefan wrote:
>>> 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.
> [...]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Fixing low-speed USB keyboard detection
2020-02-29 12:04 ` Soeren Moch
@ 2020-02-29 12:42 ` Stefan
2020-03-01 17:46 ` Soeren Moch
0 siblings, 1 reply; 6+ messages in thread
From: Stefan @ 2020-02-29 12:42 UTC (permalink / raw)
To: u-boot
Hello Soeren!
It will take me some time to prepare a proper patch, I just found the documentation of your patman tool. I am using Guix and created a package definition for U-Boot with these three fixes using regexp substitutions.
My time is quite limited for this weekend. I guess that you would be much faster preparing these three simple changes as a patch. So I would be glad, if you prepare a patch.
A proper commit message could be this: ?This patch works around issues of low-speed USB keyboards with the dwc2 USB interface. There was a need to press a key when "USB0: scanning bus 0 for devices..." was printed or otherwise there was the error "Timeout poll on interrupt endpoint" and the keyboard was not usable. This patch reverts the workaround from 5da2dc9789abecb1b018beb0c93f4c38c2985bc6 for non-working keyboards.?
Stefan
> Am 29.02.2020 um 13:04 schrieb Soeren Moch <smoch@web.de>:
>
>
>
> On 29.02.20 00:46, Marek Vasut wrote:
>> On 2/26/20 12:04 PM, Soeren Moch wrote:
>>> Adding Marek as USB maintainer. Otherwise this non-patch-email may get
>>> lost when sent to the mailing list only.
>> Well, can you send these as proper patches ?
> Well, I can try to make a proposal for patches. But I cannot test
> something since I neither own such D-Link DBT-120 Bluetooth Adapter, nor
> a Raspberry Pi 3b as host system. I'm also not familiar with the details
> of event polling / interrupt message NYET handling in u-boot, so
> probably will not come up with a good commit message about this. I also
> cannot judge which workaround or revert of such is appropriate.
>
> Stefan, can you convert your fixes to proper patches yourself, or do you
> want me to send a first proposal?
>
> Thanks,
> Soeren
>>
>>> Soeren
>>>
>>> On 25.02.20 18:45, Stefan wrote:
>>>> 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.
>> [...]
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Fixing low-speed USB keyboard detection
2020-02-29 12:42 ` Stefan
@ 2020-03-01 17:46 ` Soeren Moch
0 siblings, 0 replies; 6+ messages in thread
From: Soeren Moch @ 2020-03-01 17:46 UTC (permalink / raw)
To: u-boot
Hi Stefan,
please do not top-post.
On 29.02.20 13:42, Stefan wrote:
> Hello Soeren!
>
> It will take me some time to prepare a proper patch, I just found the documentation of your patman tool. I am using Guix and created a package definition for U-Boot with these three fixes using regexp substitutions.
I never used these tools, just git and git-send-email. But maybe they
can be helpful for you.
> My time is quite limited for this weekend. I guess that you would be much faster preparing these three simple changes as a patch. So I would be glad, if you prepare a patch.
If you are not familiar with the u-boot patch submitting procedure, and
want to learn how to do it properly, then I'm happy to help.
If you just have no time to do it right, I certainly have better things
to do on _my_ weekend than writing patches for bugs that I don't see on
hardware I do not own, sorry.
> A proper commit message could be this: ?This patch works around issues of low-speed USB keyboards with the dwc2 USB interface. There was a need to press a key when "USB0: scanning bus 0 for devices..." was printed or otherwise there was the error "Timeout poll on interrupt endpoint" and the keyboard was not usable. This patch reverts the workaround from 5da2dc9789abecb1b018beb0c93f4c38c2985bc6 for non-working keyboards.?
Without looking into this in detail, I would expect this needs to be
sent as series of 3 patches to 2 different maintainers, and the u-boot
mailing list, of course. And please provide your full name for sign-off.
Regards,
Soeren
>
>
> Stefan
>
>
>> Am 29.02.2020 um 13:04 schrieb Soeren Moch <smoch@web.de>:
>>
>>
>>
>> On 29.02.20 00:46, Marek Vasut wrote:
>>> On 2/26/20 12:04 PM, Soeren Moch wrote:
>>>> Adding Marek as USB maintainer. Otherwise this non-patch-email may get
>>>> lost when sent to the mailing list only.
>>> Well, can you send these as proper patches ?
>> Well, I can try to make a proposal for patches. But I cannot test
>> something since I neither own such D-Link DBT-120 Bluetooth Adapter, nor
>> a Raspberry Pi 3b as host system. I'm also not familiar with the details
>> of event polling / interrupt message NYET handling in u-boot, so
>> probably will not come up with a good commit message about this. I also
>> cannot judge which workaround or revert of such is appropriate.
>>
>> Stefan, can you convert your fixes to proper patches yourself, or do you
>> want me to send a first proposal?
>>
>> Thanks,
>> Soeren
>>>> Soeren
>>>>
>>>> On 25.02.20 18:45, Stefan wrote:
>>>>> 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.
>>> [...]
>>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-03-01 17:46 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-25 17:45 Fixing low-speed USB keyboard detection Stefan
2020-02-26 11:04 ` Soeren Moch
2020-02-28 23:46 ` Marek Vasut
2020-02-29 12:04 ` Soeren Moch
2020-02-29 12:42 ` Stefan
2020-03-01 17:46 ` Soeren Moch
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.