Hi Simon,

is your testing framework connected to HDMI? Only notable discrepancy from generic config is enabled 'efidebug' command.

Tested more (cycled 'U-Boot>' and 'reset'), both RPi3B and RPi3B+.. USB Keyboard failure rates: connected console 02/10 connected hdmi 06/10 connected console + hdmi 07/10 ** USB Keyboard always detected by 'usb info', just does not respond.

USB Keyboard failure rates, reverted 96991e652f541323a03c5b7e075d54a117091618: connected console + hdmi 00/10

Just to note subsequent Grub2 menu redraw to my 180x50 console terminal is about 5x faster when hdmi disconnected.

Thanks for testing! Regards, Filip

FW: rpi-firmware-20220830-1.0.1.el8.noarch Revision: 9bd3d354a1a0712ac27c717df9ad60566b0406ee

On 12/17/22 23:24, Simon Glass wrote:

Hi Filip,

On Sat, 17 Dec 2022 at 05:50, Filip Žaludek filip.zaludek@oracle.com wrote:

...

Hello, change seems to be unfriendly to RPi3B+, it allows to enter 'U-Boot>' shell but usb keyboard does not respond. Keyboard is detected by 'usb info' in v2023.01-rc3, not in v2022.10. When reverted, usb keyboard works as expected.

Anybody sitting front of RPi3B+ care to confirm?

Regards, Filip

Patch: https://urldefense.com/v3/__https://github.com/u-boot/u-boot/commit/96991e65...

Debug: USB KBD: found interrupt EP: 0x81 USB KBD: set boot protocol dwc2_submit_control_msg: dev='usb@7e980000', udev=000000003af4be00, udev->dev='usb_kbd', portnr=3 USB KBD: set idle interval... dwc2_submit_control_msg: dev='usb@7e980000', udev=000000003af4be00, udev->dev='usb_kbd', portnr=3 USB KBD: enable interrupt pipe... usb_kbd usb_kbd: Timeout poll on interrupt endpoint

Tested: SW: v2022.10 & v2023.01-rc3 compiled from sources as 'rpiarm64' HW: USB 1.1 and 2.0 keyboards, RPi3B+ JeOS: https://urldefense.com/v3/__http://download.opensuse.org/ports/aarch64/tumbl... (u-boot-rpiarm64-2022.10-1.1.aarch64)

This seems to work on current master:

do-try-int.sh rpi3 Revision 9bd3d354a1a0712ac27c717df9ad60566b0406ee, board rpi3

Checking revision 9bd3d354a1a0712ac27c717df9ad60566b0406ee /vid/software/devel/ubtest tbot starting ... ├─Parameters: │ rev = '9bd3d354a1a0712ac27c717df9ad60566b0406ee' │ clean = False ├─Calling uboot_build_and_flash ... │ ├─Calling uboot_build ... │ │ ├─Calling uboot_checkout ... │ │ │ ├─Builder: rpi3 │ │ │ └─Done. (0.181s) │ │ ├─Configuring build ... │ │ ├─Calling uboot_make ... │ │ │ └─Done. (1.504s) │ │ └─Done. (2.178s) │ ├─Calling uboot_flash ... │ │ ├─Calling copy ... │ │ │ └─Done. (0.004s) │ │ └─Done. (1.119s) │ └─Done. (3.663s) ├───────────────────────────────────────── └─SUCCESS (3.799s) tbot starting ... ├─Calling interactive_board ... │ ├─POWERON (rpi3) │ ├─Entering interactive shell (CTRL+D to exit) ...

U-Boot 2023.01-rc3-00057-g9bd3d354a1a (Dec 17 2022 - 15:23:14 -0700)

DRAM: 992 MiB RPI 3 Model B (0xa22082) Core: 66 devices, 14 uclasses, devicetree: embed MMC: mmc@7e202000: 0, mmc@7e300000: 1 Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In: serial Out: vidconsole Err: vidconsole Net: No ethernet found. starting USB... Bus usb@7e980000: USB DWC2 scanning bus usb@7e980000 for devices... usb_kbd usb_kbd: Timeout poll on interrupt endpoint Failed to get keyboard state from device 0c40:8000 6 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 0 U-Boot> usb info 1: Hub, USB Revision 1.10

