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.

EFI passes in copies of SMBIOS and other system configuration tables
via the EFI system table.  Allow configuration tables to be requested
using a mechanism similar to the current method for requesting EFI
protocols.

This driver is based on Stefan Hajnoczi's summer work, which
is in turn based on version 1.01 of the linux b44 driver.
I just assembled the pieces and fixed/added a few pieces
here and there to make it work for my hardware.

The most major limitation is that this driver won't work
on systems with >1GB RAM due to the card not having enough
address bits for that and gPXE not working around this
limitation.

Still, other than that the driver works well enough for
at least 2 users :) and the above limitation can always
be fixed when somebody wants it bad enough :)

Signed-off-by: Pantelis Koukousoulas <pktoss@gmail.com>

There are currently four places within the codebase that use a
heuristic to guess the "boot network device", with varying degrees of
success.  Add a feature to the net device core to maintain a list of
open network devices, in order of opening, and provide a function
last_opened_netdev() to retrieve the most recently opened net device.
This should do a better job than the current assortment of
guess_boot_netdev() functions.

The AoE spec does not specify that the source MAC address of a
received packet actually matches the MAC address of the AoE target.
In principle an AoE server can respond to an AoE request on any
interface available to it, which may not be an address configured to
accept AoE requests.

This issue is resolved by implementing AoE device discovery.  The
purpose of AoE discovery is to find out which addresses an AoE target
can use for requests.  An AoE configuration command is sent when the
AoE attach is attempted.  The AoE target must respond to that
configuration query from an interface that can accept requests.

Based on a patch from Ryan Thomas <ryan@coraid.com>

Signed-off-by: Laurent Vivier <Laurent.Vivier@bull.net>

Signed-off-by: Laurent Vivier <Laurent.Vivier@bull.net>

Signed-off-by: Laurent Vivier <Laurent.Vivier@bull.net>

Signed-off-by: Laurent Vivier <Laurent.Vivier@bull.net>

Signed-off-by: Laurent Vivier <Laurent.Vivier@bull.net>

Remove various 32-bit assumptions scattered throughout the codebase.
The code is still not necessarily 64-bit clean, but will at least
compile.

EFI_STATUS is defined as an INTN, which maps to UINT32 (i.e. unsigned
int) on i386 and UINT64 (i.e. unsigned long) on x86_64.  This would
require a cast each time the error status is printed.

Add efi_strerror() to avoid this ickiness and simultaneously enable
prettier reporting of EFI status codes.

gcc 4.4 adds another few warnings, and also seems to complain if we
place %ebp in the clobber list for any inline asm.

The return path in directed route SMPs lists the egress ports in order
from SM to node, rather than from node to SM.

To write to the correct offset within the return path, we need to
parse the hop pointer.  This is held within the class-specific data
portion of the MAD header, which was previously unused by us and
defined to be a uint16_t.  Define this field to be a union type; this
requires some rearrangement of ib_mad.h and corresponding changes to
ipoib.c.

These cards very nearly support our current IB Verbs model.  There is
one minor difference: multicast packets will always be delivered by
the hardware to QP0, so the driver has to redirect them to the
appropriate QP.  This means that QP owners may see receive completions
for buffers that they never posted.  Nothing in our current codebase
will break because of this.

This can be used with cards that require the driver to construct and
parse packet headers manually.  Headers are optionally handled
out-of-line from the packet payload, since some such cards will split
received headers into a separate ring buffer.

This generic SMA code can be used for any cards that do not provide
firmware-based embedded SMAs.

Some Infiniband cards will not be as accommodating as the Arbel and
Hermon cards in providing enough space for us to push a fake extra
header at the start of the received packet.  We must therefore make do
with squeezing enough information to identify source and destination
addresses into the two bytes of padding within a genuine IPoIB
link-layer header.

Not all Infiniband cards have embedded subnet management agents.
Split out the code that communicates with such an embedded SMA into a
separate ib_smc.c file, and have drivers call ib_smc_update()
explicitly when they suspect that the answers given by the embedded
SMA may have changed.

Receive completion handlers now get passed an address vector
containing the information extracted from the packet headers
(including the GRH, if present), and only the payload remains in the
I/O buffer.

This breaks the symmetry between transmit and receive completions, so
remove the ib_completer_t type and use an ib_completion_queue_operations
structure instead.

Rename the "destination QPN" and "destination LID" fields in struct
ib_address_vector to reflect its new dual usage.

