[opensuse-arm] rpi to rpi via usb gadget
Hi, I've tried to use the USB OTG features of the RPi4 to remote control an RPi3 with MicroOS 15.2 using pikvm. That works fine as soon as Linux is booted in the RPi3. Fails in U-Boot and therefore grub though. U-Boot doesn't detect the simulated devices. On the Pi4 the kernel throws error messages: [ 104.168251] configfs-gadget gadget: usb_ep_queue error on int endpoint -11 Is that an issue on our side in U-Boot or somewhere else? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi,
-----Original Message----- From: Ludwig Nussel <ludwig.nussel@suse.de> Sent: 01 September 2020 18:51 To: opensuse-arm@opensuse.org Subject: [opensuse-arm] rpi to rpi via usb gadget
Hi,
I've tried to use the USB OTG features of the RPi4 to remote control an RPi3 with MicroOS 15.2 using pikvm. That works fine as soon as Linux is booted in the RPi3. Fails in U-Boot and therefore grub though. U-Boot doesn't detect the simulated devices. On the Pi4 the kernel throws error messages: [ 104.168251] configfs-gadget gadget: usb_ep_queue error on int endpoint -11
Is that an issue on our side in U-Boot or somewhere else?
Could it be related to https://github.com/raspberrypi/firmware/issues/1322 ? Cc'ing Matthias and Nicolas. Cheers, Guillaume
cu Ludwig
-- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Guillaume Gardet wrote:
-----Original Message----- From: Ludwig Nussel <ludwig.nussel@suse.de> Sent: 01 September 2020 18:51 To: opensuse-arm@opensuse.org Subject: [opensuse-arm] rpi to rpi via usb gadget
Hi,
I've tried to use the USB OTG features of the RPi4 to remote control an RPi3 with MicroOS 15.2 using pikvm. That works fine as soon as Linux is booted in the RPi3. Fails in U-Boot and therefore grub though. U-Boot doesn't detect the simulated devices. On the Pi4 the kernel throws error messages: [ 104.168251] configfs-gadget gadget: usb_ep_queue error on int endpoint -11
Is that an issue on our side in U-Boot or somewhere else?
Could it be related to https://github.com/raspberrypi/firmware/issues/1322 ?
The pikvm website also mentions that the OTG mode doesn't work with some PC BIOSes¹ while an Arduino does the job. So maybe that OTG descriptor confuses them too? Is there a way to make the kernel not generate that descriptor to test? cu Ludwig [1]https://github.com/pikvm/pikvm#limitations -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Moin, Am Mittwoch, 2. September 2020, 10:28:21 CEST schrieb Ludwig Nussel:
Guillaume Gardet wrote:
-----Original Message----- From: Ludwig Nussel <ludwig.nussel@suse.de> Sent: 01 September 2020 18:51 To: opensuse-arm@opensuse.org Subject: [opensuse-arm] rpi to rpi via usb gadget
Hi,
I've tried to use the USB OTG features of the RPi4 to remote control an RPi3 with MicroOS 15.2 using pikvm. That works fine as soon as Linux is booted in the RPi3. Fails in U-Boot and therefore grub though. U-Boot doesn't detect the simulated devices. On the Pi4 the kernel throws error messages: [ 104.168251] configfs-gadget gadget: usb_ep_queue error on int endpoint -11
Is that an issue on our side in U-Boot or somewhere else?
Could it be related to https://github.com/raspberrypi/firmware/issues/1322 ?
The pikvm website also mentions that the OTG mode doesn't work with some PC BIOSes¹ while an Arduino does the job. So maybe that OTG descriptor confuses them too? Is there a way to make the kernel not generate that descriptor to test?
Forcing the controller in peripheral only mode might work. Something like that as device tree overlay maybe: &usb { dr_mode = "peripheral"; }; That's visible as a dr_mode file below /sys as well. Cheers, Fabian
cu Ludwig
-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am Mittwoch, 2. September 2020, 10:28:21 CEST schrieb Ludwig Nussel:
Guillaume Gardet wrote:
-----Original Message----- From: Ludwig Nussel <ludwig.nussel@suse.de> Sent: 01 September 2020 18:51 To: opensuse-arm@opensuse.org Subject: [opensuse-arm] rpi to rpi via usb gadget
Hi,
I've tried to use the USB OTG features of the RPi4 to remote control an RPi3 with MicroOS 15.2 using pikvm. That works fine as soon as Linux is booted in the RPi3. Fails in U-Boot and therefore grub though. U-Boot doesn't detect the simulated devices. On the Pi4 the kernel throws error messages: [ 104.168251] configfs-gadget gadget: usb_ep_queue error on int endpoint -11
Is that an issue on our side in U-Boot or somewhere else?
Could it be related to https://github.com/raspberrypi/firmware/issues/1322 ?
The pikvm website also mentions that the OTG mode doesn't work with some PC BIOSes¹ while an Arduino does the job. So maybe that OTG descriptor confuses them too? Is there a way to make the kernel not generate that descriptor to test?
Forcing the controller in peripheral only mode might work. Something
Fabian Vogt wrote: like that
as device tree overlay maybe:
&usb { dr_mode = "peripheral"; };
Fabian also found that it's as simple as dtoverlay=dwc2,dr_mode=peripheral to get rid of the otg descriptor. That's not the issue though. I found that when setting the hid subclass to 0 the device appears in u-boot. Still doesn't work though. It's not specific to the rpi3 either. Connecting a A10 olinuxino on the other side also gets no keyboard input either. Looking at "usb info" one can see that the gadget has two endpoints. One for input and one for output. Whereas real keyboards and also an Arduino pretending to be a keyboard only has an input endpoint. Could that be relevant? I couldn't find how to disable the second endpoint via configfs though. Any ideas? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Freitag, 4. September 2020 14:25:37 CEST Ludwig Nussel wrote:
Fabian Vogt wrote: to get rid of the otg descriptor. That's not the issue though. I found that when setting the hid subclass to 0 the device appears in u-boot. Still doesn't work though. It's not specific to the rpi3 either. Connecting a A10 olinuxino on the other side also gets no keyboard input either. Looking at "usb info" one can see that the gadget has two endpoints. One for input and one for output. Whereas real keyboards and also an Arduino pretending to be a keyboard only has an input endpoint. Could that be relevant? I couldn't find how to disable the second endpoint via configfs though. Any ideas?
Although USB Keyboards all use the HID protocol, grabbing into the stack of Keyboards I used when extending the Rpi1-3 dwc2 implementation: - USB low speed (1.5 MBit/s) and USB full speed (12 MBit/s) - Control + Interupt IN is required, OUT is optional - Devices may have one or multiple interfaces (e.g. Logitech Unifying receivers). As the OTG device appears under some circumstances, physical layer problems are unlikely. Does the OTG device only emulate an USB Keyboard (Class/Subclass/Protocol: 3/1/1), or also a mouse (3/1/2)? U-Boot might be confused when a device has interfaces with both protocols. Other than that, I fear you either have to recompile U-Boot with additional debug output, or connect a logic analyzer in between. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
On Freitag, 4. September 2020 14:25:37 CEST Ludwig Nussel wrote:
Fabian Vogt wrote: to get rid of the otg descriptor. That's not the issue though. I found that when setting the hid subclass to 0 the device appears in u-boot. Still doesn't work though. It's not specific to the rpi3 either. Connecting a A10 olinuxino on the other side also gets no keyboard input either. Looking at "usb info" one can see that the gadget has two endpoints. One for input and one for output. Whereas real keyboards and also an Arduino pretending to be a keyboard only has an input endpoint. Could that be relevant? I couldn't find how to disable the second endpoint via configfs though. Any ideas?
Although USB Keyboards all use the HID protocol, grabbing into the stack of Keyboards I used when extending the Rpi1-3 dwc2 implementation:
- USB low speed (1.5 MBit/s) and USB full speed (12 MBit/s) - Control + Interupt IN is required, OUT is optional - Devices may have one or multiple interfaces (e.g. Logitech Unifying receivers).
As the OTG device appears under some circumstances, physical layer
Stefan Brüns wrote: problems
are unlikely.
Does the OTG device only emulate an USB Keyboard (Class/Subclass/Protocol: 3/1/1), or also a mouse (3/1/2)? U-Boot might be confused when a device has interfaces with both protocols.
It's complicated indeed. Fabian pointed me at https://github.com/u-boot/u-boot/blob/9bfb567e5f1bfe7de8eb41f8c6d00f49d2b9a4... So u-boot doesn't even accept devices with more than one endpoint. Too bad usb_f_hid hardcodes IN and OUT. Also, u-boot requires the boot flag to be set but at the same time when the gadget has that it's not shown. So I've enabled debug in u-boot and see this: usb_control_msg() usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0 usb_select_config() new device strings: Mfr=1, Product=2, SerialNumber=3 usb_control_msg() usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 length 0xFF usb_string() USB device number 3 default language ID 0x409 usb_control_msg() usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x409 length 0xFF usb_control_msg() usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x409 length 0xFF usb_control_msg() usb_control_msg: request: 0x6, requesttype: 0x80, value 0x303 index 0x409 length 0xFF usb_select_config() Manufacturer openSUSE usb_select_config() Product openQA usb_select_config() SerialNumber fedcba9876543210 usb_kbd_probe_dev() USB KBD: found set protocol... usb_control_msg() usb_control_msg: request: 0xB, requesttype: 0x21, value 0x0 index 0x0 length 0x0 usb_kbd_probe_dev() USB KBD: found set idle... usb_control_msg() usb_control_msg: request: 0xA, requesttype: 0x21, value 0xA00 index 0x0 length 0x0 usb_kbd_probe_dev() USB KBD: enable interrupt pipe... Timeout poll on interrupt endpoint Failed to get keyboard state from device 1d6b:0104 The gadget is this atm: # show-gadgets ID 1d6b:0104 'usbarmory' UDC fe980000.usb bcdUSB 2.00 bDeviceClass 0x00 bDeviceSubClass 0x00 bDeviceProtocol 0x00 bMaxPacketSize0 64 idVendor 0x1d6b idProduct 0x0104 bcdDevice 0.90 Language: 0x409 Manufacturer openSUSE Product openQA Serial Number fedcba9876543210 Function, type: hid instance: usb0 dev 236:0 protocol 1 report_desc 5196a115719e029e7150251751958812951758813955751581912959129517539139567581502565571902965810c0 report_length 8 subclass 1 Function, type: hid instance: usb1 dev 236:1 protocol 0 report_desc 5196a115719e029e7150251751958812951758813955751581912959129517539139567581502565571902965810c0 report_length 8 subclass 0 Configuration: 'c' ID: 1 MaxPower 250 bmAttributes 0x80 Language: 0x409 configuration foofoo hid.usb0 -> hid usb0 hid.usb1 -> hid usb1 cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Freitag, 4. September 2020 17:43:37 CEST Ludwig Nussel wrote:
Stefan Brüns wrote:
On Freitag, 4. September 2020 14:25:37 CEST Ludwig Nussel wrote:
Fabian Vogt wrote: to get rid of the otg descriptor. That's not the issue though. I found that when setting the hid subclass to 0 the device appears in u-boot. Still doesn't work though. It's not specific to the rpi3 either. Connecting a A10 olinuxino on the other side also gets no keyboard input either. Looking at "usb info" one can see that the gadget has two endpoints. One for input and one for output. Whereas real keyboards and also an Arduino pretending to be a keyboard only has an input endpoint. Could that be relevant? I couldn't find how to disable the second endpoint via configfs though. Any ideas?
Although USB Keyboards all use the HID protocol, grabbing into the
stack of
Keyboards I used when extending the Rpi1-3 dwc2 implementation:
- USB low speed (1.5 MBit/s) and USB full speed (12 MBit/s) - Control + Interupt IN is required, OUT is optional - Devices may have one or multiple interfaces (e.g. Logitech Unifying receivers).
As the OTG device appears under some circumstances, physical layer
problems
are unlikely.
Does the OTG device only emulate an USB Keyboard
(Class/Subclass/Protocol:
3/1/1), or also a mouse (3/1/2)? U-Boot might be confused when a
device has
interfaces with both protocols.
You may try this patch: https://build.opensuse.org/package/view_file/ home:StefanBruens:branches:hardware:boot/u-boot/0001-usb-kbd-Also-accept- keyboards-with-Interrupt-OUT-end.patch?expand=1
It's complicated indeed. Fabian pointed me at https://github.com/u-boot/u-boot/blob/9bfb567e5f1bfe7de8eb41f8c6d00f49d2b9a4 26/common/usb_kbd.c#L461 So u-boot doesn't even accept devices with more than one endpoint. Too bad usb_f_hid hardcodes IN and OUT. Also, u-boot requires the boot flag to be set but at the same time when the gadget has that it's not shown. So I've enabled debug in u-boot and see this:
usb_control_msg() usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0 usb_select_config() new device strings: Mfr=1, Product=2, SerialNumber=3 usb_control_msg() usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 length 0xFF usb_string() USB device number 3 default language ID 0x409 usb_control_msg() usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x409 length 0xFF usb_control_msg() usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x409 length 0xFF usb_control_msg() usb_control_msg: request: 0x6, requesttype: 0x80, value 0x303 index 0x409 length 0xFF usb_select_config() Manufacturer openSUSE usb_select_config() Product openQA usb_select_config() SerialNumber fedcba9876543210 usb_kbd_probe_dev() USB KBD: found set protocol... usb_control_msg() usb_control_msg: request: 0xB, requesttype: 0x21, value 0x0 index 0x0 length 0x0
usb_kbd_probe_dev() USB KBD: found set idle... usb_control_msg() usb_control_msg: request: 0xA, requesttype: 0x21, value 0xA00 index 0x0 length 0x0 usb_kbd_probe_dev() USB KBD: enable interrupt pipe... Timeout poll on interrupt endpoint Failed to get keyboard state from device 1d6b:0104
requesttype: 0x21 - Class specific request to interface request: 0xA - Set_Idle value: 0xA00 - 0xA * 4ms = 40ms report interval during idle, 0x0: applies to all reports So according to the request, the OTG device should send report at regular intervals even without state changes, but the keyboard poll code times out. Maybe an interval is not supported by the gadget code, while U-Boot requires it. Would be interesting what a "Get_Idle" request returns. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
On Fri, Sep 04, 2020 at 08:53:34PM +0200, Stefan Brüns wrote:
On Freitag, 4. September 2020 17:43:37 CEST Ludwig Nussel wrote:
Stefan Brüns wrote:
On Freitag, 4. September 2020 14:25:37 CEST Ludwig Nussel wrote:
Fabian Vogt wrote: to get rid of the otg descriptor. That's not the issue though. I found that when setting the hid subclass to 0 the device appears in u-boot. Still doesn't work though. It's not specific to the rpi3 either. Connecting a A10 olinuxino on the other side also gets no keyboard input either. Looking at "usb info" one can see that the gadget has two endpoints. One for input and one for output. Whereas real keyboards and also an Arduino pretending to be a keyboard only has an input endpoint. Could that be relevant? I couldn't find how to disable the second endpoint via configfs though. Any ideas?
Although USB Keyboards all use the HID protocol, grabbing into the
stack of
Keyboards I used when extending the Rpi1-3 dwc2 implementation:
- USB low speed (1.5 MBit/s) and USB full speed (12 MBit/s) - Control + Interupt IN is required, OUT is optional - Devices may have one or multiple interfaces (e.g. Logitech Unifying receivers).
As the OTG device appears under some circumstances, physical layer
problems
are unlikely.
Does the OTG device only emulate an USB Keyboard
(Class/Subclass/Protocol:
3/1/1), or also a mouse (3/1/2)? U-Boot might be confused when a
device has
interfaces with both protocols.
You may try this patch: https://build.opensuse.org/package/view_file/ home:StefanBruens:branches:hardware:boot/u-boot/0001-usb-kbd-Also-accept- keyboards-with-Interrupt-OUT-end.patch?expand=1
It's complicated indeed. Fabian pointed me at https://github.com/u-boot/u-boot/blob/9bfb567e5f1bfe7de8eb41f8c6d00f49d2b9a4 26/common/usb_kbd.c#L461 So u-boot doesn't even accept devices with more than one endpoint. Too bad usb_f_hid hardcodes IN and OUT. Also, u-boot requires the boot flag to be set but at the same time when the gadget has that it's not shown. So I've enabled debug in u-boot and see this:
usb_control_msg() usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0 usb_select_config() new device strings: Mfr=1, Product=2, SerialNumber=3 usb_control_msg() usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 length 0xFF usb_string() USB device number 3 default language ID 0x409 usb_control_msg() usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x409 length 0xFF usb_control_msg() usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x409 length 0xFF usb_control_msg() usb_control_msg: request: 0x6, requesttype: 0x80, value 0x303 index 0x409 length 0xFF usb_select_config() Manufacturer openSUSE usb_select_config() Product openQA usb_select_config() SerialNumber fedcba9876543210 usb_kbd_probe_dev() USB KBD: found set protocol... usb_control_msg() usb_control_msg: request: 0xB, requesttype: 0x21, value 0x0 index 0x0 length 0x0
usb_kbd_probe_dev() USB KBD: found set idle... usb_control_msg() usb_control_msg: request: 0xA, requesttype: 0x21, value 0xA00 index 0x0 length 0x0 usb_kbd_probe_dev() USB KBD: enable interrupt pipe... Timeout poll on interrupt endpoint Failed to get keyboard state from device 1d6b:0104
requesttype: 0x21 - Class specific request to interface request: 0xA - Set_Idle value: 0xA00 - 0xA * 4ms = 40ms report interval during idle, 0x0: applies to all reports
So according to the request, the OTG device should send report at regular intervals even without state changes, but the keyboard poll code times out.
You can also try to press a key while u-boot is scanning for the keyboard. IIRC the dwc controller on the rPi has some issues that make it time out when other controllers would receive the packet. Thanks Michal -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Stefan Brüns wrote:
On Freitag, 4. September 2020 17:43:37 CEST Ludwig Nussel wrote:
[...] usb_kbd_probe_dev() USB KBD: found set idle... usb_control_msg() usb_control_msg: request: 0xA, requesttype: 0x21, value 0xA00 index 0x0 length 0x0 usb_kbd_probe_dev() USB KBD: enable interrupt pipe... Timeout poll on interrupt endpoint Failed to get keyboard state from device 1d6b:0104
requesttype: 0x21 - Class specific request to interface request: 0xA - Set_Idle value: 0xA00 - 0xA * 4ms = 40ms report interval during idle, 0x0: applies to all reports
So according to the request, the OTG device should send report at regular intervals even without state changes, but the keyboard poll code times out.
The discussion also reminded me of a USB-PS2 adapter that also doesn't work in u-boot (bug#1167675). With your patch and LOG_DEBUG in common/usb{_kbd,}.c:¹ usb_kbd_probe_dev() USB KBD: found interrupt EP: 0x81 usb_kbd_probe_dev() USB KBD: set boot protocol usb_control_msg() usb_control_msg: request: 0xB, requesttype: 0x21, value 0x0 index 0x0 length 0x0 usb_kbd_probe_dev() USB KBD: set idle interval... usb_control_msg() usb_control_msg: request: 0xA, requesttype: 0x21, value 0xA00 index 0x0 length 0x0 usb_kbd_probe_dev() USB KBD: enable interrupt pipe... Timeout poll on interrupt endpoint Failed to get keyboard state from device 04d9:1400 If that is the same problem then at least it's not Linux gadget code specific but also affects actual hardware devices.
Maybe an interval is not supported by the gadget code, while U-Boot requires it. Would be interesting what a "Get_Idle" request returns.
How to get that information? cu Ludwig [1] Would it be possible to have some easier way to enable verbose debug logging in u-boot rather than branching and patching the package in OBS? Would probably make it easier for people to contribute useful debug output that don't want to deep dive into u-boot :-) -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Ludwig Nussel wrote:
Stefan Brüns wrote:
On Freitag, 4. September 2020 17:43:37 CEST Ludwig Nussel wrote:
[...] usb_kbd_probe_dev() USB KBD: found set idle... usb_control_msg() usb_control_msg: request: 0xA, requesttype: 0x21, value 0xA00 index 0x0 length 0x0 usb_kbd_probe_dev() USB KBD: enable interrupt pipe... Timeout poll on interrupt endpoint Failed to get keyboard state from device 1d6b:0104
requesttype: 0x21 - Class specific request to interface request: 0xA - Set_Idle value: 0xA00 - 0xA * 4ms = 40ms report interval during idle, 0x0: applies to all reports
So according to the request, the OTG device should send report at regular intervals even without state changes, but the keyboard poll code times out.
The discussion also reminded me of a USB-PS2 adapter that also doesn't work in u-boot (bug#1167675). With your patch and LOG_DEBUG in common/usb{_kbd,}.c:¹
usb_kbd_probe_dev() USB KBD: found interrupt EP: 0x81 usb_kbd_probe_dev() USB KBD: set boot protocol usb_control_msg() usb_control_msg: request: 0xB, requesttype: 0x21, value 0x0 index 0x0 length 0x0 usb_kbd_probe_dev() USB KBD: set idle interval... usb_control_msg() usb_control_msg: request: 0xA, requesttype: 0x21, value 0xA00 index 0x0 length 0x0 usb_kbd_probe_dev() USB KBD: enable interrupt pipe... Timeout poll on interrupt endpoint Failed to get keyboard state from device 04d9:1400
If that is the same problem then at least it's not Linux gadget code specific but also affects actual hardware devices.
lsusb -v for reference. So this one also only has one interface for the keyboard with the subclass set. In contrast to the working keyboards that have one interface with the boot flag and one without. Bus 001 Device 004: ID 04d9:1400 Holtek Semiconductor, Inc. PS/2 keyboard + mouse controller Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x04d9 Holtek Semiconductor, Inc. idProduct 0x1400 PS/2 keyboard + mouse controller bcdDevice 1.43 iManufacturer 0 iProduct 0 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 59 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 1 Keyboard iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.10 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 65 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 10 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 2 Mouse iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.10 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 157 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 10 can't get debug descriptor: Resource temporarily unavailable Device Status: 0x0000 (Bus Powered) cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Stefan Brüns wrote:
[...] You may try this patch: https://build.opensuse.org/package/view_file/ home:StefanBruens:branches:hardware:boot/u-boot/0001-usb-kbd-Also-accept- keyboards-with-Interrupt-OUT-end.patch?expand=1
usb_select_config() Manufacturer openSUSE usb_select_config() Product openQA usb_select_config() SerialNumber fedcba9876543210 usb_kbd_probe_dev() USB KBD: found interrupt EP: 0x81 usb_kbd_probe_dev() USB KBD: set boot protocol usb_control_msg() usb_control_msg: request: 0xB, requesttype: 0x21, value 0x0 index 0x0 length 0x0 usb_kbd_probe_dev() USB KBD: set idle interval... usb_control_msg() usb_control_msg: request: 0xA, requesttype: 0x21, value 0xA00 index 0x0 length 0x0 usb_kbd_probe_dev() USB KBD: enable interrupt pipe... Timeout poll on interrupt endpoint Failed to get keyboard state from device 1d6b:0104 cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Montag, 7. September 2020 10:52:51 CEST Ludwig Nussel wrote:
Stefan Brüns wrote:
[...] You may try this patch: https://build.opensuse.org/package/view_file/ home:StefanBruens:branches:hardware:boot/u-boot/0001-usb-kbd-Also-accept- keyboards-with-Interrupt-OUT-end.patch?expand=1
usb_select_config() Manufacturer openSUSE usb_select_config() Product openQA usb_select_config() SerialNumber fedcba9876543210 usb_kbd_probe_dev() USB KBD: found interrupt EP: 0x81 usb_kbd_probe_dev() USB KBD: set boot protocol usb_control_msg() usb_control_msg: request: 0xB, requesttype: 0x21, value 0x0 index 0x0 length 0x0 usb_kbd_probe_dev() USB KBD: set idle interval... usb_control_msg() usb_control_msg: request: 0xA, requesttype: 0x21, value 0xA00 index 0x0 length 0x0 usb_kbd_probe_dev() USB KBD: enable interrupt pipe... Timeout poll on interrupt endpoint Failed to get keyboard state from device 1d6b:0104
The failure here is expected, as this only deals with the case of IN+OUT endpoints. Is this for a device which has both? Regars, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
Stefan Brüns wrote:
On Montag, 7. September 2020 10:52:51 CEST Ludwig Nussel wrote:
Stefan Brüns wrote:
[...] You may try this patch: https://build.opensuse.org/package/view_file/
home:StefanBruens:branches:hardware:boot/u-boot/0001-usb-kbd-Also-accept-
keyboards-with-Interrupt-OUT-end.patch?expand=1
usb_select_config() Manufacturer openSUSE usb_select_config() Product openQA usb_select_config() SerialNumber fedcba9876543210 usb_kbd_probe_dev() USB KBD: found interrupt EP: 0x81 usb_kbd_probe_dev() USB KBD: set boot protocol usb_control_msg() usb_control_msg: request: 0xB, requesttype: 0x21, value 0x0 index 0x0 length 0x0 usb_kbd_probe_dev() USB KBD: set idle interval... usb_control_msg() usb_control_msg: request: 0xA, requesttype: 0x21, value 0xA00 index 0x0 length 0x0 usb_kbd_probe_dev() USB KBD: enable interrupt pipe... Timeout poll on interrupt endpoint Failed to get keyboard state from device 1d6b:0104
The failure here is expected, as this only deals with the case of IN+OUT endpoints. Is this for a device which has both?
Yes, that's the gadget mode of the rpi4. Your patch fixes the endpoint check. The code later then of course still fails when actually trying to activate the keyboard. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Stefan Brüns wrote:
[...] requesttype: 0x21 - Class specific request to interface request: 0xA - Set_Idle value: 0xA00 - 0xA * 4ms = 40ms report interval during idle, 0x0: applies to all reports
So according to the request, the OTG device should send report at regular intervals even without state changes, but the keyboard poll code times out.
Maybe an interval is not supported by the gadget code, while U-Boot requires it. Would be interesting what a "Get_Idle" request returns.
I've added debug calls to log the return value and also enabled debug in the dwc2 controller code. Logs of the gadget as well as the ps2adapter attached. In case of the gadget the idle call return -22. For the ps2adapter it's zero but that one still doesn't work either. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
On Montag, 7. September 2020 17:34:19 CEST Ludwig Nussel wrote:
Stefan Brüns wrote:
[...] requesttype: 0x21 - Class specific request to interface request: 0xA - Set_Idle
value: 0xA00 - 0xA * 4ms = 40ms report interval during idle, 0x0: applies to
all reports
So according to the request, the OTG device should send report at regular intervals even without state changes, but the keyboard poll code times
out.
Maybe an interval is not supported by the gadget code, while U-Boot
requires
it. Would be interesting what a "Get_Idle" request returns.
I've added debug calls to log the return value and also enabled debug in the dwc2 controller code. Logs of the gadget as well as the ps2adapter attached.
In case of the gadget the idle call return -22. For the ps2adapter it's zero but that one still doesn't work either.
cu Ludwig
usb_kbd_probe_dev() USB KBD: set boot protocol usb_control_msg() usb_control_msg: request: 0xB, requesttype: 0x21, value 0x0 index 0x0 length 0x0 dwc2_submit_control_msg() dwc2_submit_control_msg: dev='usb@7e980000', udev=000000003db30210, udev->dev='usb_kbd', portnr=2 chunk_msg() chunk_msg: msg: pipe 80000403 pid 3 in 0 len 8 transfer_chunk() transfer_chunk: chunk: pid 3 xfer_len 8 pkts 1 PID: Setup
wait_for_chhltd() wait_for_chhltd: HCINT=00000023 sub=8 toggle=1 HCINT (*): XFER_COMPLETE | CHANNEL_HALTED | ACK
chunk_msg() chunk_msg: msg: pipe 80000403 pid 2 in 1 len 0 transfer_chunk() transfer_chunk: chunk: pid 2 xfer_len 0 pkts 1 PID: Data1 (Status stage) -> OK
wait_for_chhltd() wait_for_chhltd: HCINT=00000023 sub=0 toggle=0 usb_kbd_probe_dev() USB KBD: set boot protocol returned 0 usb_kbd_probe_dev() USB KBD: set idle interval... usb_control_msg() usb_control_msg: request: 0xA, requesttype: 0x21, value 0xA00 index 0x0 length 0x0 dwc2_submit_control_msg() dwc2_submit_control_msg: dev='usb@7e980000', udev=000000003db30210, udev->dev='usb_kbd', portnr=2 chunk_msg() chunk_msg: msg: pipe 80000403 pid 3 in 0 len 8 transfer_chunk() transfer_chunk: chunk: pid 3 xfer_len 8 pkts 1 wait_for_chhltd() wait_for_chhltd: HCINT=00000023 sub=8 toggle=1 Setup, XFER_COMPLETE | CHANNEL_HALTED | ACK
chunk_msg() chunk_msg: msg: pipe 80000403 pid 2 in 1 len 0 transfer_chunk() transfer_chunk: chunk: pid 2 xfer_len 0 pkts 1 wait_for_chhltd() wait_for_chhltd: HCINT=0000000a sub=0 toggle=2 wait_for_chhltd() wait_for_chhltd: Error (HCINT=0000000a) Status: CHANNEL_HALTED | STALL
usb_kbd_probe_dev() USB KBD: set idle 10 returned -22 U-Boot obviously ignores the failing request, and commences as it had succeeded. Though, apparently this is only relevant for Linux Gadget mode, as
USB 2.0 spec: " STALL indicates that the function cannot complete the command." the Holtek HID fails silently.
usb_kbd_probe_dev() USB KBD: enable interrupt pipe... dwc2_submit_int_msg() dwc2_submit_int_msg: dev='usb@7e980000', udev=000000003db30210 ... chunk_msg() chunk_msg: msg: pipe 40408483 pid 0 in 1 len 8 transfer_chunk() transfer_chunk: chunk: pid 0 xfer_len 8 pkts 1 wait_for_chhltd() wait_for_chhltd: HCINT=00000012 sub=8 toggle=0 Status: CHANNEL_HALTED | NACK "I really have no keyboard status change for you" ...
Timeout poll on interrupt endpoint Failed to get keyboard state from device 1d6b:0104
Kind regards, Stefan *) https://elixir.bootlin.com/u-boot/v2020.07/source/drivers/usb/host/ dwc2.h#L648 -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
Stefan Brüns wrote:
On Freitag, 4. September 2020 17:43:37 CEST Ludwig Nussel wrote:
Stefan Brüns wrote:
On Freitag, 4. September 2020 14:25:37 CEST Ludwig Nussel wrote:
[...] Looking at "usb info" one can see that the gadget has two endpoints. One for input and one for output. Whereas real keyboards and also an Arduino pretending to be a keyboard only has an input endpoint. Could that be relevant? I couldn't find how to disable the second endpoint via configfs though. [...] You may try this patch: https://build.opensuse.org/package/view_file/ home:StefanBruens:branches:hardware:boot/u-boot/0001-usb-kbd-Also-accept- keyboards-with-Interrupt-OUT-end.patch?expand=1
So with your patch and https://build.opensuse.org/package/view_file/home:lnussel:branches:hardware:... it works! Are you planning to send yours upstream? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Dienstag, 8. September 2020 17:52:17 CEST Ludwig Nussel wrote:
Stefan Brüns wrote:
On Freitag, 4. September 2020 17:43:37 CEST Ludwig Nussel wrote:
Stefan Brüns wrote:
On Freitag, 4. September 2020 14:25:37 CEST Ludwig Nussel wrote:
[...] Looking at "usb info" one can see that the gadget has two
endpoints. One
for input and one for output. Whereas real keyboards and also an
Arduino
pretending to be a keyboard only has an input endpoint. Could that be relevant? I couldn't find how to disable the second endpoint via configfs though.
[...] You may try this patch: https://build.opensuse.org/package/view_file/ home:StefanBruens:branches:hardware:boot/u-boot/0001-usb-kbd-Also-accept- keyboards-with-Interrupt-OUT-end.patch?expand=1
So with your patch and https://build.opensuse.org/package/view_file/home:lnussel:branches:hardware: boot/u-boot/0001-Fix-RPi-2-3-USB-keyboard.patch
I have something similar cooking. Actually, I would avoid the extra CONFIG option and just always use Get_Report for the initial state, and only use the Interrupt pipe for event polling later. Can you try if setting CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE also works? As far as I can see this does not check for a non-empty response, but just creates the queue. Nb, CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE is the default for Allwinner SoCs.
it works! Are you planning to send yours upstream?
Yes, definitely, just a matter of limited time. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019
On Dienstag, 8. September 2020 17:52:17 CEST Ludwig Nussel wrote:
Stefan Brüns wrote:
On Freitag, 4. September 2020 17:43:37 CEST Ludwig Nussel wrote:
Stefan Brüns wrote:
On Freitag, 4. September 2020 14:25:37 CEST Ludwig Nussel wrote:
[...] Looking at "usb info" one can see that the gadget has two
endpoints. One
for input and one for output. Whereas real keyboards and also an
Arduino
pretending to be a keyboard only has an input endpoint. Could that be relevant? I couldn't find how to disable the second endpoint via configfs
Stefan Brüns wrote: though.
[...] You may try this patch: https://build.opensuse.org/package/view_file/
home:StefanBruens:branches:hardware:boot/u-boot/0001-usb-kbd-Also-accept-
keyboards-with-Interrupt-OUT-end.patch?expand=1
So with your patch and
https://build.opensuse.org/package/view_file/home:lnussel:branches:hardware:
boot/u-boot/0001-Fix-RPi-2-3-USB-keyboard.patch
I have something similar cooking. Actually, I would avoid the extra CONFIG option and just always use Get_Report for the initial state, and only use the Interrupt pipe for event polling later.
Can you try if setting CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE also works? As far as I can see this does not check for a non-empty response, but just creates the queue. Nb, CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE is the default for Allwinner SoCs.
I tried the other settings first but they didn't work. With CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP one key press came through. The combination of getting the report and then using the int queue might be worth trying. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Ludwig Nussel wrote:
Stefan Brüns wrote:
[...] Can you try if setting CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE also works? As far as I can see this does not check for a non-empty response, but just creates the queue. Nb, CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE is the default for Allwinner SoCs.
I tried the other settings first but they didn't work. With CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP one key press came through. The combination of getting the report and then using the int queue might be worth trying.
Looks like dwc2 doesn't implement create_int_queue() ... cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
(OT, but still might be useful to some...) Am 04.09.20 um 17:43 schrieb Ludwig Nussel:
It's complicated indeed. Fabian pointed me at https://github.com/u-boot/u-boot/blob/9bfb567e5f1bfe7de8eb41f8c6d00f49d2b9a4... So u-boot doesn't even accept devices with more than one endpoint.
This might also explain why I never could input anything to U-Boot and GRUB on my raspis. The keyboard i tried also has some multimedia keys and they appear on a different input device... don't have it handy to check the usb descriptors, but it might certainly explain that failure. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On Samstag, 5. September 2020 12:25:17 CEST Stefan Seyfried wrote:
(OT, but still might be useful to some...)
Am 04.09.20 um 17:43 schrieb Ludwig Nussel:
It's complicated indeed. Fabian pointed me at https://github.com/u-boot/u-boot/blob/9bfb567e5f1bfe7de8eb41f8c6d00f49d2b9 a426/common/usb_kbd.c#L461 So u-boot doesn't even accept devices with more than one endpoint. This might also explain why I never could input anything to U-Boot and GRUB on my raspis. The keyboard i tried also has some multimedia keys and they appear on a different input device... don't have it handy to check the usb descriptors, but it might certainly explain that failure.
I think you are mixing multiple interfaces and multiple endpoints here. An interface is a set of endpoints, the endpoints forming the data pipes for a single protocol. An interface typically shows up as a single device in Linux. That said, though there is no causal relationship between multiple interfaces and existence of an interrupt OUT endpoint, there may be a tendency of more complex devices to have it. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
Stefan Brüns wrote:
On Samstag, 5. September 2020 12:25:17 CEST Stefan Seyfried wrote:
(OT, but still might be useful to some...)
Am 04.09.20 um 17:43 schrieb Ludwig Nussel:
It's complicated indeed. Fabian pointed me at
https://github.com/u-boot/u-boot/blob/9bfb567e5f1bfe7de8eb41f8c6d00f49d2b9
a426/common/usb_kbd.c#L461 So u-boot doesn't even accept devices with more than one endpoint. This might also explain why I never could input anything to U-Boot and GRUB on my raspis. The keyboard i tried also has some multimedia keys and they appear on a different input device... don't have it handy to check the usb descriptors, but it might certainly explain that failure.
I think you are mixing multiple interfaces and multiple endpoints here. An interface is a set of endpoints, the endpoints forming the data pipes for a single protocol. An interface typically shows up as a single device in Linux.
That said, though there is no causal relationship between multiple interfaces and existence of an interrupt OUT endpoint, there may be a tendency of more complex devices to have it.
Well Seife's guess about the multimedia keys might be a wrong clue but could very well be that this specific keyboard has the same issue like my usb-ps2 adapter, right? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (6)
-
Fabian Vogt -
Guillaume Gardet -
Ludwig Nussel -
Michal Suchánek -
Stefan Brüns -
Stefan Seyfried