• U-Boot Root Hub
• Class: Hub
• PacketSize: 8 Configurations: 1
• Vendor: 0x0000 Product 0x0000 Version 0.0 Configuration: 1
  • Interfaces: 1 Self Powered 0mA Interface: 0
    • Alternate Setting 0, Endpoints: 1
    • Class Hub
    • Endpoint 1 In Interrupt MaxPacket 2 Interval 255ms

2: Hub, USB Revision 2.0

• Class: Hub
• PacketSize: 64 Configurations: 1
• Vendor: 0x0424 Product 0x9514 Version 2.0 Configuration: 1
  • Interfaces: 1 Self Powered Remote Wakeup 2mA Interface: 0
    • Alternate Setting 0, Endpoints: 1
    • Class Hub
    • Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
    • Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms

3: Human Interface, USB Revision 1.10

• Logitech USB Keyboard
• Class: (from Interface) Human Interface
• PacketSize: 8 Configurations: 1
• Vendor: 0x046d Product 0xc31c Version 100.0 Configuration: 1
  • Interfaces: 2 Bus Powered Remote Wakeup 90mA
  • String: "U64.00_B0001" Interface: 0
    • Alternate Setting 0, Endpoints: 1
    • Class Human Interface, Subclass: Boot Keyboard
    • String: "USB Keyboard"
    • Endpoint 1 In Interrupt MaxPacket 8 Interval 10ms
    Interface: 1
    • Alternate Setting 0, Endpoints: 1
    • Class Human Interface, Subclass: None
    • String: "USB Keyboard"
    • Endpoint 2 In Interrupt MaxPacket 4 Interval 255ms

4: Human Interface, USB Revision 0.1

• QDtech MPI5001 ?
• Class: (from Interface) Human Interface
• PacketSize: 64 Configurations: 1
• Vendor: 0x0483 Product 0x5750 Version 2.0 Configuration: 1
  • Interfaces: 1 Bus Powered 64mA Interface: 0
    • Alternate Setting 0, Endpoints: 1
    • Class Human Interface, Subclass: None
    • Endpoint 2 In Interrupt MaxPacket 64 Interval 1ms
    • Endpoint 2 Out Interrupt MaxPacket 64 Interval 1ms

5: Vendor specific, USB Revision 2.0

• Class: Vendor specific
• PacketSize: 64 Configurations: 1
• Vendor: 0x0424 Product 0xec00 Version 2.0 Configuration: 1
  • Interfaces: 1 Self Powered Remote Wakeup 2mA Interface: 0
    • Alternate Setting 0, Endpoints: 3
    • Class Vendor specific
    • Endpoint 1 In Bulk MaxPacket 512
    • Endpoint 2 Out Bulk MaxPacket 512
    • Endpoint 3 In Interrupt MaxPacket 16 Interval 4ms

6: Mass Storage, USB Revision 2.10

• SanDisk USB Extreme Pro 513456791960
• Class: (from Interface) Mass Storage
• PacketSize: 64 Configurations: 1
• Vendor: 0x0781 Product 0x5588 Version 1.0 Configuration: 1
  • Interfaces: 1 Self Powered 0mA Interface: 0
    • Alternate Setting 0, Endpoints: 2
    • Class Mass Storage, Transp. SCSI, Bulk only
    • Endpoint 1 In Bulk MaxPacket 512
    • Endpoint 2 Out Bulk MaxPacket 512

U-Boot> hello Unknown command 'hello' - try 'help' U-Boot> │ ├─POWEROFF (rpi3) │ ├─Exiting poweroff │ └─Done. (34.381s) ├───────────────────────────────────────── └─SUCCESS (34.481s)

(the 'hello' is typed on the keyboard)

Regards, Simon

Hi Simon,

On 12/19/22 20:20, Simon Glass wrote:

Hi Filip,

On Mon, 19 Dec 2022 at 02:29, Filip Žaludek filip.zaludek@oracle.com wrote:

...

Hi Simon,

is your testing framework connected to HDMI? Only notable discrepancy from generic config is enabled 'efidebug' command.

Tested more (cycled 'U-Boot>' and 'reset'), both RPi3B and RPi3B+.. USB Keyboard failure rates: connected console 02/10 connected hdmi 06/10 connected console + hdmi 07/10 ** USB Keyboard always detected by 'usb info', just does not respond.

USB Keyboard failure rates, reverted 96991e652f541323a03c5b7e075d54a117091618: connected console + hdmi 00/10

Yes this one does have HDMI. Are you wanting me to run multiple runs? With or without the display?

