Kevin O'Connor kevin@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, break; case KBD_CCMD_SELF_TEST: s->status |= KBD_STAT_SELFTEST; + kbd_put_keycode(0x1d); kbd_queue(s, 0x55, 0); break; case KBD_CCMD_KBD_TEST:
Regards,
Anthony Liguori
I'd guess someone on the coreboot list could describe how to reflash the pixel. I don't own one myself.
-Kevin