Pinebook Pro keyboard (RK3399 OHCI)?

Pinebook Pro keyboard (RK3399 OHCI)?

[Simon South]

Has anyone managed to get the built-in keyboard of the Pinebook Pro
working with U-Boot?

Kever, Jagan: Are you aware of any special setup required to have the
RK3399's OHCI controller begin processing its periodic list?

Even using the latest code, having USB started makes the U-boot console
feel sluggish while pressing keys on the keyboard produces no result.

The issue seems to be the OHCI (USB 1.1) driver continually times out
waiting for the controller to start an interrupt transfer (to poll the
keyboard for a keypress). Dumping the OHCI controller's registers as
well as the endpoint and transfer descriptors shows everything set up
correctly, however, as best I can tell from the OHCI spec: The
descriptors have the right values, the ED is added to the first
interrupt list, and the controller even "sees" the ED (the
HcPeriodCurrentED register holds its address once per frame). Yet when
the timeout expires the TD remains unprocessed, with its condition code
still set to "not accessed" and the controller's error counters still at
zero.

Oddly, control messages are passed to the keyboard just fine. It's as
though the controller is simply ignoring the periodic list, even though
the bit to enable its processing is set in the HcControl register.

Plugging in an external keyboard (after updating the build configuration
to include the right phy driver) produces the same result, so it's not
just the built-in one. And obviously the OHCI driver works on other
platforms, so it seems to me this could be something specific to
Rockchip's implementation not yet reflected in the code.

Has anyone found a solution to this?

-- 
Simon South
simon at simonsouth.net

Pinebook Pro keyboard (RK3399 OHCI)?

[Peter Robinson]

On Tue, Jul 14, 2020 at 12:02 AM Simon South <simon@simonsouth.net> wrote:
>
> Has anyone managed to get the built-in keyboard of the Pinebook Pro
> working with U-Boot?

It should be fixed in the main devel repo, commit 3a5771249

> Kever, Jagan: Are you aware of any special setup required to have the
> RK3399's OHCI controller begin processing its periodic list?
>
> Even using the latest code, having USB started makes the U-boot console
> feel sluggish while pressing keys on the keyboard produces no result.
>
> The issue seems to be the OHCI (USB 1.1) driver continually times out
> waiting for the controller to start an interrupt transfer (to poll the
> keyboard for a keypress). Dumping the OHCI controller's registers as
> well as the endpoint and transfer descriptors shows everything set up
> correctly, however, as best I can tell from the OHCI spec: The
> descriptors have the right values, the ED is added to the first
> interrupt list, and the controller even "sees" the ED (the
> HcPeriodCurrentED register holds its address once per frame). Yet when
> the timeout expires the TD remains unprocessed, with its condition code
> still set to "not accessed" and the controller's error counters still at
> zero.
>
> Oddly, control messages are passed to the keyboard just fine. It's as
> though the controller is simply ignoring the periodic list, even though
> the bit to enable its processing is set in the HcControl register.
>
> Plugging in an external keyboard (after updating the build configuration
> to include the right phy driver) produces the same result, so it's not
> just the built-in one. And obviously the OHCI driver works on other
> platforms, so it seems to me this could be something specific to
> Rockchip's implementation not yet reflected in the code.
>
> Has anyone found a solution to this?
>
> --
> Simon South
> simon at simonsouth.net

Pinebook Pro keyboard (RK3399 OHCI)?

[Simon South]

Peter Robinson <pbrobinson@gmail.com> writes:
> It should be fixed in the main devel repo, commit 3a5771249

That commit enables the OHCI driver but doesn't lead to a working
keyboard, at least for me.

Have you actually tested this successfully on a PBP? (Has anyone else?)
I wonder if there's something different about my unit.

-- 
Simon South
simon at simonsouth.net

Pinebook Pro keyboard (RK3399 OHCI)?

[Peter Robinson]

On Tue, Jul 14, 2020 at 11:50 AM Simon South <simon@simonsouth.net> wrote:
>
> Peter Robinson <pbrobinson@gmail.com> writes:
> > It should be fixed in the main devel repo, commit 3a5771249
>
> That commit enables the OHCI driver but doesn't lead to a working
> keyboard, at least for me.
>
> Have you actually tested this successfully on a PBP? (Has anyone else?)
> I wonder if there's something different about my unit.

It was working when I sent the patches.

Pinebook Pro keyboard (RK3399 OHCI)?

[Arnaud Patard]

Simon South <simon@simonsouth.net> writes:

> Peter Robinson <pbrobinson@gmail.com> writes:
>> It should be fixed in the main devel repo, commit 3a5771249
>
> That commit enables the OHCI driver but doesn't lead to a working
> keyboard, at least for me.
>
> Have you actually tested this successfully on a PBP? (Has anyone else?)
> I wonder if there's something different about my unit.

The keyboard is working fine here. Maybe you could provide more details ?
Did you check if everything needed is enabled in your configuration and
if the keyboard is detected after a usb start / usb tree ?
Your keyboard is working with linux, right ?

