Currently the only supported platform for x86_64 is EFI.

Building an EFI64 gPXE requires a version of gcc that supports
__attribute__((ms_abi)).  This currently means a development build of
gcc; the feature should be present when gcc 4.4 is released.

In the meantime; you can grab a suitable gcc tree from

  git://git.etherboot.org/scm/people/mcb30/gcc/.git

EFI provides a copy of the SMBIOS table accessible via the EFI system
table, which we should use instead of manually scanning through the
F000:0000 segment.

This brings us in to line with Linux definitions, and also simplifies
adding x86_64 support since both platforms have 2-byte shorts, 4-byte
ints and 8-byte long longs.

__cdecl is a misleading name, since it currently encapsulates both
cdecl and regparm(0) attributes.  Rename to __asmcall.

The initial PXE implementation in Etherboot had the goal of being
architecture-agnostic, but this goal has not been realised.

Code paths that automatically allocate memory from the FBMS at 40:13
should also free it, if possible.

Freeing this memory will not be possible if either

  1. The FBMS has been modified since our allocation, or

  2. We have not been able to unhook one or more BIOS interrupt vectors.

We have EFI APIs for CPU I/O, PCI I/O, timers, console I/O, user
access and user memory allocation.

EFI executables are created using the vanilla GNU toolchain, with the
EXE header handcrafted in assembly and relocations generated by a
custom efilink utility.

The userptr_t is now the fundamental type that gets used for conversions.
For example, virt_to_phys() is implemented in terms of virt_to_user() and
user_to_phys().

We now have two implementations for the timer API: one using the
time-of-day counter at 40:70 and one using RDTSC.  Both make use of
timer2_udelay().

The copy_{to,from}_phys() functions were obsoleted long ago by
copy_{to,from}_user().

relocate_to() also disappeared some time ago.

We seem to be having issues with various E820 memory maps.  These
problems are often difficult to reproduce, requiring access to the
specific system exhibiting the problem.

Add a facility for hooking in a fake E820 map generator, using an
arbitrary map defined in a C array, solely in order to be able to test
the map-mangling code against arbitrary E820 maps.

Shifting all INT13 drive numbers causes problems on systems that use a
sparse drive number space (e.g. qemu BIOS, which uses 0xe0 for the CD-ROM
drive).

The strategy now is:

  Each drive is assigned a "natural" drive number, being the next
  available drive number in the system (based on the BIOS drive count).

  Each drive is accessed using its specified drive number.  If the
  specified drive number is -1, the natural drive number will be used.

  Accesses to the specified drive number will be delivered to the
  emulated drive, masking out any preexisting drive using this number.

  Accesses to the natural drive number, if different, will be remapped to
  the masked-out drive.

The overall upshot is that, for examples:

  System has no drives.  Emulated INT13 drive gets natural number 0x80
  and specified number 0x80.  Accesses to drive 0x80 go to the emulated
  drive, and there is no remapping.

  System has one drive.  Emulated INT13 drive gets natural number 0x81
  and specified number 0x80.  Accesses to drive 0x80 go to the emulated
  drive.  Accesses to drive 0x81 get remapped to the original drive 0x80.

__from_data16 and __from_text16 now take a pointer to a
.data16/.text16 variable, and return the real-mode offset within the
appropriate segment.  This matches the use case for every occurrence
of these macros, and prevents potential future bugs such as that fixed
in commit d51d80f.  (The bug arose essentially because "&pointer" is
still syntactically valid.)

If we ever need these macros, they should be defined in
include/{big,little}_bswap.h, and the whole family should be defined.

2.6.22+ kernels have an extra field in the bzimage_header structure to
indicate the maximum permitted command-line length.  Use this if it is
available.

Delete ELF as a generic image type.  The method for invoking an
ELF-based image (as well as any tables that must be set up to allow it
to boot) will always depend on the specific architecture.  core/elf.c
now only provides the elf_load() function, to avoid duplicating
functionality between ELF-based image types.

Add arch/i386/image/elfboot.c, to handle the generic case of 32-bit
x86 ELF images.  We don't currently set up any multiboot tables, ELF
notes, etc.  This seems to be sufficient for loading kernels generated
using both wraplinux and coreboot's mkelfImage.

Note that while Etherboot 5.4 allowed ELF images to return, we don't.
There is no callback mechanism for the loaded image to shut down gPXE,
which means that we have to shut down before invoking the image.  This
means that we lose device state, protection against being trampled on,
etc.  It is not safe to continue afterwards.

See http://etherboot.org/wiki/dev/gdbstub for documentation.

In particular, expose the system UUID as a setting ("smbios/uuid").

The home-grown versions don't work properly for static variadic
functions, when gcc can choose to use a non-standard calling convention.

Replace a printf with a DBG in timer_rtdsc.c
Replace a printf in timer.c with assert
Return proper error codes from timer drivers

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

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

	Timer subsystem initialization code in core/timer.c

	Split the BIOS and RTDSC timer drivers from i386_timer.c

	Split arch/i386/firmware/pcbios/bios.c into the RTSDC
	timer driver and arch/i386/core/nap.c

	Split the headers properly:
		include/unistd.h - delay functions to be used by the
					gPXE core and drivers.

		include/gpxe/timer.h - the fimer subsystem interface
					to be used by the timer drivers
					and currticks() to be used by
					the code gPXE subsystems.

		include/latch.h	- removed
		include/timer.h - scheduled for removal. Some driver
					are using currticks, which is
					only for core subsystems.

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

implemented smbios_get_uuid().

potentially exorbitant amounts of stack space.

allowing any space for this, which makes it surprising that bzImage
loading ever worked.

outside of librm.S.