Yes please! With HDMI as there is better chance you will hit issue I am experiencing, to confirm 96991e652f541323a03c5b7e075d54a117091618 is inferior for RPi3. You should see usb_kbd detected, but no input possible.

Thanks, Filip

Regards, Simon

...

Just to note subsequent Grub2 menu redraw to my 180x50 console terminal is about 5x faster when hdmi disconnected.

Thanks for testing! Regards, Filip

FW: rpi-firmware-20220830-1.0.1.el8.noarch Revision: 9bd3d354a1a0712ac27c717df9ad60566b0406ee

On 12/17/22 23:24, Simon Glass wrote:

...

Hi Filip,

On Sat, 17 Dec 2022 at 05:50, Filip Žaludek filip.zaludek@oracle.com wrote:

...

Hello, change seems to be unfriendly to RPi3B+, it allows to enter 'U-Boot>' shell but usb keyboard does not respond. Keyboard is detected by 'usb info' in v2023.01-rc3, not in v2022.10. When reverted, usb keyboard works as expected.

Anybody sitting front of RPi3B+ care to confirm?

Regards, Filip

Patch: https://urldefense.com/v3/__https://github.com/u-boot/u-boot/commit/96991e65...

Debug: USB KBD: found interrupt EP: 0x81 USB KBD: set boot protocol dwc2_submit_control_msg: dev='usb@7e980000', udev=000000003af4be00, udev->dev='usb_kbd', portnr=3 USB KBD: set idle interval... dwc2_submit_control_msg: dev='usb@7e980000', udev=000000003af4be00, udev->dev='usb_kbd', portnr=3 USB KBD: enable interrupt pipe... usb_kbd usb_kbd: Timeout poll on interrupt endpoint

Tested: SW: v2022.10 & v2023.01-rc3 compiled from sources as 'rpiarm64' HW: USB 1.1 and 2.0 keyboards, RPi3B+ JeOS: https://urldefense.com/v3/__http://download.opensuse.org/ports/aarch64/tumbl... (u-boot-rpiarm64-2022.10-1.1.aarch64)

This seems to work on current master:

do-try-int.sh rpi3 Revision 9bd3d354a1a0712ac27c717df9ad60566b0406ee, board rpi3

Checking revision 9bd3d354a1a0712ac27c717df9ad60566b0406ee /vid/software/devel/ubtest tbot starting ... ├─Parameters: │ rev = '9bd3d354a1a0712ac27c717df9ad60566b0406ee' │ clean = False ├─Calling uboot_build_and_flash ... │ ├─Calling uboot_build ... │ │ ├─Calling uboot_checkout ... │ │ │ ├─Builder: rpi3 │ │ │ └─Done. (0.181s) │ │ ├─Configuring build ... │ │ ├─Calling uboot_make ... │ │ │ └─Done. (1.504s) │ │ └─Done. (2.178s) │ ├─Calling uboot_flash ... │ │ ├─Calling copy ... │ │ │ └─Done. (0.004s) │ │ └─Done. (1.119s) │ └─Done. (3.663s) ├───────────────────────────────────────── └─SUCCESS (3.799s) tbot starting ... ├─Calling interactive_board ... │ ├─POWERON (rpi3) │ ├─Entering interactive shell (CTRL+D to exit) ...

U-Boot 2023.01-rc3-00057-g9bd3d354a1a (Dec 17 2022 - 15:23:14 -0700)

DRAM: 992 MiB RPI 3 Model B (0xa22082) Core: 66 devices, 14 uclasses, devicetree: embed MMC: mmc@7e202000: 0, mmc@7e300000: 1 Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In: serial Out: vidconsole Err: vidconsole Net: No ethernet found. starting USB... Bus usb@7e980000: USB DWC2 scanning bus usb@7e980000 for devices... usb_kbd usb_kbd: Timeout poll on interrupt endpoint Failed to get keyboard state from device 0c40:8000 6 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found Hit any key to stop autoboot: 0 U-Boot> usb info 1: Hub, USB Revision 1.10

• U-Boot Root Hub
• Class: Hub
• PacketSize: 8 Configurations: 1
• Vendor: 0x0000 Product 0x0000 Version 0.0 Configuration: 1
  • Interfaces: 1 Self Powered 0mA Interface: 0
    • Alternate Setting 0, Endpoints: 1
    • Class Hub
    • Endpoint 1 In Interrupt MaxPacket 2 Interval 255ms

