Add the missing instructions to the code path that I never tested due
to not having a PCI 3.0 system available.

(D'oh)

WinPE seems to have a bug that causes it to always use the TFTP server
IP address and filename from the ProxyDHCPACK packet, even if the
ProxyDHCPACK packet doesn't exist.  This causes it to end up
attempting to fetch a file such as

  tftp://0.0.0.0/bootmgr.exe

If we don't have a ProxyDHCPACK to use, we pretend that it was a copy
of the DHCPACK packet.  This works around the problem, and hopefully
won't surprise any NBPs.

Altiris erroneously cares about the ordering of DHCP options, and will
get confused if we don't construct them in the order it expects.

This is observed (so far) only when attempting to deploy 64-bit Win2k3.

This patch adds support for the virtio-net adapter provided by KVM.

Written by Laurent Vivier <Laurent.Vivier@bull.net> for Etherboot.
Wrapped as legacy driver for gPXE by Stefan Hajnoczi
<stefanha@gmail.com>.

When we boot from a DHCP-supplied filename, we previously relied on
the fact that the current working URI is set to tftp://[next-server]/
in order to resolve the filename into a full tftp:// URI.  However,
this process will eliminate the distinction between filenames with and
without initial slashes:

 cwuri="tftp://10.0.0.1/" filename="vmlinuz"  => URI="tftp://10.0.0.1/vmlinuz"
 cwuri="tftp://10.0.0.1/" filename="/vmlinuz" => URI="tftp://10.0.0.1/vmlinuz"

This distinction is important for some TFTP servers.  We now
explicitly construct a string of the form

 "tftp://[next-server]/filename"

so that a filename with an initial slash will result in a URI
containing a double-slash, e.g.

 "tftp://10.0.0.1//vmlinuz"

The TFTP code always strips a single initial slash, and so ends up
presenting the correct path to the server.

URIs entered explicitly by users at the command line must include a
double slash if they want an initial slash presented to the TFTP
server:

  "kernel tftp://10.0.0.1/vmlinuz"  => filename="vmlinuz"
  "kernel tftp://10.0.0.1//vmlinuz" => filename="/vmlinuz"

This utility is required as a workaround for legal restrictions on
including GPL and non-GPL code within the same expansion ROM image.

While this is not encouraged, we are prepared to accept that
concatenation of ROM images and updating of the ROM header data
structures can be classed as "mere aggregation" within the terms of
the GPL.

If in any doubt, assume that you cannot include GPL and non-GPL code
within the same expansion ROM image.  Contact the Etherboot team for
clarification on your specific circumstances.

The Option::ROM module provides an easy way to read and edit fields
within option ROM headers.

When an error reply (not 1xx, 2xx or 3xx) was received, ftp_reply()
invoked ftp_done() to close connections, but did not return, and the
rest of code in this function could try to send commands to the closed
control connection.

Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>

Based on a patch contributed by Sergey Vlasov <vsu@altlinux.ru> :

  In my testing with "qemu -net user" the 226 response to RETR was
  often received earlier than final packets of the data connection;
  this caused the received file to become truncated without any error
  indication.  Fix this by adding an intermediate state FTP_TRANSFER
  between FTP_RETR and FTP_QUIT, so that the transfer is considered to
  be complete only when both the end of data connection is encountered
  and the final reply to the RETR command is received.

H. Peter Anvin <hpa@zytor.com> sent word that Sergey Vlasov
<vsu@altlinux.ru> discovered gPXE lkrn images fail to load in SYSLINUX
3.70 because we have initrd_addr_max zeroed.  This patch sets the same
value as the Linux kernel.

Also change the header jmp instruction to use a hardcoded opcode value
like Linux does.  Just in case the assembler decides to use a three-byte
instruction instead of the desired two-byte jmp.

Allow settings to be expanded in arbitrary commands, such as

  kernel http://10.0.0.1/boot.php?uuid=${uuid}

Also add the "echo" command, as being the easiest way to test this
features.

Print one dot per second while waiting in monojob.c (e.g. for DHCP,
for file downloads, etc.), to inform user that the system has not
locked up.

Patch contributed by Andrew Schran <aschran@google.com>, minor
modification by me.

This change allows the time for which shell banners are displayed to
be configured in the config.h file.  The ability to access the shell
can also be effectively disabled by setting this timeout to zero.

In tg3_chip_reset(), the PCI_EXPRESS change is taken from the Linux
tg3 driver. I am not sure what exactly it does (it is not documented
in the Linux driver), but it is necessary for the NIC to work
correctly.

Use "-include" rather than "include" for the generated Makefile
fragments, in order to suppress the long list of warnings that
otherwise appears at the start of a clean build.

Contributed by Edward Waugh <ewaugh@netxen.com>

Add yet another ugly hack to iscsiboot.c, this time to allow the user to
inhibit the shutdown/removal of the iSCSI INT13 device (and the network
devices, since they are required for the iSCSI device to function).

On the plus side, the fact that shutdown() now takes flags to
differentiate between shutdown-for-exit and shutdown-for-boot means that
another ugly hack (to allow returning via the PXE stack on BIOSes that
have broken INT 18 calls) will be easier.

I feel dirty.

Conjecture: The hardware issues 64-bit DMA writes of status descriptors,
which some PCI bridges seem to split into two 32-bit writes in reverse
order (i.e. dword 1 first).  This means that we sometimes observe a
partial status descriptor.  Add an explicit check to ensure that the
descriptor is complete before processing it.

Also ensure that the RDS consumer counter is incremented only when we
know that we have actually consumed an RX descriptor.

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.

This duplicates a fix made to tcp.c in commit
d5735c631c.

Verifying server ID and DHCP transaction ID is insufficient to
differentiate between DHCPACK and ProxyDHCPACK when the DHCP server and
Proxy DHCP server are the same machine.

PCI ID supplied (and tested) by Frederic
Temporelli <frederic.temporelli@bull.net>

If there is more than one loaded image, refuse to automatically select
the image to execute.  There are at least two possible cases, with
different "correct" answers:

1. User loads image A by mistake, then loads image B and types "boot".
   User wants to execute image B.

2. User loads image A, then loads image B (which patches image A), then
   types "boot".  User wants to execute image A.

If a user actually wants to load multiple images, they must explicitly
specify which image is to be executed.

Clearing the LOADED flag actually prevents users from doing clever things
such as loading an image, then loading a patch image, then executing the
first image.  (image_exec() checks for IMAGE_LOADED, so this sequence of
operations will fail if the LOADED flag gets cleared.)

This reverts commit 14c080020f.

Loading an image may overwrite part or all of any previously-loaded
images, so we should clear the LOADED flag for all images prior to
attempting to load a new image.

We can just treat all non-kernel images as initrds, which matches our
behaviour for multiboot kernels.  This allows us to eliminate initrd as
an image type, and treat the "initrd" command as just another synonym for
"imgfetch".

dhcppkt_store() is supposed to clear the setting if passed NULL for the
setting data.  In the case of fixed-location fields (e.g. client IP
address), this requires setting the content of the field to all-zeros.

__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.)

__from_data16 takes the value pointed to, rather than the pointer
itself.  This was silently causing gPXE to return a dud buffer pointer
when the caller did not supply a buffer for PXENV_GET_CACHED_INFO.

Perform the same test for a matching DHCP_SERVER_IDENTIFIER on
ProxyDHCPACKs as we do for DHCPACKs.  Otherwise, a retransmitted
DHCPACK can end up being treated as the ProxyDHCPACK.

I have a vague and unsettling memory that this test was deliberately
omitted, but I can't remember why, and can't find anything in the VC
logs.

Remove src/Config as it has no more users, and conflicts with
src/config on case-deficient filesystems.

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

ns8390.c can produce four different drivers (one PCI, three ISA.)  The
ISA driver requires setting a few macros; do that by setting defines
in stub files instead of using src/Config.

Currently, all the ISA drivers are broken (they were not enabled by
default), so #if 0 them out.

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

zImage kernels require the real-mode portion to be loaded at 9000:0000
rather than 1000:0000.

When the 16-bit segment registers are accessed using 32-bit instructions
the high order bytes are undefined on older CPUs.  We now explicitly
zero the high order bytes when snapshotting the CPU state.  This ensures
that the GDB stub reports consistent values for the segment registers.