Bug 1167675 - [u-boot] usb keyboard not working in ARM JeOS in RPi3
[u-boot] usb keyboard not working in ARM JeOS in RPi3
Status: CONFIRMED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Bootloader
Current
aarch64 Other
: P5 - None : Normal (vote)
: ---
Assigned To: Matthias Brugger
E-mail List
:
Depends on:
Blocks: 1172438
  Show dependency treegraph
 
Reported: 2020-03-25 16:45 UTC by Ludwig Nussel
Modified: 2021-02-20 19:57 UTC (History)
6 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
lsusb -v (17.13 KB, text/plain)
2020-06-03 13:32 UTC, Ludwig Nussel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ludwig Nussel 2020-03-25 16:45:38 UTC
USB keyboard is not working in u-boot and grub. u-boot throws an error. Later in Linux it works.

U-Boot 2020.01 (Mar 19 2020 - 14:15:58 +0000)

DRAM:  992 MiB
RPI 3 Model B (0xa02082)
MMC:   mmc@7e202000: 0, mmcnr@7e300000: 1
Loading Environment from FAT... *** Warning - bad CRC, using default environment

In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
Bus usb@7e980000: scanning bus usb@7e980000 for devices... Timeout poll on interrupt endpoint
Failed to get keyboard state from device 04d9:1400
4 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:3...
** Invalid partition 4 **
** Unrecognized filesystem type **
Scanning mmc 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Scanning disk mmc@7e202000.blk...
** Unrecognized filesystem type **
Card did not respond to voltage select!
Scanning disk mmcnr@7e300000.blk...
Disk mmcnr@7e300000.blk not ready
Scanning disk usb_mass_storage.lun0...
Found 6 disks
BootOrder not defined
EFI boot manager: Cannot load any image
1357680 bytes read in 60 ms (21.6 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
Welcome to GRUB!

Waiting for Ethernet connection... done.
Please press 't' to show the boot menu on this console
EFI stub: Booting Linux Kernel...
EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...

Welcome to openSUSE Tumbleweed dracut-049.1+git135.46dceb02-1.1 (Initramfs)!
Comment 1 Ludwig Nussel 2020-03-25 16:45:56 UTC
openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2020.03.19-Snapshot20200320
Comment 2 Guillaume GARDET 2020-03-25 18:20:13 UTC
@Matthias, I thought this problem was fixed in u-boot. Could you have a look, please?
Comment 3 Ludwig Nussel 2020-06-02 17:20:11 UTC
Did this fix make it anywhere? I'm looking at MicroOS 15.2, ie using u-boot from SLE and no keyboard in u-boot there either.
Comment 4 Ludwig Nussel 2020-06-02 17:20:22 UTC
(on rpi2 now)
Comment 5 Guillaume GARDET 2020-06-03 08:23:23 UTC
@Ludwig, Could you tell us more on the keyboard used, please? Is it a USB 1.1, maybe? Did you try another keyboard?
Comment 6 Ludwig Nussel 2020-06-03 13:32:32 UTC
Created attachment 838465 [details]
lsusb -v

The original report is about a ps2-usb connector. Plugging the other keyboard I have here, an older cherry USB keyboard also doesn't work. U-Boot says

      USB device not accepting new address (error=0)


Attaching lsub output with both devices connected.
Comment 8 Matthias Brugger 2020-06-05 08:25:11 UTC
(In reply to Ludwig Nussel from comment #6)
> Created attachment 838465 [details]
> lsusb -v
> 
> The original report is about a ps2-usb connector. Plugging the other
> keyboard I have here, an older cherry USB keyboard also doesn't work. U-Boot
> says
> 
>       USB device not accepting new address (error=0)
> 
> 
> Attaching lsub output with both devices connected.

So you have two keyboards, an USB stick and a USB hub connected. Correct? Unfortunately I don't have that much HW to test that myself.
Comment 9 Matthias Brugger 2020-06-05 08:26:48 UTC
(In reply to Ludwig Nussel from comment #4)
> (on rpi2 now)

but in this bug we are talking about rpi3, correct? This message puzzels me. Do you see the same bug on RPi2? If so please open a new bug or clone this one.
Comment 10 Ludwig Nussel 2020-06-05 08:30:40 UTC
(In reply to Matthias Brugger from comment #9)
> (In reply to Ludwig Nussel from comment #4)
> > (on rpi2 now)
> 
> but in this bug we are talking about rpi3, correct? This message puzzels me.
> Do you see the same bug on RPi2? If so please open a new bug or clone this
> one.

juggling several Pis atm and saw the problem on all of them.
Comment 11 Ludwig Nussel 2020-06-05 08:34:01 UTC
(In reply to Matthias Brugger from comment #8)
> (In reply to Ludwig Nussel from comment #6)
> > Attaching lsub output with both devices connected.
> 
> So you have two keyboards, an USB stick and a USB hub connected. Correct?
> Unfortunately I don't have that much HW to test that myself.

In order to have only one lsusb output I connected both keyboards, yes. Normally I'd only connect one though. Thought that's not relevant for seeing the USB properties of the devices. Sorry for the confusion :-/. One of the keyboards has a built in usb hub. The stick is directly connected to the Pi though.
Comment 12 Ludwig Nussel 2020-06-05 12:24:18 UTC
ok tried http://download.opensuse.org/ports/aarch64/tumbleweed/images/openSUSE-Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2020.05.25-Snapshot20200602.raw.xz

With my old keyboards same problem. I found another, crappy, cheap but less old :) in a box that works.
Comment 13 Matthias Brugger 2020-06-05 14:03:14 UTC
(In reply to Guillaume GARDET from comment #5)
> @Ludwig, Could you tell us more on the keyboard used, please? Is it a USB
> 1.1, maybe? Did you try another keyboard?

From the lsusb output it seems both keyboards are USB 1.1
Comment 14 Matthias Brugger 2020-06-05 14:59:43 UTC
(In reply to Ludwig Nussel from comment #12)
> ok tried
> http://download.opensuse.org/ports/aarch64/tumbleweed/images/openSUSE-
> Tumbleweed-ARM-JeOS-raspberrypi3.aarch64-2020.05.25-Snapshot20200602.raw.xz
> 
> With my old keyboards same problem. I found another, crappy, cheap but less
> old :) in a box that works.

I realized that my USB keyboard is USB 1.1 as well and it works with no problems.
So not sure where the problem is, or how to debug it.

Niclas, any idea?
Comment 15 Ludwig Nussel 2020-06-05 15:19:14 UTC
I mean no hard feeling from my side. Good to know it's not a generic issue.
Comment 16 Matthias Brugger 2020-06-21 11:04:38 UTC
No response on how to debug it further. Apart it seems to be a corner case
Comment 17 Ludwig Nussel 2020-09-07 08:27:16 UTC
Finally got a u-boot with debugging. See also discussion on opensuse-arm list.

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
Comment 18 Ludwig Nussel 2020-09-10 11:43:26 UTC
So the solution as found in two patches linked here:
https://lists.opensuse.org/opensuse-arm/2020-09/msg00008.html
https://lists.opensuse.org/opensuse-arm/2020-09/msg00024.html

Could you help getting them upstream?
Comment 19 Matthias Brugger 2020-09-14 12:51:02 UTC
(In reply to Ludwig Nussel from comment #18)
> So the solution as found in two patches linked here:
> https://lists.opensuse.org/opensuse-arm/2020-09/msg00008.html
> https://lists.opensuse.org/opensuse-arm/2020-09/msg00024.html
> 
> Could you help getting them upstream?

I'll have a look!
Comment 20 Guillaume GARDET 2021-02-16 07:54:00 UTC
(In reply to Matthias Brugger from comment #19)
> (In reply to Ludwig Nussel from comment #18)
> > So the solution as found in two patches linked here:
> > https://lists.opensuse.org/opensuse-arm/2020-09/msg00008.html
> > https://lists.opensuse.org/opensuse-arm/2020-09/msg00024.html
> > 
> > Could you help getting them upstream?
> 
> I'll have a look!

@Matthias, did you upstream those 2 patches?
Comment 21 Matthias Brugger 2021-02-16 08:35:53 UTC
(In reply to Guillaume GARDET from comment #20)
> (In reply to Matthias Brugger from comment #19)
> > (In reply to Ludwig Nussel from comment #18)
> > > So the solution as found in two patches linked here:
> > > https://lists.opensuse.org/opensuse-arm/2020-09/msg00008.html
> > > https://lists.opensuse.org/opensuse-arm/2020-09/msg00024.html
> > > 
> > > Could you help getting them upstream?
> > 
> > I'll have a look!
> 
> @Matthias, did you upstream those 2 patches?

Unfortunately not. Up to now I wasn't able to find a way to implement this on the chip level. On of the patches change the usb keyboard implementation which will break USB on other RPi's. I'll have to have a deeper look. I think now I'll find more time to do so.
Comment 22 Stefan Brüns 2021-02-20 19:57:22 UTC
I have just submitted the patch for interrupt out endpoints upstream. This should fix the issue of Linux gadget keyboard being rejected (which does affect any DUT which uses u-boot, not only RPIs).

With this accepted, you should be able to use and Rpi3 as KVM (Linux gadget keyboard) and e.g. a Pine64 as DUT (which uses interrupts for transfers) or maybe an Rpi4 (which has as XHCI controller and not the awkward DWC2).


@lnussel:
For the missing/incomplete support of the SetIdle request by the gadget support, I think you can/have to implement that in userspace. Taking the code from https://www.kernel.org/doc/Documentation/usb/gadget_hid.txt , just add a 500ms timeout to the select() loop and send the last report again.