2: Hub, USB Revision 2.0

• Class: Hub
• PacketSize: 64 Configurations: 1
• Vendor: 0x0424 Product 0x9514 Version 2.0 Configuration: 1
  • Interfaces: 1 Self Powered Remote Wakeup 2mA Interface: 0
    • Alternate Setting 0, Endpoints: 1
    • Class Hub
    • Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms
    • Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms

3: Human Interface, USB Revision 1.10

• Logitech USB Keyboard
• Class: (from Interface) Human Interface
• PacketSize: 8 Configurations: 1
• Vendor: 0x046d Product 0xc31c Version 100.0 Configuration: 1
  • Interfaces: 2 Bus Powered Remote Wakeup 90mA
  • String: "U64.00_B0001" Interface: 0
    • Alternate Setting 0, Endpoints: 1
    • Class Human Interface, Subclass: Boot Keyboard
    • String: "USB Keyboard"
    • Endpoint 1 In Interrupt MaxPacket 8 Interval 10ms
    Interface: 1
    • Alternate Setting 0, Endpoints: 1
    • Class Human Interface, Subclass: None
    • String: "USB Keyboard"
    • Endpoint 2 In Interrupt MaxPacket 4 Interval 255ms

4: Human Interface, USB Revision 0.1

• QDtech MPI5001 ?
• Class: (from Interface) Human Interface
• PacketSize: 64 Configurations: 1
• Vendor: 0x0483 Product 0x5750 Version 2.0 Configuration: 1
  • Interfaces: 1 Bus Powered 64mA Interface: 0
    • Alternate Setting 0, Endpoints: 1
    • Class Human Interface, Subclass: None
    • Endpoint 2 In Interrupt MaxPacket 64 Interval 1ms
    • Endpoint 2 Out Interrupt MaxPacket 64 Interval 1ms

5: Vendor specific, USB Revision 2.0

• Class: Vendor specific
• PacketSize: 64 Configurations: 1
• Vendor: 0x0424 Product 0xec00 Version 2.0 Configuration: 1
  • Interfaces: 1 Self Powered Remote Wakeup 2mA Interface: 0
    • Alternate Setting 0, Endpoints: 3
    • Class Vendor specific
    • Endpoint 1 In Bulk MaxPacket 512
    • Endpoint 2 Out Bulk MaxPacket 512
    • Endpoint 3 In Interrupt MaxPacket 16 Interval 4ms

6: Mass Storage, USB Revision 2.10

• SanDisk USB Extreme Pro 513456791960
• Class: (from Interface) Mass Storage
• PacketSize: 64 Configurations: 1
• Vendor: 0x0781 Product 0x5588 Version 1.0 Configuration: 1
  • Interfaces: 1 Self Powered 0mA Interface: 0
    • Alternate Setting 0, Endpoints: 2
    • Class Mass Storage, Transp. SCSI, Bulk only
    • Endpoint 1 In Bulk MaxPacket 512
    • Endpoint 2 Out Bulk MaxPacket 512

U-Boot> hello Unknown command 'hello' - try 'help' U-Boot> │ ├─POWEROFF (rpi3) │ ├─Exiting poweroff │ └─Done. (34.381s) ├───────────────────────────────────────── └─SUCCESS (34.481s)

(the 'hello' is typed on the keyboard)

Regards, Simon

Hi Filip,

On Wed, 18 Jan 2023 at 09:03, Filip Žaludek filip.zaludek@oracle.com wrote:

Hi Michal,

thanks for testing! Do you consider keyboard as working once it is detected without 'usb_kbd usb_kbd: Timeout poll on interrupt endpoint', or judging from subsequent typing? Note that issue is reproducible only in about 20% of reboots. For me I can always enter 'U-Boot>' shell, but then keyboard usually does not work. And yes, resetting the usb controller with pressing a key afterwards will finally break the keyboard. ('usb reset' typed from keyboard) If you are Prague located I am ready to demonstrate what I am talking about.

Simon's keyboard detection is somewhat interfered by 'SanDisk USB Extreme Pro' detection, printed complaints but keyboard still works.. 'usb_kbd usb_kbd: Timeout poll on interrupt endpoint' and 'Failed to get keyboard state from device 0c40:8000' Btw. why from 0c40:8000 (ELMCU 2.4GHz receiver) when wired keyboard is 046d:c31c (Logitech Keyboard K120)?