Arnaud

Pinebook Pro keyboard (RK3399 OHCI)?

[Simon South]

Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org> writes:
> Did you check if everything needed is enabled in your configuration and
> if the keyboard is detected after a usb start / usb tree ?

It is detected, yes.

I believe the configuration is fine; I see this issue using the standard
"pinebook-pro-rk3399_defconfig" and building either from the latest
commit in git or from the tree at commit 3a5771249 (Peter's, which he
mentioned earlier).

Changing the configuration to remove the XHCI and EHCI drivers, or to
add the Inno USB phy driver, doesn't help.

Beyond that, for BL31 I'm using a release build of v2.3 of the ARM
Trusted Firmware. I've tested using debug and release builds of v2.3 and
v2.2 without seeing a difference.

> Your keyboard is working with linux, right ?

Yes it is. It's only U-Boot that's affected.

The only things I've thought of so far that might be unique about my
setup are

- My PBP is from the latest manufacturing run of a few months ago, not
  last year's; and

- I currently have the eMMC module disabled via the internal switch and
  am booting off a microSD card.

Otherwise I'm at a total loss. The driver sets everything up correctly
and then the controller just does nothing. In GNU/Linux, everything
works fine. Very strange.

-- 
Simon South
simon at simonsouth.net

Pinebook Pro keyboard (RK3399 OHCI)?

[Peter Robinson]

> > Did you check if everything needed is enabled in your configuration and
> > if the keyboard is detected after a usb start / usb tree ?
>
> It is detected, yes.
>
> I believe the configuration is fine; I see this issue using the standard
> "pinebook-pro-rk3399_defconfig" and building either from the latest
> commit in git or from the tree at commit 3a5771249 (Peter's, which he
> mentioned earlier).
>
> Changing the configuration to remove the XHCI and EHCI drivers, or to
> add the Inno USB phy driver, doesn't help.
>
> Beyond that, for BL31 I'm using a release build of v2.3 of the ARM
> Trusted Firmware. I've tested using debug and release builds of v2.3 and
> v2.2 without seeing a difference.

I believe I have 2.3 from upstream.

> > Your keyboard is working with linux, right ?
>
> Yes it is. It's only U-Boot that's affected.
>
> The only things I've thought of so far that might be unique about my
> setup are
>
> - My PBP is from the latest manufacturing run of a few months ago, not
>   last year's; and
>
> - I currently have the eMMC module disabled via the internal switch and
>   am booting off a microSD card.

I'm booting off mSD and I actually took out the eMMC because it was a
pain dealing with it when I was developing the upstream U-Boot
support. I think my keyboard firmware is quite old (dealing with that
is on my list), but I'm not sure that should make a difference here.

Pinebook Pro keyboard (RK3399 OHCI)?

[Arnaud Patard]

Simon South <simon@simonsouth.net> writes:

> Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org> writes:
>> Did you check if everything needed is enabled in your configuration and
>> if the keyboard is detected after a usb start / usb tree ?
>
> It is detected, yes.

ok.

>
> I believe the configuration is fine; I see this issue using the standard
> "pinebook-pro-rk3399_defconfig" and building either from the latest
> commit in git or from the tree at commit 3a5771249 (Peter's, which he
> mentioned earlier).

Did you check the stdin variable content if it contains only "usbkbd" ?
If you have more than one value in it (like "serial,usbkbd"), do you have
CONSOLE_MUX configuration setting enabled ? If it's not enabled, test
with it, as I guess you probably want stdin set to "serial,usbkbd".

>
> Changing the configuration to remove the XHCI and EHCI drivers, or to
> add the Inno USB phy driver, doesn't help.
>
> Beyond that, for BL31 I'm using a release build of v2.3 of the ARM
> Trusted Firmware. I've tested using debug and release builds of v2.3 and
> v2.2 without seeing a difference.
>

imho, ATF has nothing to do with your issue and it's possibly a uboot
configuration issue (like stdin variable or .config).

>> Your keyboard is working with linux, right ?
>
> Yes it is. It's only U-Boot that's affected.

So it's not hardware. I've tested fairly recent version of uboot (HEAD
pointing to 7012865e961ca2645d783adf4b75ca4abdbfe5a7) last week and the
keyboard was fine. That's why I'm really thinking of uboot
configuration.

>
> The only things I've thought of so far that might be unique about my
> setup are
>
> - My PBP is from the latest manufacturing run of a few months ago, not
>   last year's; and
>
> - I currently have the eMMC module disabled via the internal switch and
>   am booting off a microSD card.

Same here.

Arnaud

Pinebook Pro keyboard (RK3399 OHCI)?

[Simon South]

Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org> writes:
> Did you check the stdin variable content if it contains only "usbkbd" ?
> If you have more than one value in it (like "serial,usbkbd"), do you have
> CONSOLE_MUX configuration setting enabled ?

Yes, "stdin" is set to "serial,usbkbd" and CONSOLE_MUX is set. The
console works fine via the serial connection, apart from being sluggish
while USB is enabled.

