Signed-off-by: Marty Connor <mdc@etherboot.org>

The NMB protocol code came from legacy Etherboot and was never updated
to work as a gPXE protocol.  There has been no demand for this protocol,
so this patch removes it.

Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>

The IGMP code came from legacy Etherboot and was never updated to work
as a gPXE protocol.  There has been no demand for this protocol, so this
patch removes it.

Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>

The NFS protocol code came from legacy Etherboot and was never updated
to work as a gPXE protocol.  There has been no demand for this protocol,
so this patch removes it.

I have an unfinished NFSv3 over TCP implementation for gPXE that can be
used as the base for new work, should we want to resurrect this
protocol.

Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>

The FSP protocol code came from legacy Etherboot and was never updated
to work as a gPXE protocol.  There has been no demand for this protocol,
so this patch removes it.

Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>

The .elf, .elfd, .lmelf, and .lmelfd prefices were brought over from
legacy Etherboot and they do not build in gPXE.  This patch removes the
ELF prefices.

Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>

The unfinished .exe prefix was brought over from legacy Etherboot.
There has been no demand for .exe images so this patch removes the
prefix.

Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>

The DOS .com prefix was brought over from legacy Etherboot but does not
build.  There has been no demand for .com images so this patch removes
the prefix.

Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>

The .lkrn prefix allows gPXE to be loaded as a Linux bzImage.  The
bImage prefix was carried over from legacy Etherboot and does not build.
This patch removes the .bImage prefix, use .lkrn instead.

Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>