What is supposed scenario for RPi3/u-boot/grub usb keyboard equipped users wanting to boot non-default? Enter 'U-Boot>' shell to detect keyboard; type boot; select desired grub entry..?

Reverting either from the two makes it non issue for me: 'dwc2: use the nonblock argument in submit_int_msg' commit 9dcab2c4d2cb50ab1864c818b82a72393c160236

'console: usb: kbd: Limit poll frequency to improve performance' commit 96991e652f541323a03c5b7e075d54a117091618

What will be attitude on this, should we try to bring workaround preserving both patches?

(please try to avoid top-posting)

You can use a USB quirk to handle this.

Marek do you have any thoughts here?

Regards, Simon

Regards, Filip

On 1/17/23 19:46, Michal Suchánek wrote:

...

Hello,

On Sat, Dec 17, 2022 at 01:49:47PM +0100, Filip Žaludek wrote:

...

Hello, change seems to be unfriendly to RPi3B+, it allows to enter 'U-Boot>' shell but usb keyboard does not respond. Keyboard is detected by 'usb info' in v2023.01-rc3, not in v2022.10. When reverted, usb keyboard works as expected.

Anybody sitting front of RPi3B+ care to confirm?

For me an USB keyboard connected to a Raspberry Pi 3B+ is only detected when something is typed during the probe.

The message

usb_kbd usb_kbd: Timeout poll on interrupt endpoint

is a sign of nothing typed on the keyboard and then it does not work.

It is limitation of the dwc2 hardware with hardwired USB hub.

Same on both v2022.10 & v2023.01 rpiarm64 and rpi_3 configs.

Thanks

Michal

...

Regards, Filip

Patch: https://urldefense.com/v3/__https://github.com/u-boot/u-boot/commit/96991e65...

Debug: USB KBD: found interrupt EP: 0x81 USB KBD: set boot protocol dwc2_submit_control_msg: dev='usb@7e980000', udev=000000003af4be00, udev->dev='usb_kbd', portnr=3 USB KBD: set idle interval... dwc2_submit_control_msg: dev='usb@7e980000', udev=000000003af4be00, udev->dev='usb_kbd', portnr=3 USB KBD: enable interrupt pipe... usb_kbd usb_kbd: Timeout poll on interrupt endpoint

Tested: SW: v2022.10 & v2023.01-rc3 compiled from sources as 'rpiarm64' HW: USB 1.1 and 2.0 keyboards, RPi3B+ JeOS: https://urldefense.com/v3/__http://download.opensuse.org/ports/aarch64/tumbl... (u-boot-rpiarm64-2022.10-1.1.aarch64)

Date: Wed, 8 Feb 2023 19:45:36 +0100 From: Michal Suchánek msuchanek@suse.de

Hello,

On Wed, Jan 18, 2023 at 05:01:12PM +0100, Filip Žaludek wrote:

...

Hi Michal,

thanks for testing! Do you consider keyboard as working once it is detected without 'usb_kbd usb_kbd: Timeout poll on interrupt endpoint', or judging from subsequent typing? Note that issue is reproducible only in about 20% of reboots.

I rely on keyboard input to boot so if it was 20% broken I would notice. I don't use the rPi all that much so if it was broken only a few % of the time there is a chance I would miss it.

However, for me not typing on the keyboard during usb detection it is 100% not detected, typing on it during usb detection it is 100% detected.

The timeout is limitation of the dwc2 controller handling of usb hubs.

There might be a possibility to improve the driver so that it handles the condition but it might be that the Linux driver relies on a separate thread handling the controller which is not acceptable for u-boot.

I am not usb expert and definitely not dwc2 expert so I cannot do more than workaround the current driver limitation.

...

For me I can always enter 'U-Boot>' shell, but then keyboard usually does not work. And yes, resetting the usb controller with pressing a key afterwards will finally break the keyboard. ('usb reset' typed from keyboard) If you are Prague located I am ready to demonstrate what I am talking about.

Simon's keyboard detection is somewhat interfered by 'SanDisk USB Extreme Pro' detection, printed complaints but keyboard still works.. 'usb_kbd usb_kbd: Timeout poll on interrupt endpoint' and 'Failed to get keyboard state from device 0c40:8000' Btw. why from 0c40:8000 (ELMCU 2.4GHz receiver) when wired keyboard is 046d:c31c (Logitech Keyboard K120)?

