The INT13 console type (CONSOLE_INT13) autodetects at initialisation
time a magic partition to be used for logging iPXE console output.  If
the INT13 drive number mapping is subsequently changed (e.g. because
iPXE was used to perform a SAN boot), then the console logging output
will be written to the incorrect disk.

Fix by recording the INT13 vector at initialisation time, and using
this original vector to emulate INT13 calls for all subsequent
accesses.  This should be robust against drive remapping performed
either by ourselves or by another bootloader (e.g. a chainloaded
undionly.kpxe which then performs a SAN boot).

Signed-off-by: Michael Brown <mcb30@ipxe.org>

Move most arch/i386 files to arch/x86, and adjust the contents of the
Makefiles and the include/bits/*.h headers to reflect the new
locations.

This patch makes no substantive code changes, as can be seen using a
rename-aware diff (e.g. "git show -M5").

This patch does not make the pcbios platform functional for x86_64; it
merely allows it to compile without errors.

Signed-off-by: Michael Brown <mcb30@ipxe.org>

Several popular public cloud providers do not provide any sensible
mechanism for obtaining debug output from an OS which is failing to
boot.  For example, Amazon EC2 provides the "Get System Log" facility,
which occasionally deigns to report a random subset of the characters
emitted via the VM's serial port, but usually returns only a blank
screen.  (Amazingly, this is still superior to the debugging
facilities provided by Azure.)

Work around these shortcomings by adding a console type which sends
output to a magically detected raw disk partition, and including such
a partition within any iPXE .usb-format image.

To use this facility:

 - build an iPXE .usb image with CONSOLE_INT13 enabled

 - boot the cloud VM from this image

 - after the boot fails, attach the VM's boot disk to a second VM

 - from this second VM, use "less -f -R /dev/sdb3" (or similar) to
   view the iPXE output.

Signed-off-by: Michael Brown <mcb30@ipxe.org>