> Same here.

I just now tried removing another variable by building U-Boot from a
fresh checkout on the PBP itself, rather than cross-compiling from my
x86_64 machine as I normally do. Same result.

So I'm completely at a loss.

If you have them handy, would you be willing to email me (off-list) your
idbloader.img and u-boot.itb files please so I can try booting them on
my hardware? I'm starting to think at this point I somehow got a lemon,
but if your build works that would at least point to something I've
missed in my setup.

-- 
Simon South
simon at simonsouth.net

Pinebook Pro keyboard (RK3399 OHCI)?

[Simon South]

Simon South <simon@simonsouth.net> writes:
> Has anyone managed to get the built-in keyboard of the Pinebook Pro
> working with U-Boot?
>
> Even using the latest code, having USB started makes the U-boot
> console feel sluggish while pressing keys on the keyboard produces no
> result.

To follow up on this, for anyone looking into it in the future:

The issue is that the Pinebook Pro's keyboard firmware does not actually
implement the keyboard boot protocol (described in the USB HID
specification[1]). It also doesn't support retrieving input reports via
its control interface, meaning neither of the two mechanisms U-Boot
normally uses for polling keyboard data are functional.

The firmware does recognize the Set_Protocol request, and will even
store the supplied value in the controller's memory and return it in
response to Get_Protocol. But it doesn't actually change how the
keyboard operates.

As such, the keyboard continues to NAK every interrupt-transfer request
it sees (whenever the user isn't pressing a key), despite U-Boot
expecting it to return a report at least once each 40-millisecond
period. Consequently the submit_common_msg() routine in
drivers/usb/host/ohci-hcd.c is continually timing out waiting for a
response, and this slows down the U-Boot console considerably.

Arnaud Patard has pointed out setting the
CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE configuration option seems to
improve the keyboard's responsiveness somewhat, and while this is true,
I suspect all this does is increase the likelihood U-Boot will happen to
be polling the keyboard at the same moment the user is pressing a
key. It doesn't address the underlying problem.

In fact, nothing seems likely to address this unless and until new
keyboard firmware is created for the Pinebook Pro. There has actually
been some progress in this area[2], but the complexity involved in using
an external programmer with the controller[3] (and the possibility of
bricking it without one) makes it risky for an end-user to experiment
with anything beyond very minor changes to the existing code.

[1] https://www.usb.org/document-library/device-class-definition-hid-111
[2] https://github.com/jackhumbert/pinebook-pro-keyboard-updater/tree/master/firmware
[3] https://electronics.stackexchange.com/a/277395

-- 
Simon South
simon at simonsouth.net

Pinebook Pro keyboard (RK3399 OHCI)?

[Arnaud Patard]

Simon South <simon@simonsouth.net> writes:

> Simon South <simon@simonsouth.net> writes:
>> Has anyone managed to get the built-in keyboard of the Pinebook Pro
>> working with U-Boot?
>>
>> Even using the latest code, having USB started makes the U-boot
>> console feel sluggish while pressing keys on the keyboard produces no
>> result.
>
> To follow up on this, for anyone looking into it in the future:
>
> The issue is that the Pinebook Pro's keyboard firmware does not actually
> implement the keyboard boot protocol (described in the USB HID
> specification[1]). It also doesn't support retrieving input reports via
> its control interface, meaning neither of the two mechanisms U-Boot
> normally uses for polling keyboard data are functional.

this explains things a lot.

>
> The firmware does recognize the Set_Protocol request, and will even
> store the supplied value in the controller's memory and return it in
> response to Get_Protocol. But it doesn't actually change how the
> keyboard operates.
>
> As such, the keyboard continues to NAK every interrupt-transfer request
> it sees (whenever the user isn't pressing a key), despite U-Boot
> expecting it to return a report at least once each 40-millisecond
> period. Consequently the submit_common_msg() routine in
> drivers/usb/host/ohci-hcd.c is continually timing out waiting for a
> response, and this slows down the U-Boot console considerably.
>
> Arnaud Patard has pointed out setting the
> CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE configuration option seems to
> improve the keyboard's responsiveness somewhat, and while this is true,
> I suspect all this does is increase the likelihood U-Boot will happen to
> be polling the keyboard at the same moment the user is pressing a
> key. It doesn't address the underlying problem.

I've never pretended I found the issue, and I hope I've never pretended
it. All I know is that CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE were
making things better. It's merely a workaround. Thanks to you, now, we
know what the problem really is.

>
> In fact, nothing seems likely to address this unless and until new
> keyboard firmware is created for the Pinebook Pro. There has actually
> been some progress in this area[2], but the complexity involved in using
> an external programmer with the controller[3] (and the possibility of
> bricking it without one) makes it risky for an end-user to experiment
> with anything beyond very minor changes to the existing code.

hm. I already did update the touchpad/keyboard firmware in the past from
linux so people should be able to do it too, but you're right. Adding
boot protocol support can't be done without external programmer. Also,
not sure how many writes can be done to the chipset memory before it
breaks.

Arnaud