Commit 3d9dd93 introduced a regression in HTTP: if a URI without a
path is specified (e.g. http://netboot.me), we send the empty string
as our GET request. Reintroduce an extra slash when uri->path is NULL,
to turn this into the expected GET /.

Reported-by: Kyle Kienapfel <doctor.whom@gmail.com>
Signed-off-by: Joshua Oreman <oremanj@rwcr.net>
Signed-off-by: Marty Connor <mdc@etherboot.org>

Previously, if none of the URI parts requested existed in the passed
URI, unparse_uri() would not touch the destination buffer at all; this
could lead to use of uninitialized data. Fix by setting buf[0] = '\0'
before unparsing whenever we have room to do so.

Signed-off-by: Joshua Oreman <oremanj@rwcr.net>
Signed-off-by: Marty Connor <mdc@etherboot.org>

The rtl818x driver uses programmed I/O but has a fallback to
memory-mapped I/O registers.  The fallback currently will not work since
the registers are accessed using inl()/outl() programmed I/O functions
in the driver.  This patch removes the fallback to we fail cleanly when
programmed I/O is not possible.

Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Joshua Oreman <oremanj@rwcr.net>
Signed-off-by: Marty Connor <mdc@etherboot.org>

This driver uses programmed I/O to access hardware registers.  There is
a stray memory-mapped I/O read on a programmed I/O address.  Perhaps
this is an artifact of porting the driver.  Fix this by converting it to
programmed I/O.

Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>

It might be the case that we wish to chain to an NBP without
being "in the way".  We now implement a hook in our exit path
for gPXE *.*pxe build targets.  The hook is a pointer to a
SEG16:OFF16 which we try to jump to during exit.  By default,
this pointer results in the usual exit path.

We also implement the "pxenv_file_exit_hook" PXE API routine
to allow the user to specify an alternate SEG16:OFF16 to jump
to during exit.

Unfortunately, this additional PXE extension has a cost
in code size.  Fortunately, a look at the size difference
for a gPXE .rom build target shows zero size difference
after compression.

The routine is documented in doc/pxe_extensions as follows:

FILE EXIT HOOK

Op-Code:	PXENV_FILE_EXIT_HOOK (00e7h)

Input:	Far pointer to a t_PXENV_FILE_EXIT_HOOK parameter
		structure that has been initialized by the caller.

Output:	PXENV_EXIT_SUCCESS or PXENV_EXIT_FAILURE must be
		returned in AX.  The Status field in the parameter
		structure must be set to one of the values represented
		by the PXENV_STATUS_xxx constants.

Description:Modify the exit path to jump to the specified code.
		Only valid for pxeprefix-based builds.

typedef struct s_PXENV_FILE_EXIT_HOOK {
        PXENV_STATUS_t Status;
        SEGOFF16_t Hook;
} t_PXENV_FILE_EXIT_HOOK;

Set before calling API service:

Hook:	The SEG16:OFF16 of the code to jump to.

Returned from API service:

Status:	See PXENV_STATUS_xxx constants.

Requested-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Shao Miller <shao.miller@yrdsb.edu.on.ca>
Signed-off-by: Marty Connor <mdc@etherboot.org>

Instead of keeping only the best IP and PXE offers, store all of them,
and pick the best to use just before a request is sent. This allows
priority differentiation to work even when lower-priority offers
provide PXE options, and improves robustness at sites with broken PXE
servers intermingled with working ones: when a ProxyDHCP request times
out, instead of giving up, we try the next PXE offer we've received.
It also allows us to avoid breaking up combined IP+PXE offers, which
can be important with some firewall configurations. This behavior
matches that of most vendor PXE ROMs.

Store a reference to the DHCPOFFER packet in the offer structure, so
that when registering settings after a successful ACK we can register
the proxy PXE settings we originally received; this removes the need
for a nonstandard duplicate REQUEST/ACK to port 67 of proxy servers
like dnsmasq that provide PXE options in the OFFER.

Total cost: 450 bytes uncompressed.

Signed-off-by: Marty Connor <mdc@etherboot.org>

This seems to be necessary for some types of PCI devices. We had
problems when using gPXE in KVM virtual machines with direct
PCI device access.

Signed-off-by: Bernhard Kohl <bernhard.kohl@nsn.com>
Signed-off-by: Shao Miller <shao.miller@yrdsb.edu.on.ca>
Modified-by: Marty Connor <mdc@etherboot.org>
Signed-off-by: Marty Connor <mdc@etherboot.org>

The default user and password are used for anonymous FTP by default.
This patch adds support for an explicit user name and password in an FTP
URI:

    imgfetch ftp://user:password@server.com/path/to/file

Edited-by: Stefan Hajnoczi <stefanha@gmail.com>.  Bugs are my fault.

Signed-off-by: Marty Connor <mdc@etherboot.org>

Currently, handling of URI escapes is ad-hoc; escaped strings are
stored as-is in the URI structure, and it is up to the individual
protocol to unescape as necessary. This is error-prone and expensive
in terms of code size. Modify this behavior by unescaping in
parse_uri() and escaping in unparse_uri() those fields that typically
handle URI escapes (hostname, user, password, path, query, fragment),
and allowing unparse_uri() to accept a subset of fields to print so
it can be easily used to generate e.g. the escaped HTTP path?query
request.

Signed-off-by: Joshua Oreman <oremanj@rwcr.net>
Signed-off-by: Marty Connor <mdc@etherboot.org>

A script loaded via autoboot may want to get some of the settings (MAC
address, IP address, et cetera) for the interface via which it was
loaded, in order to pass them to the operating system. Previously such
a script had no way to determine what to put in the X of ${netX/foo}.

Solve this problem by transparently forwarding accesses to the real
settings associated with the most recently opened network device,
so scripts in this situation can say literally ${netX/foo} and get
the foo setting they want.

Signed-off-by: Marty Connor <mdc@etherboot.org>

The standard option ROM format provides a header indicating the size
of the entire ROM, which the BIOS will reserve space for, load, and
call as necessary. However, this space is strictly limited to 128k for
all ROMs. gPXE ameliorates this somewhat by reserving space for itself
in high memory and relocating the majority of its code there, but on
systems prior to PCI3 enough space must still be present to load the
ROM in the first place. Even on PCI3 systems, the BIOS often limits the
size of ROM it will load to a bit over 64kB.

These space problems can be solved by providing an artificially small
size in the ROM header: just enough to let the prefix code (at the
beginning of the ROM image) be loaded by the BIOS. To the BIOS, the
gPXE ROM will appear to be only a few kilobytes; it can then load
the rest of itself by accessing the ROM directly using the PCI
interface reserved for that task.

There are a few problems with this approach. First, gPXE needs to find
an unmapped region in memory to map the ROM so it can read from it;
this is done using the crude but effective approach of scanning high
memory (over 0xF0000000) for a sufficiently large region of all-ones
(0xFF) reads. (In x86 architecture, all-ones is returned for accesses
to memory regions that no mapped device can satisfy.) This is not
provably valid in all situations, but has worked well in practice.
More importantly, this type of ROM access can only work if the PCI ROM
BAR exists at all. NICs on physical add-in PCI cards generally must
have the BAR in order for the BIOS to be able to load their ROM, but
ISA cards and LAN-on-Motherboard cards will both fail to load gPXE
using this scheme.

Due to these uncertainties, it is recommended that .xrom only be used
when a regular .rom image is infeasible due to crowded option ROM
space. However, when it works it could allow loading gPXE images
as large as a flash chip one could find - 128kB or even higher.

Signed-off-by: Marty Connor <mdc@etherboot.org>

For extremely tight space requirements and specific applications, it is
sometimes desirable to create gPXE images that cannot provide the PXE API
functionality to client programs. Add a configuration header option,
PXE_STACK, that can be removed to remove this stack. Also add PXE_MENU
to control the PXE boot menu, which most uses of gPXE do not need.

Signed-off-by: Marty Connor <mdc@etherboot.org>

If we don't unload the PXE stack before executing gPXE, automatically
take advantage of the cached DHCPACK that the underlying/parent PXE
stack can provide. If that cached DHCPACK contains option 175.178, or
the user sets the use-cached setting before invoking DHCP, the real
DHCP request will be skipped and the cached DHCPACK will be used for
network configuration. Otherwise, the cached settings block is thrown
away as soon as a fresh one is acquired.

Signed-off-by: Marty Connor <mdc@etherboot.org>

When a DHCP session is started (using autoboot or a command-line `dhcp
net0'), check whether the new setting use-cached (DHCP option 175.178)
is TRUE; if so, skip DHCP and rely on currently registered
settings. This lets one combine a static IP with autoboot.

Before checking the use-cached setting, call a weak
get_cached_dhcpack() hook that can be implemented by particular builds
of gPXE supporting some fashion of retrieving a cached DHCPACK packet.
If one is available, it is registered as an options source, and then
either that packet's option 175.178 or the user's prior manual
use-cached setting can allow skipping duplicate DHCP.

Using cached packets is not the default because DHCP servers are often
configured to give gPXE different options than they give a vendor PXE
client; in order to break the infinite loop of PXE chaining, one would
need to load a gPXE with an embedded image that does something more
than autoboot.

Signed-off-by: Marty Connor <mdc@etherboot.org>

Calling the parent PXE stack (the stack that loaded us, for
undionly.kkpxe) can be useful for more than UNDI calls; for instance,
it lets us get cached DHCP packets to avoid re-DHCP when working with
embedded images.

Signed-off-by: Marty Connor <mdc@etherboot.org>

Weak symbols are a useful tool in eliminating unnecessary dependencies
between object files, but they are somewhat dangerous because one must
remember to test the weak symbol against NULL before using it. To
rectify that, add macros for declaring weak functions that will return
a default value inline if the file defining them is not available at
link time.

Signed-off-by: Marty Connor <mdc@etherboot.org>

There is no defined error code for aborting a request but 0 is commonly
used.  This patch switches the abort request error code from
TFTP_ERR_UNKNOWN_TID (5) to 0.

Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>

pxenv_tftp_get_fsize is an API call that PXE clients can call to
obtain the size of a remote file. It is implemented by starting a TFTP
transfer with pxe_tftp_open, waiting for the response and then
stopping the transfer with pxe_tftp_close(). This leaves the session
hanging on the TFTP server and it will try to resend the packet
repeatedly (verified with tftpd-hpa) until it times out.

This patch adds a method "tftpsize" that will abort the transfer after
the first packet is received from the server. This will terminate the
session on the server and is the same behaviour as Intel's PXE ROM
exhibits.

Together with a qemu patch to handle the ERROR packet (submitted to
qemu's mailing list), this resolves a specific issue where booting
pxegrub with qemu's TFTP server would be slow or hang.

I've tested this against qemu's tftp server and against my normal boot
infrastructure (tftpd-hpa). Booting pxegrub and loading extra files
now produces a trace similar to Intel's PXE client and there are no
spurious retransmits from tftpd any more.

Signed-off-by: Thomas Horsten <thomas@horsten.com>
Signed-off-by: Milan Plzik <milan.plzik@gmail.com>
Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>

When the "keep-san" option is used, the function is exited without
unregistering the stack allocated int13h drive.  To prevent a dangling
pointer to the stack, these structs should be heap allocated.

Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>

The retry timer is used to retransmit TFTP packets lost on the network,
and to start a new connection.  There is an unnecessary delay while
waiting for name resolution because the timer period is fixed and cannot
be shortened when name resolution completes.  This patch keeps the timer
period at zero while name resolution takes place so that no time is lost
once before sending the first packet.

Reported-by: Thomas Horsten <thomas@horsten.com>
Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>

This patch adds TFTP support for files larger than 65535 blocks by
wrapping the 16-bit block number.

Reported-by: Mark Johnson <johnson.nh@gmail.com>
Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>

IBM's Tivoli Provisioning Manager for OS Deployment, when acting as a
ProxyDHCP server, sends an initial offer with a vendor class of "PXEClient"
and vendor-encapsulated options that have nothing to do with PXE. To
differentiate between this case and the case of a ProxyDHCP server that
sends all PXE options in its initial offer, modify gPXE to check for
the presence of an encapsulated PXE boot menu option (43.9) instead of
simply checking for the existence of any encapsulated options at all.
This is the same check used by the Intel vendor PXE ROM.

Signed-off-by: Marty Connor <mdc@etherboot.org>

The PXE standard provides examples of ProxyDHCP responses being encoded both
as type DHCPOFFER and DHCPACK, but currently we only accept DHCPACKs. Since
there are PXE servers in existence that respond to ProxyDHCPREQUESTs with
DHCPOFFERs, modify gPXE's ProxyDHCP pruning logic to treat both types of
responses equally.

Signed-off-by: Marty Connor <mdc@etherboot.org>

The previous [skge] commit should have been recorded as authored by
Thomas Miletich <thomas.miletich@gmail.com>

I mistakenly committed it improperly after fixing a merge issue.

Signed-off-by: Marty Connor <mdc@etherboot.org>

This code is based on the linux skge driver. It supports Marvell Yukon
and SysKonnect Gigabit chipsets.

The code is based on code Michael Decker <mrd999@gmail.com> wrote for
Google Summer of Code 2008.

Support for dual-port cards is untested. The code, however, was left
in. In my opinion it's easier to fix the code if we need to, instead
of having to add support for it from scratch.

Signed-off-by: Marty Connor <mdc@etherboot.org>

This is useful when comparing size optimizations.

Signed-off-by: Marty Connor <mdc@etherboot.org>

The bin/xxx.sizes targets examine the list of obj_ symbols in bin/xxx.tmp
to determine which objects to measure the size of. These symbols have been
normalized to C identifiers, so the result is an error message from `size'
when examining a target that includes objects that were originally named
with hyphens.

Fix by turning obj_foo_bar into $(wildcard bin/foo?bar.o) instead of
bin/foo_bar.o.

Signed-off-by: Marty Connor <mdc@etherboot.org>

Change the behaviour for adding DHCP options into a DHCP packet so
that we now append options, rather than insert them in front of
whatever options might already be present.

Apparently, the DHCP relay logic on a Nortel 470-48T layer 2 switch
cares about the order of DHCP options.  If we build a DHCP packet
pre-populated with some options, their order will now be preserved,
except for encapsulated options.

Signed-off-by: Marty Connor <mdc@etherboot.org>

Apparently, the DHCP relay logic on a Nortel 470-48T layer 2 switch
cares about the order of DHCP options.  Specifically, it requires
that the DHCP message type option be the first option present in the
DHCP packet.  We achieve this by having this option appear first in
our dhcp_request_options_data array, which pre-populates DHCP
requests.

Signed-off-by: Marty Connor <mdc@etherboot.org>

gPXE currently takes advantage of the feature of PCI3.0 that allows
option ROMs to relocate the bulk of their code to high memory and so
take up only a small amount of space in the option ROM area. Currently,
the relocation can only take place if the BIOS's implementation of PMM
can be made to return blocks aligned to an even megabyte, because of
the A20 gate. AMI BIOSes, in particular, will not return allocations
that gPXE can use.

Ameliorate the situation somewhat by adding a prefix, .hrom, that works
identically to .rom except in the case that PMM allocation fails. Where
.rom would give up and place itself entirely in option ROM space, .hrom
moves to a block (assumed free) at HIGHMEM_LOADPOINT = 4MB. This allows
for the use of larger gPXE ROMs than would otherwise be possible.

Because there is no way to check that the area at HIGHMEM_LOADPOINT is
really free, other devices using that memory during the boot process
will cause failure for gPXE, the other device, or both. In practice
such conflicts will likely not occur, but this prefix should still be
considered EXPERIMENTAL.

Signed-off-by: Marty Connor <mdc@etherboot.org>

This driver supports all current Myricom 10 gigabit Ethernet NICs.
It was written from scratch for gPXE by Glenn Brown <glenn@myri.com>,
referenencing Myricom's Linux and EFI drivers, with permission.

Signed-off-by: Glenn Brown <glenn@myri.com>
Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>

Taken from Linux /usr/include/linux/pci.h .

Signed-off-by: Glenn Brown <glenn@myri.com>
Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>

Tested-by: Boudhayan Gupta <bg13.ina@gmail.com>
Signed-off-by: Thomas Horsten <thomas@horsten.com>
Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>

Contrary to the IEEE specification, some access points apparently
set the Spectrum Mgmt bit in the capabilities field even when
broadcasting on a 2.4GHz band that does not require spectrum
management. Allow gPXE to attempt to connect to such networks;
if spectrum management is really required, our advertisement
of capabilities not including it will result in an association
failure.

Reported-by: Peter Meyer <residue@xmail.net>

Signed-off-by: Marty Connor <mdc@etherboot.org>

Wireless gPXE images are already so large that user-friendliness
seems to trump ROM-size friendliness in this case.

Signed-off-by: Marty Connor <mdc@etherboot.org>

Signed-off-by: Marty Connor <mdc@etherboot.org>

Signed-off-by: Marty Connor <mdc@etherboot.org>

Modified-by: Marty Connor <mdc@etherboot.org>
Signed-off-by: Marty Connor <mdc@etherboot.org>

Modified-by: Marty Connor <mdc@etherboot.org>
Signed-off-by: Marty Connor <mdc@etherboot.org>