What is supposed scenario for RPi3/u-boot/grub usb keyboard equipped users wanting to boot non-default? Enter 'U-Boot>' shell to detect keyboard; type boot; select desired grub entry..?

Reverting either from the two makes it non issue for me: 'dwc2: use the nonblock argument in submit_int_msg' commit 9dcab2c4d2cb50ab1864c818b82a72393c160236

Without this booting from USB is not feasible because reading every block from the USB drive waits for the keyboard to time out.

...

'console: usb: kbd: Limit poll frequency to improve performance' commit 96991e652f541323a03c5b7e075d54a117091618

No idea about this one, for me it doea not give any substantial difference in behavior.

Reverting that commit leads to a significant slowdown loading a kernel from disk with a usb keyboard connected. The slowdown is somewhat hardware dependent but on some systems loading the OpenBSD/arm64 kernel would take minutes instead of seconds.

Hi Filip,

On Tue, 11 Apr 2023 at 14:24, Filip Žaludek filip.zaludek@oracle.com wrote:

On 2/8/23 20:01, Mark Kettenis wrote:

...

...

Date: Wed, 8 Feb 2023 19:45:36 +0100 From: Michal Suchánek msuchanek@suse.de

Hello,

On Wed, Jan 18, 2023 at 05:01:12PM +0100, Filip Žaludek wrote:

...

Hi Michal,

thanks for testing! Do you consider keyboard as working once it is detected without 'usb_kbd usb_kbd: Timeout poll on interrupt endpoint', or judging from subsequent typing? Note that issue is reproducible only in about 20% of reboots.

I rely on keyboard input to boot so if it was 20% broken I would notice. I don't use the rPi all that much so if it was broken only a few % of the time there is a chance I would miss it.

However, for me not typing on the keyboard during usb detection it is 100% not detected, typing on it during usb detection it is 100% detected.

The timeout is limitation of the dwc2 controller handling of usb hubs.

There might be a possibility to improve the driver so that it handles the condition but it might be that the Linux driver relies on a separate thread handling the controller which is not acceptable for u-boot.

I am not usb expert and definitely not dwc2 expert so I cannot do more than workaround the current driver limitation.

...

For me I can always enter 'U-Boot>' shell, but then keyboard usually does not work. And yes, resetting the usb controller with pressing a key afterwards will finally break the keyboard. ('usb reset' typed from keyboard) If you are Prague located I am ready to demonstrate what I am talking about.

Simon's keyboard detection is somewhat interfered by 'SanDisk USB Extreme Pro' detection, printed complaints but keyboard still works.. 'usb_kbd usb_kbd: Timeout poll on interrupt endpoint' and 'Failed to get keyboard state from device 0c40:8000' Btw. why from 0c40:8000 (ELMCU 2.4GHz receiver) when wired keyboard is 046d:c31c (Logitech Keyboard K120)?

What is supposed scenario for RPi3/u-boot/grub usb keyboard equipped users wanting to boot non-default? Enter 'U-Boot>' shell to detect keyboard; type boot; select desired grub entry..?

Reverting either from the two makes it non issue for me: 'dwc2: use the nonblock argument in submit_int_msg' commit 9dcab2c4d2cb50ab1864c818b82a72393c160236

Without this booting from USB is not feasible because reading every block from the USB drive waits for the keyboard to time out.

...

'console: usb: kbd: Limit poll frequency to improve performance' commit 96991e652f541323a03c5b7e075d54a117091618

No idea about this one, for me it doea not give any substantial difference in behavior.

Reverting that commit leads to a significant slowdown loading a kernel from disk with a usb keyboard connected. The slowdown is somewhat hardware dependent but on some systems loading the OpenBSD/arm64 kernel would take minutes instead of seconds.

Hello, I am about to dig more into this issue with proper tools, but failed to configure/compile trace functionality on RPi3 due to missing references to timer_early_get_count() and timer_early_get_rate().

You could implement a proper timer driver for rpi.

Is it possible/feasible to implement calls in CONFIG_SYS_ARCH_TIMER and/or CONFIG_SP804_TIMER?

Yes

I would be grateful even for trace to generate function traces without timestamps. Is such nasty hack without timestamping supposed to work? Basically my intention is to trace 'usb reset'.

Appreciate any hints/outlines how to proceed.

I assume you mean CONFIG_TRACE. Yes, you could update it to support writing a zero timestamp. See the add_ftrace() function.

