Send a null command, specifically "pulse outputs" with no outputs
selected, to the KBC after changing A20.  This was apparently done by DOS,
presumably as a synchronization hack, and the authors of the UHCI spec
thought it was inherent.  Therefore, there are systems out there (e.g. HP
DL360 G5) which will stop responsing to "legacy USB" unless they see the
null command, 0xFF, written to port 0x64 at the end of the A20 toggling
sequence.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>

Signed-off-by: Alexey Zaytsev <alexey.zaytsev@gmail.com>

in a long loop before giving up on them.  Record method which worked
and default to that method on next attempt.

optimisation of only trying to do so when necessary.

number of (potentially very slow) gateA20_set operations.

Die with a fatal error if we are unable to set gate A20; if this fails
then we are bound to experience memory corruption at a later stage,
and I'd prefer to pick it up early.

technically be necessary, because the "enable A20" command requires
only that the keyboard controller is ready to accept input (i.e. that
its input buffer is empty), and shouldn't also require that the
keyboard is ready to send output (i.e. that its output buffer is also
empty).  See http://www.smsc.com/main/tools/io-bios/42i.pdf section
3.1 ("Command Invocation") for a justification.

gateA20_set() is called on every real-mode transition (in case some
idiot piece of external code such as Intel's PXE stack decided it
would be fun to re-disable A20), so draining the keyboard buffer means
that we end up losing keypresses on some systems.  In particular, this
makes typing at the command line almost impossible, and causes
Etherboot to ignore Ctrl-Alt-Del.

We should really implement a gateA20_test() function to verify that
gate A20 has been correctly enabled, and think about adding other
commonly-used methods such as Fast Gate A20.