Since the ib_completion structure now contains only an IB status code,
("syndrome") replace it with a generic gPXE integer status code.

Both queue owners and drivers often need to keep track of the fill
level, so let's make it a generic property.

Avoid leaking I/O buffers in ib_destroy_qp() by completing any
outstanding work queue entries with a generic error code.  This
requires the completion handlers to be available to ib_destroy_qp(),
which is done by making them static configuration parameters of the CQ
(set by ib_create_cq()) rather than being provided on each call to
ib_poll_cq().

This mimics the functionality of netdev_{tx,rx}_flush().  The netdev
flush functions would previously have been catching any I/O buffers
leaked by the IPoIB data queue (though not by the IPoIB metadata
queue).

Add the simplified ne2k_isa driver.  It is just a selective copy+paste
of the relevant parts from ns8390.c plus a little trivial hacking to
make it actually work.

It is true that the code is pretty ugly, but:
  a) ns8390.c is worse
  b) It is only 372 lines and no #ifdefs
  c) It works both in qemu/bochs and in real hardware
     and we all know it is easier to cleanup working code

Hope someone will find the time to rewrite this driver properly,
but until then at least for me this is an ok solution.

Signed-off-by: Pantelis Koukousoulas <pktoss@gmail.com>

netdev_rx_err() and netdev_tx_complete_err() get passed the error
code, but currently use it only in debug messages.

Retain error numbers and frequencey counts for up to
NETDEV_MAX_UNIQUE_ERRORS (4) different errors for each of TX and RX.
This allows the "ifstat" command to report the reasons for TX/RX
errors in most cases, even in non-debug builds.

Settings can be constructed using a dotted-decimal notation, to allow
for access to unnamed settings.  The default interpretation is as a
DHCP option number (with encapsulated options represented as
"<encapsulating option>.<encapsulated option>".

In several contexts (e.g. SMBIOS, Phantom CLP), it is useful to
interpret the dotted-decimal notation as referring to non-DHCP
options.  In this case, it becomes necessary for these contexts to
ignore standard DHCP options, otherwise we end up trying to, for
example, retrieve the boot filename from SMBIOS.

Allow settings blocks to specify a "tag magic".  When dotted-decimal
notation is used to construct a setting, the tag magic value of the
originating settings block will be ORed in to the tag number.
Store/fetch methods can then check for the magic number before
interpreting arbitrarily-numbered settings.

This implementation is tested and working, but not currently tied in
to the EFI build.

EFI requires us to be able to specify the source address for
individual transmitted packets, and to be able to extract the
destination address on received packets.

Take advantage of this to rationalise the push() and pull() methods so
that push() takes a (dest,source,proto) tuple and pull() returns a
(dest,source,proto) tuple.

Multicast hashing is an ugly overlap between network and link layers.
EFI requires us to provide access to this functionality, so move it
out of ipv4.c and expose it as a method of the link layer.

Currently this length is set at device allocation time, and is never
changed.

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

Using start==0 to indicate a stopped timer is dangerous, because 0 is a
valid value for the current tick counter.

-Wformat-nonliteral is not enabled by -Wall and needs to be explicitly
 specified.

Modified the few files that use nonliteral format strings to work with
this new setting in place.

Inspired by a patch from Carl Karsten <carl@personnelware.com> and an
identical patch from Rorschach <r0rschach@lavabit.com>.

The intention is to include near-verbatim copies of the EFI headers
required by gPXE.  This is achieved using the import.pl script in
src/include/gpxe/efi.

Note that import.pl will modify any #include lines in each imported
header to reflect its new location within the gPXE tree.  It will also
tidy up the file by removing carriage return characters and trailing
whitespace.

Some devices (e.g. the Atmel AT24C11) have no concept of a device
address; they respond to every device address and use this value as
the word address.  Some other devices use part of the device address
field to extend the word address field.

Generalise the i2c bit-bashing support to handle this by defining the
device address length and word address length as properties of an i2c
device.  The word address is assumed to overflow into the device
address field if the address used exceeds the width of the word
address field.

Also add a bus reset mechanism.  i2c chips don't usually have a reset
line, so rebooting the host will not clear any bizarre state that the
chip may be in.  We reset the bus by clocking SCL until we see SDA
high, at which point we know we can generate a start condition and
have it seen by all devices.  We then generate a stop condition to
leave the bus in a known state prior to use.

Finally, add some extra debugging messages to i2c_bit.c.