But better to add a driver if you can. It should not be difficult.

Regards, Simon

Hi Filip,

On Tue, 25 Apr 2023 at 06:36, Filip Žaludek filip.zaludek@oracle.com wrote:

Hi Simon,

On 4/19/23 03:49, Simon Glass wrote:

...

Hi Filip,

On Tue, 11 Apr 2023 at 14:24, Filip Žaludek filip.zaludek@oracle.com wrote:

...

On 2/8/23 20:01, Mark Kettenis wrote:

...

...

Date: Wed, 8 Feb 2023 19:45:36 +0100 From: Michal Suchánek msuchanek@suse.de

Hello,

On Wed, Jan 18, 2023 at 05:01:12PM +0100, Filip Žaludek wrote:

...

Hi Michal,

thanks for testing! Do you consider keyboard as working once it is detected without 'usb_kbd usb_kbd: Timeout poll on interrupt endpoint', or judging from subsequent typing? Note that issue is reproducible only in about 20% of reboots.

I rely on keyboard input to boot so if it was 20% broken I would notice. I don't use the rPi all that much so if it was broken only a few % of the time there is a chance I would miss it.

However, for me not typing on the keyboard during usb detection it is 100% not detected, typing on it during usb detection it is 100% detected.

The timeout is limitation of the dwc2 controller handling of usb hubs.

There might be a possibility to improve the driver so that it handles the condition but it might be that the Linux driver relies on a separate thread handling the controller which is not acceptable for u-boot.

I am not usb expert and definitely not dwc2 expert so I cannot do more than workaround the current driver limitation.

...

For me I can always enter 'U-Boot>' shell, but then keyboard usually does not work. And yes, resetting the usb controller with pressing a key afterwards will finally break the keyboard. ('usb reset' typed from keyboard) If you are Prague located I am ready to demonstrate what I am talking about.

Simon's keyboard detection is somewhat interfered by 'SanDisk USB Extreme Pro' detection, printed complaints but keyboard still works.. 'usb_kbd usb_kbd: Timeout poll on interrupt endpoint' and 'Failed to get keyboard state from device 0c40:8000' Btw. why from 0c40:8000 (ELMCU 2.4GHz receiver) when wired keyboard is 046d:c31c (Logitech Keyboard K120)?

What is supposed scenario for RPi3/u-boot/grub usb keyboard equipped users wanting to boot non-default? Enter 'U-Boot>' shell to detect keyboard; type boot; select desired grub entry..?

Reverting either from the two makes it non issue for me: 'dwc2: use the nonblock argument in submit_int_msg' commit 9dcab2c4d2cb50ab1864c818b82a72393c160236

Without this booting from USB is not feasible because reading every block from the USB drive waits for the keyboard to time out.

...

'console: usb: kbd: Limit poll frequency to improve performance' commit 96991e652f541323a03c5b7e075d54a117091618

No idea about this one, for me it doea not give any substantial difference in behavior.

Reverting that commit leads to a significant slowdown loading a kernel from disk with a usb keyboard connected. The slowdown is somewhat hardware dependent but on some systems loading the OpenBSD/arm64 kernel would take minutes instead of seconds.

Hello, I am about to dig more into this issue with proper tools, but failed to configure/compile trace functionality on RPi3 due to missing references to timer_early_get_count() and timer_early_get_rate().

You could implement a proper timer driver for rpi.

...

Is it possible/feasible to implement calls in CONFIG_SYS_ARCH_TIMER and/or CONFIG_SP804_TIMER?

Yes

I am little bit missing here secret sauce, timer_early_get_count() and timer_early_get_rate() are not supposed to be implemented in arch/arm/cpu/armv8/generic_timer.c? But predestined for drivers/timer/sp804_timer.c?

TIMER is required for common/board_f.c and common/board_r.c but it disables generic_timer.. %< ----------------------------------------- ifndef CONFIG_$(SPL_TPL_)TIMER obj-$(CONFIG_SYS_ARCH_TIMER) += generic_timer.o endif %< ----------------------------------------- And obviously multiple definition of get_tbclk and get_ticks when forced to compile/link.

It seems from the above that if TIMER is enabled for a particular U-Boot build phase, then generic_timer is not, and vice versa. I suppose that is fair enough.

...

...

I would be grateful even for trace to generate function traces without timestamps. Is such nasty hack without timestamping supposed to work? Basically my intention is to trace 'usb reset'.

