Re: RPi Zero 2 W usb keyboard support?
Hi Peter, On 8/22/23 13:00, Peter Robinson wrote: Hi, Hi, is supposed usb keyboard to work in u-boot 2023.04 on RPi Zero 2 W? Configured as rpi_arm64_defconfig, no usb devices found but subsequent kernel works as expected. [pi02] kernel=u-boot.bin otg_mode=0 dtoverlay=dwc2,dr_mode=host Hello, I see, increasing usb_pgood_delay makes the trick. I wonder if it's device specific, my Logitech wireless keyboard is detected with the defaults: U-Boot> USB device tree: 1 Hub (480 Mb/s, 0mA) | U-Boot Root Hub | +-2 Human Interface (12 Mb/s, 98mA) Logitech USB Receiver Yes, seems to be device specific, it is also sensitive to OTG adaptor used.. Notes: (no usb_pgood_delay adjustments) Linux 5.15.0: * all the adaptors vs keyboards works U-boot 2023.04: (+works, -does not) * k1_a1- k1_a2+ // workaround usb_pgood_delay=1000 * k2_a1- k2_a2- // 'usb tree' detected but does not work * k3_a1+ k3_a2+ Keyboards: k1/ Bus 001 Device 003: ID 17ef:6099 Lenovo Lenovo Traditional USB Keyboard, bcdUSB 1.10, bcdDevice 1.10, bcdHID 1.10 k2/ Bus 001 Device 002: ID 03f0:0024 HP, Inc KU-0316 Keyboard, bcdUSB 2.00, bcdDevice 1.30, bcdHID 1.11 k3/ Bus 001 Device 002: ID 04f2:0116 Chicony Electronics Co., Ltd KU-2971/KU-0325 Keyboard, bcdUSB 1.10, bcdDevice 3.00, bcdHID 1.10 OTG Adaptors: a1/ The PiHut, USB to microUSB OTG Shim https://urldefense.com/v3/__https://rpishop.cz/datove-redukce/4365-prevodnik-usb-na-microusb-otg-shim.html__;!!ACWV5N9M2RV99hQ!JIFzwzVvSSXpR2n_vV5USgKPkbrvI1VtCWDO4eKbLaT4RVHAtvawPy76faXmhOJ33tUlx9_TtwkHgiewJKqAUapuqEk$ a2/ USB 2.0 Hi-Speed 0,2m OTG adaptér https://urldefense.com/v3/__https://rpishop.cz/datove-redukce/580-usb-20-hi-speed-02m-otg-adapter.html__;!!ACWV5N9M2RV99hQ!JIFzwzVvSSXpR2n_vV5USgKPkbrvI1VtCWDO4eKbLaT4RVHAtvawPy76faXmhOJ33tUlx9_TtwkHgiewJKqAYbCSmmM$ Sorry, I get lost with so many devices. To conclude my experiments.. All the permutations works in Linux 5.15.0, testing is OTG adapter agnostic. USB 2.0 keyboard does not work. Some of USB 1.1 keyboards work out of the box, some with usb_pgood_delay=1000 workaround. Filip
Re: RPi Zero 2 W usb keyboard support?
Hi Peter, On 8/22/23 13:00, Peter Robinson wrote: Hi, Hi, is supposed usb keyboard to work in u-boot 2023.04 on RPi Zero 2 W? Configured as rpi_arm64_defconfig, no usb devices found but subsequent kernel works as expected. [pi02] kernel=u-boot.bin otg_mode=0 dtoverlay=dwc2,dr_mode=host Hello, I see, increasing usb_pgood_delay makes the trick. I wonder if it's device specific, my Logitech wireless keyboard is detected with the defaults: U-Boot> USB device tree: 1 Hub (480 Mb/s, 0mA) | U-Boot Root Hub | +-2 Human Interface (12 Mb/s, 98mA) Logitech USB Receiver Yes, seems to be device specific, it is also sensitive to OTG adaptor used.. Notes: (no usb_pgood_delay adjustments) Linux 5.15.0: * all the adaptors vs keyboards works U-boot 2023.04: (+works, -does not) * k1_a1- k1_a2+// workaround usb_pgood_delay=1000 * k2_a1- k2_a2-// 'usb tree' detected but does not work * k3_a1+ k3_a2+ Keyboards: k1/ Bus 001 Device 003: ID 17ef:6099 Lenovo Lenovo Traditional USB Keyboard,bcdUSB 1.10, bcdDevice 1.10, bcdHID 1.10 k2/ Bus 001 Device 002: ID 03f0:0024 HP, Inc KU-0316 Keyboard, bcdUSB 2.00, bcdDevice 1.30, bcdHID 1.11 k3/ Bus 001 Device 002: ID 04f2:0116 Chicony Electronics Co., Ltd KU-2971/KU-0325 Keyboard, bcdUSB 1.10, bcdDevice 3.00, bcdHID 1.10 OTG Adaptors: a1/ The PiHut, USB to microUSB OTG Shim https://rpishop.cz/datove-redukce/4365-prevodnik-usb-na-microusb-otg-shim.html a2/ USB 2.0 Hi-Speed 0,2m OTG adaptér https://rpishop.cz/datove-redukce/580-usb-20-hi-speed-02m-otg-adapter.html
Re: RPi Zero 2 W usb keyboard support?
On 7/24/23 21:53, Filip Žaludek wrote: Hi, is supposed usb keyboard to work in u-boot 2023.04 on RPi Zero 2 W? Configured as rpi_arm64_defconfig, no usb devices found but subsequent kernel works as expected. [pi02] kernel=u-boot.bin otg_mode=0 dtoverlay=dwc2,dr_mode=host Hello, I see, increasing usb_pgood_delay makes the trick. Regards, Filip U-Boot> env set usb_pgood_delay 1000 U-Boot> env save U-Boot> U-Boot> usb reset resetting USB... Bus usb@7e98: USB DWC2 scanning bus usb@7e98 for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found U-Boot> usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) | U-Boot Root Hub | +-2 Human Interface (1.5 Mb/s, 98mA) Lenovo Traditional USB Keyboard U-Boot>
RPi Zero 2 W usb keyboard support?
Hi, is supposed usb keyboard to work in u-boot 2023.04 on RPi Zero 2 W? Configured as rpi_arm64_defconfig, no usb devices found but subsequent kernel works as expected. [pi02] kernel=u-boot.bin otg_mode=0 dtoverlay=dwc2,dr_mode=host Regards, Filip
Re: [External] : Re: [PATCH] usb: kbd: dwc2: Increase wait for dwc2 controller reset by 125us
Hi Marek, On 5/15/23 20:56, Filip Žaludek wrote: Hi Marek, On 5/15/23 20:09, Marek Vasut wrote: On 5/15/23 16:53, Filip Zaludek wrote: Two following performance patches applied together occasionally harm usb keyboard on RPi3. 'dwc2: use the nonblock argument in submit_int_msg' commit 9dcab2c4d2cb50ab1864c818b82a72393c160236 'console: usb: kbd: Limit poll frequency to improve performance' commit 96991e652f541323a03c5b7e075d54a117091618 This empirically increased by sub-millisecond wait for dwc2 controller reset makes keyboard reliable. Signed-off-by: Filip Zaludek --- drivers/usb/host/dwc2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c index 23060fc369..71b66a52ed 100644 --- a/drivers/usb/host/dwc2.c +++ b/drivers/usb/host/dwc2.c @@ -764,7 +764,7 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv *priv, DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG, DWC2_HPRT0_PRTRST); - mdelay(50); + udelay(50125); Why not just use 'mdelay(51);' ? If you can tell me how to reproduce this , I could try and use USB bus analyzer (Beagle 5000) to look at his. I have RPi3 somewhere I think. Then we would know what's up. But that might take a while, since I am a bit busy these days. Unfortunately mdelay(51) does not work, what is actually strange. Be aware 'usb reset' might require 50 repetitions to reproduce, but usually it is reproduced under 20 cycles. Prerequisities: * RPi3B or RPi3B+ * unplugged all usb devices except keyboard, (both usb 1.1 and 2.0 tested) * RPi3 connected to console and HDMI monitor, (monitor is not requirement) * u-boot from master compiled without debugging as it works as workaround (reproducible with current JeOS-20230110) Refined reproducer: * Enter 'U-Boot>' shell using usb keyboard, (always works) * repeat 'usb reset' until usb keyboard responds, (press ENTER, or ARROW UP followed by ENTER [to see responsiveness]) * keyboard can be usually resurrected by subsequent 'usb reset' from console Marek Vasut suggested CONFIG_SYS_USB_EVENT_POLL_VIA_CONTROL_EP=y is another way how to deal with it, I can confirm. Thanks! Not proposing changes to configs/rpi_3_* defaults, hopefully distributors are listening.. Regards, Filip
Re: [External] : Re: [PATCH] usb: kbd: dwc2: Increase wait for dwc2 controller reset by 125us
Hi Marek, On 5/15/23 20:09, Marek Vasut wrote: On 5/15/23 16:53, Filip Zaludek wrote: Two following performance patches applied together occasionally harm usb keyboard on RPi3. 'dwc2: use the nonblock argument in submit_int_msg' commit 9dcab2c4d2cb50ab1864c818b82a72393c160236 'console: usb: kbd: Limit poll frequency to improve performance' commit 96991e652f541323a03c5b7e075d54a117091618 This empirically increased by sub-millisecond wait for dwc2 controller reset makes keyboard reliable. Signed-off-by: Filip Zaludek --- drivers/usb/host/dwc2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c index 23060fc369..71b66a52ed 100644 --- a/drivers/usb/host/dwc2.c +++ b/drivers/usb/host/dwc2.c @@ -764,7 +764,7 @@ static int dwc_otg_submit_rh_msg_out(struct dwc2_priv *priv, DWC2_HPRT0_PRTENCHNG | DWC2_HPRT0_PRTOVRCURRCHNG, DWC2_HPRT0_PRTRST); - mdelay(50); + udelay(50125); Why not just use 'mdelay(51);' ? If you can tell me how to reproduce this , I could try and use USB bus analyzer (Beagle 5000) to look at his. I have RPi3 somewhere I think. Then we would know what's up. But that might take a while, since I am a bit busy these days. Unfortunately mdelay(51) does not work, what is actually strange. Be aware 'usb reset' might require 50 repetitions to reproduce, but usually it is reproduced under 20 cycles. Prerequisities: * RPi3B or RPi3B+ * unplugged all usb devices except keyboard, (both usb 1.1 and 2.0 tested) * RPi3 connected to console and HDMI monitor, (monitor is not requirement) * u-boot from master compiled without debugging as it works as workaround (reproducible with current JeOS-20230110) Refined reproducer: * Enter 'U-Boot>' shell using usb keyboard, (always works) * repeat 'usb reset' until usb keyboard responds, (press ENTER, or ARROW UP followed by ENTER [to see responsiveness]) * keyboard can be usually resurrected by subsequent 'usb reset' from console Thanks, Filip
[PATCH v3] console: usb: kbd: Limit poll frequency to improve performance
Hi Simon,
On 5/3/23 03:28, Simon Glass wrote:
Hi Filip,
On Tue, 2 May 2023 at 12:43, Filip Žaludek wrote:
Hi Simon, Michal, Marek,
On 4/26/23 03:04, Simon Glass wrote:
Hi Filip,
On Tue, 25 Apr 2023 at 06:36, Filip Žaludek wrote:
Hi Simon,
On 4/19/23 03:49, Simon Glass wrote:
Hi Filip,
On Tue, 11 Apr 2023 at 14:24, Filip Žaludek wrote:
On 2/8/23 20:01, Mark Kettenis wrote:
Date: Wed, 8 Feb 2023 19:45:36 +0100
From: Michal Suchánek
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.
More updates to usb keyboard/RPi3/dwc2 controller issue:
I was following my former observation about printing characters from semi
random places [usb.c, usb_hub.c, device.c, usb-uclass.c, dwc2.c] what
works as workaround. I realized this is only when printing to vidconsole,
not to serial. After disabling video_sync() and/or flush_dcache_range()
from corresponding vidconsole print functions, printing is no longer
workaround. This behavior seem to be due to cache coherency.
Do you have any objections against elephant in porcelain proposal?
Not able to narrow it down more to single source code line.
With this keyboard works for me even when touching it only during 15s grub
timeout.
It is not for sure that cache coherency problem is from dwc2, but afaik there
are no other complaints to usb keyboard.
Performance degradation not observed..
%< -
diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index 23060fc369..f95314ff1b 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -814,6 +814,7 @@ static int dwc_otg_submit_rh_msg(struct dwc2_priv *priv,
struct usb_device *dev,
else
stat = dwc_otg_submit_rh_msg_out(priv, dev, buffer, txlen,
cmd);
+ flush_dcache_all();
mdelay(1);
We have dma_map_single() and dma_unmap_single() which are designed for
this. If you put these into the two functions that are called
immediately above, perhaps that will solve the problem.
After more experiments I finally concluded issue is not due to cache
coherency at all.
Workaround actually profited from side effect, time spent cleaning&invalidating
dcache.
Flushing dcache works for 51
Re: [PATCH v3] console: usb: kbd: Limit poll frequency to improve performance
Hi Simon, Michal, Marek,
On 4/26/23 03:04, Simon Glass wrote:
Hi Filip,
On Tue, 25 Apr 2023 at 06:36, Filip Žaludek wrote:
Hi Simon,
On 4/19/23 03:49, Simon Glass wrote:
Hi Filip,
On Tue, 11 Apr 2023 at 14:24, Filip Žaludek wrote:
On 2/8/23 20:01, Mark Kettenis wrote:
Date: Wed, 8 Feb 2023 19:45:36 +0100
From: Michal Suchánek
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.
More updates to usb keyboard/RPi3/dwc2 controller issue:
I was following my former observation about printing characters from semi
random places [usb.c, usb_hub.c, device.c, usb-uclass.c, dwc2.c] what
works as workaround. I realized this is only when printing to vidconsole,
not to serial. After disabling video_sync() and/or flush_dcache_range()
from corresponding vidconsole print functions, printing is no longer
workaround. This behavior seem to be due to cache coherency.
Do you have any objections against elephant in porcelain proposal?
Not able to narrow it down more to single source code line.
With this keyboard works for me even when touching it only during 15s grub
timeout.
It is not for sure that cache coherency problem is from dwc2, but afaik there
are no other complaints to usb keyboard.
Performance degradation not observed..
%< -
diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index 23060fc369..f95314ff1b 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -814,6 +814,7 @@ static int dwc_otg_submit_rh_msg(struct dwc2_priv *priv,
struct usb_device *dev,
else
stat = dwc_otg_submit_rh_msg_out(priv, dev, buffer, txlen, cmd);
+ flush_dcache_all();
mdelay(1);
return stat;
%< -
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_c
Re: [PATCH v3] console: usb: kbd: Limit poll frequency to improve performance
Hi Simon,
On 4/19/23 03:49, Simon Glass wrote:
Hi Filip,
On Tue, 11 Apr 2023 at 14:24, Filip Žaludek wrote:
On 2/8/23 20:01, Mark Kettenis wrote:
Date: Wed, 8 Feb 2023 19:45:36 +0100
From: Michal Suchánek
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.
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.
* 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.
More Tracing in U-Boot thoughts:
* There is proftool options discrepancy,
Re: [PATCH v3] console: usb: kbd: Limit poll frequency to improve performance
On 2/8/23 20:01, Mark Kettenis wrote:
Date: Wed, 8 Feb 2023 19:45:36 +0100
From: Michal Suchánek
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().
Is it possible/feasible to implement calls in CONFIG_SYS_ARCH_TIMER
and/or CONFIG_SP804_TIMER?
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.
Kind regards,
Filip
Re: [PATCH v3] console: usb: kbd: Limit poll frequency to improve performance
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
Re: [PATCH v3] console: usb: kbd: Limit poll frequency to improve performance
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?
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/96991e652f541323a03c5b7e075d54a117091618__;!!ACWV5N9M2RV99hQ!J3bR4ePIrYCcbqK8Zd5qG9y4yP6W_sNqMV0BhlIJqrwImk8KRkbMK8K5tzXHZU3BZ3ai6k7v25WDUCtgOBMVk8o$
Debug:
USB KBD: found interrupt EP: 0x81
USB KBD: set boot protocol
dwc2_submit_control_msg: dev='usb@7e98', udev=3af4be00,
udev->dev='usb_kbd', portnr=3
USB KBD: set idle interval...
dwc2_submit_control_msg: dev='usb@7e98', udev=3af4be00,
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/tumbleweed/appliances/openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.aarch64-2022.10.11-Snapshot20221112.raw.xz__;!!ACWV5N9M2RV99hQ!J3bR4ePIrYCcbqK8Zd5qG9y4yP6W_sNqMV0BhlIJqrwImk8KRkbMK8K5tzXHZU3BZ3ai6k7v25WDUCtgKPUw0V8$
(u-boot-rpiarm64-2022.10-1.1.aarch64)
[PATCH v3] console: usb: kbd: Limit poll frequency to improve performance
Hi Simon,
purchased 'Logitech K120 keyboard Vend: 0x046d Prod: 0xc31c' and 'SanDisk
USB Extreme Pro 53A45678B3C1'
to mimic your setup, I can still reproduce the issue. Major discrepancy is
u-boot does not recognize
SanDisk USB Extreme Pro.
Could you please share your u-boot config, config.txt, firmware version and dtbs? (Or better os image you are using for
testing)
Could you please retest once again, but unplugged all usb devices except
keyboard? Please see refined reproducer..
Prerequisities:
* RPi3B or RPi3B+
* unplugged all usb devices except keyboard, (both usb 1.1 and 2.0 tested)
* RPi3 connected to console and HDMI monitor, (monitor is not requirement)
* u-boot from master compiled without debugging as it works as workaround
(reproducible with current JeOS-20230110)
Refined reproducer:
* Enter 'U-Boot>' shell using usb keyboard, (always works)
* repeat 'usb reset' until usb keyboard responds, (press ENTER, or ARROW UP
followed by ENTER [to see responsiveness])
* keyboard can be resurrected by subsequent 'usb reset' from console
Workarounds:
* revert '96991e652f541323a03c5b7e075d54a117091618'
* hardcode poll_delay=0 [common/usb_kbd.c]
* enable '#define LOG_DEBUG' in [common/usb_hub.c]
* output character from semi random places [usb.c, usb_hub.c, device.c,
usb-uclass.c, dwc2.c]
Cordial regards,
Filip
On 1/3/23 18:36, Filip Žaludek wrote:
Hi Simon,
hmm this is strange. I am hitting this usually before 10 repetitions,
for sure within 30 repetitions. 'gpu_freq' is missing, thus default.
I can see this also from stock JeOS/RPi3 from OpenSUSE.
Do you have enabled debug as it works as workaround? [usb_hub.c]
Dissected more, thoughts into record:
** not reproduced on underclocked RPi4
** not reproduced with hardcoded poll_delay=0 [common/usb_kbd.c]
** reproduced with hardcoded poll_delay=1 [common/usb_kbd.c]
** not reproduced when '#define LOG_DEBUG' enabled in common/usb_hub.c
** workaround is to output character in non 'UCLASS_USB_HUB' branch,
even mdelay(500) instead of printing character would not help.
Seems to be synchronization problem, please advise if you have any
ideas/suggestions how to troubleshoot.
%< -
diff --git a/common/usb_hub.c b/common/usb_hub.c
index 95f1449..817e15e 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -73,8 +73,10 @@ static inline bool usb_hub_is_superspeed(struct usb_device
*hdev)
#if CONFIG_IS_ENABLED(DM_USB)
bool usb_hub_is_root_hub(struct udevice *hub)
{
- if (device_get_uclass_id(hub->parent) != UCLASS_USB_HUB)
+ if (device_get_uclass_id(hub->parent) != UCLASS_USB_HUB) {
+ puts(".");
return true;
+ }
return false;
}
%< -
Happy new year!
Regards,
Filip
On 1/3/23 18:02, Simon Glass wrote:
Hi Filip,
On Mon, 19 Dec 2022 at 14:25, Filip Žaludek wrote:
Hi Simon,
On 12/19/22 20:20, Simon Glass wrote:
Hi Filip,
On Mon, 19 Dec 2022 at 02:29, Filip Žaludek 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.
I am not seeing this problem, but the HDMI is not actually working. It
could be because of a setting in the silly config.txt file, e.g.
gpu_freq=250
The display comes to life and then says no signal.
But I tried it 10 times on us/next and the USB keyboard worked each time.
Regards,
Simon
[PATCH v3] console: usb: kbd: Limit poll frequency to improve performance
Hi Simon,
hmm this is strange. I am hitting this usually before 10 repetitions,
for sure within 30 repetitions. 'gpu_freq' is missing, thus default.
I can see this also from stock JeOS/RPi3 from OpenSUSE.
Do you have enabled debug as it works as workaround? [usb_hub.c]
Dissected more, thoughts into record:
** not reproduced on underclocked RPi4
** not reproduced with hardcoded poll_delay=0 [common/usb_kbd.c]
** reproduced with hardcoded poll_delay=1 [common/usb_kbd.c]
** not reproduced when '#define LOG_DEBUG' enabled in common/usb_hub.c
** workaround is to output character in non 'UCLASS_USB_HUB' branch,
even mdelay(500) instead of printing character would not help.
Seems to be synchronization problem, please advise if you have any
ideas/suggestions how to troubleshoot.
%< -
diff --git a/common/usb_hub.c b/common/usb_hub.c
index 95f1449..817e15e 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -73,8 +73,10 @@ static inline bool usb_hub_is_superspeed(struct usb_device
*hdev)
#if CONFIG_IS_ENABLED(DM_USB)
bool usb_hub_is_root_hub(struct udevice *hub)
{
- if (device_get_uclass_id(hub->parent) != UCLASS_USB_HUB)
+ if (device_get_uclass_id(hub->parent) != UCLASS_USB_HUB) {
+ puts(".");
return true;
+ }
return false;
}
%< -
Happy new year!
Regards,
Filip
On 1/3/23 18:02, Simon Glass wrote:
Hi Filip,
On Mon, 19 Dec 2022 at 14:25, Filip Žaludek wrote:
Hi Simon,
On 12/19/22 20:20, Simon Glass wrote:
Hi Filip,
On Mon, 19 Dec 2022 at 02:29, Filip Žaludek 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 console02/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.
I am not seeing this problem, but the HDMI is not actually working. It
could be because of a setting in the silly config.txt file, e.g.
gpu_freq=250
The display comes to life and then says no signal.
But I tried it 10 times on us/next and the USB keyboard worked each time.
Regards,
Simon
Re: [PATCH v3] console: usb: kbd: Limit poll frequency to improve performance
Hi Simon, On 12/19/22 20:20, Simon Glass wrote: Hi Filip, On Mon, 19 Dec 2022 at 02:29, Filip Žaludek 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 console02/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 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/96991e652f541323a03c5b7e075d54a117091618__;!!ACWV5N9M2RV99hQ!MunypRlNhelLw1nrbbLFCTeZK2pCAlIH_WPhgvmgFhfy3wJnPA5titNwl3o2fkc-mCqWAgJxjjc1sSD1$ Debug: USB KBD: found interrupt EP: 0x81 USB KBD: set boot protocol dwc2_submit_control_msg: dev='usb@7e98', udev=3af4be00, udev->dev='usb_kbd', portnr=3 USB KBD: set idle interval... dwc2_submit_control_msg: dev='usb@7e98', udev=3af4be00, 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/tumbleweed/appliances/openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.aarch64-2022.10.11-Snapshot20221112.raw.xz__;!!ACWV5N9M2RV99hQ!MunypRlNhelLw1nrbbLFCTeZK2pCAlIH_WPhgvmgFhfy3wJnPA5titNwl3o2fkc-mCqWAgJxjkilUmrv$ (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@7e30: 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@7e98: USB DWC2 scanning bus usb@7e98 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: 0x Product 0x 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 -
Re: [External] : Re: [PATCH v3] console: usb: kbd: Limit poll frequency to improve performance
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 console02/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 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/96991e652f541323a03c5b7e075d54a117091618__;!!ACWV5N9M2RV99hQ!MunypRlNhelLw1nrbbLFCTeZK2pCAlIH_WPhgvmgFhfy3wJnPA5titNwl3o2fkc-mCqWAgJxjjc1sSD1$ Debug: USB KBD: found interrupt EP: 0x81 USB KBD: set boot protocol dwc2_submit_control_msg: dev='usb@7e98', udev=3af4be00, udev->dev='usb_kbd', portnr=3 USB KBD: set idle interval... dwc2_submit_control_msg: dev='usb@7e98', udev=3af4be00, 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/tumbleweed/appliances/openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.aarch64-2022.10.11-Snapshot20221112.raw.xz__;!!ACWV5N9M2RV99hQ!MunypRlNhelLw1nrbbLFCTeZK2pCAlIH_WPhgvmgFhfy3wJnPA5titNwl3o2fkc-mCqWAgJxjkilUmrv$ (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@7e30: 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@7e98: USB DWC2 scanning bus usb@7e98 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: 0x Product 0x 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
[PATCH v3] console: usb: kbd: Limit poll frequency to improve performance
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://github.com/u-boot/u-boot/commit/96991e652f541323a03c5b7e075d54a117091618 Debug: USB KBD: found interrupt EP: 0x81 USB KBD: set boot protocol dwc2_submit_control_msg: dev='usb@7e98', udev=3af4be00, udev->dev='usb_kbd', portnr=3 USB KBD: set idle interval... dwc2_submit_control_msg: dev='usb@7e98', udev=3af4be00, 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: http://download.opensuse.org/ports/aarch64/tumbleweed/appliances/openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.aarch64-2022.10.11-Snapshot20221112.raw.xz (u-boot-rpiarm64-2022.10-1.1.aarch64)
