From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnaud Patard (Rtp) Date: Fri, 02 Oct 2020 10:07:21 +0200 Subject: Pinebook Pro keyboard (RK3399 OHCI)? In-Reply-To: <87362y6llf.fsf@simonsouth.net> (Simon South's message of "Thu, 01 Oct 2020 10:56:44 -0400") References: <87zh8388d6.fsf@simonsouth.net> <87362y6llf.fsf@simonsouth.net> Message-ID: <871rihkq4m.fsf@lechat.rtp-net.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Simon South writes: > Simon South 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