Appreciate any hints/outlines how to proceed.

I assume you mean CONFIG_TRACE. Yes, you could update it to support writing a zero timestamp. See the add_ftrace() function.

But better to add a driver if you can. It should not be difficult.

Regards, Simon

I am already happily timestamp tracing with borrowed functionality from generic_timer.c, albeit bypassing kbuild mechanism. It did not yet answered my usb polling questions, tracing report is polluted/overfilled.

Instrumenting code thoughts:

• It would be handy to -finstrument-functions only for desired objects.

The compiler probably doesn't support that, or at least we don't support passing different compiler args to each file in U-Boot, other than by manually hacking the Makefiles.

But I wonder if we could have a list of wildcards to match against the function names?

• It would be handy to have macro inverse to 'notrace' to mark only desired functions. Feasible?
• gcc -finstrument-functions-exclude-file-list still pollutes tracing buffer.

I wonder why? You could check whether the filename includes a full path, or something like that, so that it doesn't match. There will be a reason.

More Tracing in U-Boot thoughts:

• There is proftool options discrepancy, documented {-c, -f, -m, -o, -t, -v}, implemented {-m, -p, -t, -v}.
• Both types FUNCF_ENTRY and FUNCF_EXIT are marked as " <- " by proftool.

Yes, please send a patch or two to clean these up.

Regards, Simon

Hi,

On 2/8/23 19:45, Michal Suchánek wrote:

Hello,

On Wed, Jan 18, 2023 at 05:01:12PM +0100, Filip Žaludek wrote:

...

Hi Michal,

thanks for testing! Do you consider keyboard as working once it is detected without 'usb_kbd usb_kbd: Timeout poll on interrupt endpoint', or judging from subsequent typing? Note that issue is reproducible only in about 20% of reboots.

I rely on keyboard input to boot so if it was 20% broken I would notice. I don't use the rPi all that much so if it was broken only a few % of the time there is a chance I would miss it.

Common denominator here is most likely dwc2 controller on RPi3.

However, for me not typing on the keyboard during usb detection it is 100% not detected, typing on it during usb detection it is 100% detected.

There are 3 states: Keyboard not detected, keyboard detected but does not work, keyboard detected and works.

If keyboard is not detected/does not work then subsequent grub timeout is misleading/pointless..

The timeout is limitation of the dwc2 controller handling of usb hubs.

Michal, can you please elaborate more [pointers to docs, discussions] why/how is the timeout limitation of the dwc2 controller handling of usb hubs? I am trying to dissect it more by printing single character from myriad of places what actually works as a workaround, but when substituting with mdelay(x) exceeding printing does not. [common/usb.c, common/usb_hub.c, drivers/core/device.c, drivers/usb/host/dwc2.c, drivers/usb/host/usb-uclass.c]

Thanks, Filip

There might be a possibility to improve the driver so that it handles the condition but it might be that the Linux driver relies on a separate thread handling the controller which is not acceptable for u-boot.

I am not usb expert and definitely not dwc2 expert so I cannot do more than workaround the current driver limitation.

...

For me I can always enter 'U-Boot>' shell, but then keyboard usually does not work. And yes, resetting the usb controller with pressing a key afterwards will finally break the keyboard. ('usb reset' typed from keyboard) If you are Prague located I am ready to demonstrate what I am talking about.

Simon's keyboard detection is somewhat interfered by 'SanDisk USB Extreme Pro' detection, printed complaints but keyboard still works.. 'usb_kbd usb_kbd: Timeout poll on interrupt endpoint' and 'Failed to get keyboard state from device 0c40:8000' Btw. why from 0c40:8000 (ELMCU 2.4GHz receiver) when wired keyboard is 046d:c31c (Logitech Keyboard K120)?

What is supposed scenario for RPi3/u-boot/grub usb keyboard equipped users wanting to boot non-default? Enter 'U-Boot>' shell to detect keyboard; type boot; select desired grub entry..?

Reverting either from the two makes it non issue for me: 'dwc2: use the nonblock argument in submit_int_msg' commit 9dcab2c4d2cb50ab1864c818b82a72393c160236

Without this booting from USB is not feasible because reading every block from the USB drive waits for the keyboard to time out.

...

'console: usb: kbd: Limit poll frequency to improve performance' commit 96991e652f541323a03c5b7e075d54a117091618

No idea about this one, for me it doea not give any substantial difference in behavior.

Thanks

Michal