[SeaBIOS] [PATCH] ps2: disable the keyboard and mouse before flushing the queue

Anthony Liguori aliguori at us.ibm.com
Thu Apr 25 17:33:57 CEST 2013

Kevin O'Connor <kevin at koconnor.net> writes:

> On Wed, Apr 24, 2013 at 08:32:09PM -0500, Anthony Liguori wrote:
>> If SeaBIOS is run as a payload via coreboot (and presumably as a
>> CSM), then it's possible the keyboard or mouse will still be
>> enabled.  This can lead to data being queued even after the flush
>> function attempts to clear the queue.
>> Disabling the keyboard/mouse prior to flushing is pretty standard
>> in DOS programming so it's not surprising that it's needed here.
>> I believe this problem manifests with the Chromebook Pixel.  People
>> have reported that sometimes the 'ESC to Select Boot Devices'
>> doesn't work.  I can reproduce this faithfully by holding 'Ctrl-L'
>> in the firmware screen during SeaBIOS initialization.
> Thanks.  I don't understand why keyboard/mouse events would be a
> problem.  Those events should get discarded with the "Discarding ps2
> data %02x (status=%02x)" message.  (The role of the flush is to make
> sure there are no i8042 command responses pending - I don't think
> keyboard/mouse events are a problem.)

This is much too late.  I think what's happening is:

>    /* flush incoming keys */
>    int ret = i8042_flush();
>    if (ret)
>        return;

This drains the PS/2 queue but if the keyboard is enabled, then more
data can appear in the queue.

>    // Controller self-test.
>    u8 param[2];
>    ret = i8042_command(I8042_CMD_CTL_TEST, param);
>    if (ret)
>        return;
>    if (param[0] != 0x55) {
>        dprintf(1, "i8042 self test failed (got %x not 0x55)\n", param[0]);
>        return;
>    }

The patch below in QEMU will effectively queue the injected queue
keycode before the 0x55 that self-test returns.  The command queue is
shared with the keyboard and the i8042 so if the keyboard is active, you
may get keyboard data before getting the command responses.

>> I can't test this fix on an actual Pixel because I don't know how
>> to update SeaBIOS but I have tested the patch under QEMU.
> Are you able to reproduce the problem under QEMU?

I can with the following patch.  It's very hard to get the right timing
manually because IO writes are much faster in QEMU.  We also don't
emulate key repeat correctly in QEMU so just holding a key won't do it.

But the following patch is a reasonable approximation.  kbd_put_keycode()
can happen at any time in QEMU (this is what VNC/GTK will call to inject
a keycode).  This patch just makes it happen at exactly the right time
to reproduce the bug.

This replicates the same behavior in QEMU as I see on the Pixel.

(And the patch I sent fixes the problem with my hacked QEMU).

diff --git a/hw/input/pckbd.c b/hw/input/pckbd.c
index 08ceb9f..bc35dd6 100644
--- a/hw/input/pckbd.c
+++ b/hw/input/pckbd.c
@@ -26,6 +26,7 @@
 #include "hw/i386/pc.h"
 #include "hw/input/ps2.h"
 #include "sysemu/sysemu.h"
+#include "ui/console.h"
 /* debug PC keyboard */
 //#define DEBUG_KBD
@@ -267,6 +268,7 @@ static void kbd_write_command(void *opaque, hwaddr addr,
         s->status |= KBD_STAT_SELFTEST;
+        kbd_put_keycode(0x1d);
         kbd_queue(s, 0x55, 0);
     case KBD_CCMD_KBD_TEST:


Anthony Liguori

> I'd guess someone on the coreboot list could describe how to reflash
> the pixel.  I don't own one myself.
> -Kevin

More information about the SeaBIOS mailing list