ipxe.git
7 years ago[device] Provide a driver-private data field for root devices
Michael Brown [Thu, 18 Dec 2014 14:38:45 +0000 (14:38 +0000)] 
[device] Provide a driver-private data field for root devices

Signed-off-by: Michael Brown <mcb30@ipxe.org>
7 years ago[malloc] Report caller address as soon as memory corruption is detected
Michael Brown [Mon, 15 Dec 2014 14:48:02 +0000 (14:48 +0000)] 
[malloc] Report caller address as soon as memory corruption is detected

Signed-off-by: Michael Brown <mcb30@ipxe.org>
7 years ago[malloc] Check integrity of free list
Michael Brown [Mon, 15 Dec 2014 14:45:05 +0000 (14:45 +0000)] 
[malloc] Check integrity of free list

Check the integrity of the free memory block list before and after any
modifications to the list.  We check that certain invariants are
preserved:

 - the list is a well-formed doubly linked list

 - all blocks are at least MIN_MEMBLOCK_SIZE

 - no block extends beyond the end of our address space

 - blocks remain sorted in ascending order of address

 - no blocks are adjacent (i.e. any adjacent blocks have been merged)

Signed-off-by: Michael Brown <mcb30@ipxe.org>
7 years ago[malloc] Sanity check parameters to alloc_memblock() and free_memblock()
Michael Brown [Mon, 15 Dec 2014 14:42:26 +0000 (14:42 +0000)] 
[malloc] Sanity check parameters to alloc_memblock() and free_memblock()

Signed-off-by: Michael Brown <mcb30@ipxe.org>
7 years ago[malloc] Tidy up debug output
Michael Brown [Mon, 15 Dec 2014 14:34:59 +0000 (14:34 +0000)] 
[malloc] Tidy up debug output

Colourise debug output and move per-allocation messages to DBGLVL_EXTRA.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
7 years ago[list] Add sanity checks after list-adding functions
Michael Brown [Tue, 9 Dec 2014 13:12:01 +0000 (13:12 +0000)] 
[list] Add sanity checks after list-adding functions

Signed-off-by: Michael Brown <mcb30@ipxe.org>
7 years ago[libc] Add ASSERTED macro to test if any assertion has triggered
Michael Brown [Wed, 10 Dec 2014 01:45:30 +0000 (01:45 +0000)] 
[libc] Add ASSERTED macro to test if any assertion has triggered

Signed-off-by: Michael Brown <mcb30@ipxe.org>
7 years ago[netdevice] Fix erroneous use of free(iobuf) instead of free_iob(iobuf)
Michael Brown [Tue, 9 Dec 2014 23:49:11 +0000 (23:49 +0000)] 
[netdevice] Fix erroneous use of free(iobuf) instead of free_iob(iobuf)

Signed-off-by: Michael Brown <mcb30@ipxe.org>
7 years ago[vmxnet3] Add profiling code to exclude time spent in the hypervisor
Michael Brown [Fri, 12 Dec 2014 10:16:26 +0000 (10:16 +0000)] 
[vmxnet3] Add profiling code to exclude time spent in the hypervisor

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[crypto] Fix parsing of OCSP responder ID key hash
Michael Brown [Mon, 24 Nov 2014 14:55:07 +0000 (14:55 +0000)] 
[crypto] Fix parsing of OCSP responder ID key hash

We currently compare the entirety of the KeyHash object (including the
ASN.1 tag and length byte) against the raw SHA-1 hash of the
certificate's public key.  This causes OCSP validation to fail for any
responses which identify the responder by key hash rather than by
name, and hence prevents the use of X.509 certificates where any
certificate in the chain has an OCSP responder which chooses to
identify itself via its key hash.

Fix by adding the missing asn1_enter() required to enter the ASN.1
octet string containing the key hash.

Also add a corresponding test case including an OCSP response where
the responder is identified by key hash, to ensure that this
functionality cannot be broken in future.

Debugged-by: Brian Rak <brak@gameservers.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[intel] Use autoloaded MAC address instead of EEPROM MAC address
Michael Brown [Fri, 31 Oct 2014 15:18:54 +0000 (15:18 +0000)] 
[intel] Use autoloaded MAC address instead of EEPROM MAC address

The i350 (and possibly other Intel NICs) have a non-trivial
correspondence between the PCI function number and the external
physical port number.  For example, the i350 has a "LAN Function Sel"
bit within the EEPROM which can invert the mapping so that function 0
becomes port 3, function 1 becomes port 2, etc.

Unfortunately the MAC addresses within the EEPROM are indexed by
physical port number rather than PCI function number.  The end result
is that when anything other than the default mapping is used, iPXE
will use the wrong address as the base MAC address.

Fix by using the autoloaded MAC address if it is valid, and falling
back to reading the MAC address directly from the EEPROM only if no
autoloaded address is available.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[ping] Allow "ping" command output to be inhibited
Michael Brown [Thu, 23 Oct 2014 15:52:08 +0000 (16:52 +0100)] 
[ping] Allow "ping" command output to be inhibited

Originally-implemented-by: Cedric Levasseur <cyr-ius@ipocus.net>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[ping] Allow termination after a specified number of packets
Michael Brown [Thu, 23 Oct 2014 15:30:58 +0000 (16:30 +0100)] 
[ping] Allow termination after a specified number of packets

Add the "-c <count>" option to the "ping" command, allowing for
automatic termination after a specified number of packets.

When a number of packets is specified:

  - if a serious error (i.e. length mismatch or content mismatch)
    occurs, then the ping will be immediately terminated with the relevant
    status code;

  - if at least one response is received successfully, and all errors
    are non-serious (i.e. timeouts or out-of-sequence responses), then
    the ping will be terminated after the final response (or timeout)
    with a success status;

  - if no responses are received successfully, then the ping will be
    terminated after the final timeout with ETIMEDOUT.

If no number of packets is specified, then the ping will continue
until manually interrupted.

Originally-implemented-by: Cedric Levasseur <cyr-ius@ipocus.net>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[ping] Report timed-out pings via the callback function
Michael Brown [Thu, 23 Oct 2014 14:04:10 +0000 (15:04 +0100)] 
[ping] Report timed-out pings via the callback function

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Include NII driver within "snp" and "snponly" build targets
Michael Brown [Fri, 17 Oct 2014 15:36:00 +0000 (16:36 +0100)] 
[efi] Include NII driver within "snp" and "snponly" build targets

End users almost certainly don't care whether the underlying interface
is SNP or NII/UNDI.  Try to minimise surprise and unnecessary
documentation by including the NII driver whenever the SNP driver is
requested.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Check for presence of UNDI in NII protocol
Michael Brown [Fri, 17 Oct 2014 15:50:45 +0000 (16:50 +0100)] 
[efi] Check for presence of UNDI in NII protocol

iPXE itself exposes a dummy NII protocol with no UNDI.  Avoid
potentially dereferencing a NULL pointer by checking for a non-zero
UNDI address.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Add NII / UNDI driver
Michael Brown [Fri, 3 Oct 2014 12:17:22 +0000 (13:17 +0100)] 
[efi] Add NII / UNDI driver

Some UEFI network drivers provide a software UNDI interface which is
exposed via the Network Interface Identifier Protocol (NII), rather
than providing a Simple Network Protocol (SNP).

The UEFI platform firmware will usually include the SnpDxe driver,
which attaches to NII and provides an SNP interface.  The SNP
interface is usually provided on the same handle as the underlying NII
device.  This causes problems for our EFI driver model: when
efi_driver_connect() detaches existing drivers from the handle it will
cause the SNP interface to be uninstalled, and so our SNP driver will
not be able to attach to the handle.  The platform firmware will
eventually reattach the SnpDxe driver and may attach us to the SNP
handle, but we have no way to prevent other drivers from attaching
first.

Fix by providing a driver which can attach directly to the NII
protocol, using the software UNDI interface to drive the network
device.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Update to current EDK2 headers
Michael Brown [Wed, 15 Oct 2014 13:45:17 +0000 (14:45 +0100)] 
[efi] Update to current EDK2 headers

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Generalise snpnet_dev_info() to efi_device_info()
Michael Brown [Tue, 30 Sep 2014 17:06:13 +0000 (18:06 +0100)] 
[efi] Generalise snpnet_dev_info() to efi_device_info()

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Free transmit ring entry before calling netdev_tx_complete()
Michael Brown [Thu, 16 Oct 2014 13:09:27 +0000 (14:09 +0100)] 
[efi] Free transmit ring entry before calling netdev_tx_complete()

The snpnet driver uses netdev_tx_defer() and so must ensure that space
in the (single-entry) transmit descriptor ring is freed up before
calling netdev_tx_complete().

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[intel] Add 8086:1557 card (Intel 82599 10G ethernet mezz)
Anton D. Kachalov [Tue, 30 Sep 2014 19:38:27 +0000 (23:38 +0400)] 
[intel] Add 8086:1557 card (Intel 82599 10G ethernet mezz)

Signed-off-by: Anton D. Kachalov <mouse@yandex-team.ru>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Add definitions of GUIDs observed when chainloading from Intel driver
Michael Brown [Thu, 25 Sep 2014 12:16:44 +0000 (13:16 +0100)] 
[efi] Add definitions of GUIDs observed when chainloading from Intel driver

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Centralise definitions of more protocol GUIDs
Michael Brown [Thu, 25 Sep 2014 11:28:38 +0000 (12:28 +0100)] 
[efi] Centralise definitions of more protocol GUIDs

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[build] Use -malign-double to build 32-bit UEFI binaries
Michael Brown [Wed, 24 Sep 2014 15:07:04 +0000 (16:07 +0100)] 
[build] Use -malign-double to build 32-bit UEFI binaries

The EDK2 codebase uses -malign-double for 32-bit builds, which causes
64-bit integers to be naturally aligned.  This affects the layout of
some structures (including EFI_BLOCK_IO_MEDIA).

This mirrors wimboot commit 7b8f39d ("[build] Fix building of 32-bit
UEFI version").

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[dhcp] Remove obsolete dhcp_chaddr() function
Michael Brown [Mon, 22 Sep 2014 15:41:10 +0000 (16:41 +0100)] 
[dhcp] Remove obsolete dhcp_chaddr() function

As of commit 03f0c23 ("[ipoib] Expose Ethernet-compatible eIPoIB
link-layer addresses and headers"), all link layers have used
addresses which fit within the DHCP chaddr field.  The dhcp_chaddr()
function was therefore made obsolete by this commit, but was
accidentally left present (though unused) in the source code.

Remove the dhcp_chaddr() function and the only remaining use of it,
unnecessarily introduced in commit 08bcc0f ("[dhcp] Check for matching
chaddr in received DHCP packets").

Reported-by: Wissam Shoukair <wissams@mellanox.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[dhcp] Check for matching chaddr in received DHCP packets
Michael Brown [Mon, 22 Sep 2014 14:29:13 +0000 (15:29 +0100)] 
[dhcp] Check for matching chaddr in received DHCP packets

On large networks a DHCP XID collision is possible.  Fix by explicitly
checking the chaddr in received DHCP packets.

Originally-fixed-by: Wissam Shoukair <wissams@mellanox.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Provide dummy device path in efi_image_probe()
Michael Brown [Fri, 19 Sep 2014 12:16:31 +0000 (13:16 +0100)] 
[efi] Provide dummy device path in efi_image_probe()

Some UEFI platforms will fail the call to LoadImage() with
EFI_INVALID_PARAMETER if we do not provide a device path (even though
we are providing a non-NULL SourceBuffer).

Fix by providing an empty device path for the call to LoadImage() in
efi_image_probe().

The call to LoadImage() in efi_image_exec() already constructs and
provides a device path (based on the most recently opened SNP device),
and so does not require this fix.

Reported-by: NICOLAS CATTIE <nicolas.cattie@mpsa.com>
Tested-by: NICOLAS CATTIE <nicolas.cattie@mpsa.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[intel] Add I217-LM PCI ID
Jan Kiszka [Mon, 15 Sep 2014 06:00:06 +0000 (08:00 +0200)] 
[intel] Add I217-LM PCI ID

Add the ID for the LM variant and differentiate it from the I217-V.

Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Add efifatbin utility
Michael Brown [Wed, 10 Sep 2014 01:58:50 +0000 (02:58 +0100)] 
[efi] Add efifatbin utility

Add utility for constructing EFI fat binaries (dual 32/64-bit
binaries, usable only on Apple EFI systems).

This utility is not part of the standard build process.  To use it:

  make util/efifatbin bin-i386-efi/ipxe.efi bin-x86_64-efi/ipxe.efi

and then

  ./util/efifatbin bin-*-efi/ipxe.efi fat-ipxe.efi

Requested-by: Brandon Penglase <bpenglase-ipxe@spaceservices.net>
Tested-by: Brandon Penglase <bpenglase-ipxe@spaceservices.net>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[build] Clean up all binary directories on "make [very]clean"
Michael Brown [Thu, 4 Sep 2014 15:46:59 +0000 (16:46 +0100)] 
[build] Clean up all binary directories on "make [very]clean"

Allow a straightforward "make clean" or "make veryclean" to apply to
all binary directories (using the shell pattern "bin{,-*}").
Individual binary directories can be cleaned using e.g.

  make bin clean
  make bin-x86_64-efi clean

Reported-by: Robin Smidsrød <robin@smidsrod.no>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Allow for non-PCI snpnet devices
Michael Brown [Thu, 4 Sep 2014 15:18:08 +0000 (16:18 +0100)] 
[efi] Allow for non-PCI snpnet devices

We currently require information about the underlying PCI device to
populate the snpnet device's name and description.  If the underlying
device is not a PCI device, this will fail and prevent the device from
being registered.

Fix by falling back to populating the device description with
information based on the EFI handle, if no PCI device information is
available.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Make EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL optional
Michael Brown [Thu, 4 Sep 2014 15:03:10 +0000 (16:03 +0100)] 
[efi] Make EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL optional

Some UEFI systems (observed with a Hyper-V virtual machine) do not
provide EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.  Make this an optional
protocol (and fail any attempts to access PCI configuration space via
the root bridge if the protocol is missing).

Reported-by: Colin Blacker <Colin.Blacker@computerplanet.co.uk>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Avoid returning uninitialised data from PCI configuration space reads
Michael Brown [Thu, 4 Sep 2014 15:00:11 +0000 (16:00 +0100)] 
[efi] Avoid returning uninitialised data from PCI configuration space reads

Under UEFI, reads from PCI configuration space may fail.  If this
happens, we should return all-ones (which will mimic the behaviour of
an absent PCI device).

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Use the SNP protocol instance to match the SNP chainloading device
Michael Brown [Wed, 20 Aug 2014 12:15:00 +0000 (13:15 +0100)] 
[efi] Use the SNP protocol instance to match the SNP chainloading device

Some systems will install a child of the SNP device and use this as
our loaded image's device handle, duplicating the installation of the
underlying SNP protocol onto the child device handle.  On such
systems, we want to end up driving the parent device (and
disconnecting any other drivers, such as MNP, which may be attached to
the parent device).

Fix by recording the SNP protocol instance at initialisation time, and
using this to match against device handles (rather than simply
comparing the handles themselves).

Reported-by: Jarrod Johnson <jarrod.b.johnson@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Wrap any images loaded by our wrapped image
Michael Brown [Fri, 29 Aug 2014 12:10:18 +0000 (13:10 +0100)] 
[efi] Wrap any images loaded by our wrapped image

Propagate our modified EFI system table to any images loaded by the
image that we wrap, thereby allowing us to observe boot services calls
made by all subsequent EFI images.

Also show details of intercepted ExitBootServices() calls.  When
wrapping is used, exiting boot services will almost certainly fail,
but this at least allows us to see when it happens.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Make our virtual file system case insensitive
Michael Brown [Wed, 27 Aug 2014 02:13:43 +0000 (03:13 +0100)] 
[efi] Make our virtual file system case insensitive

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Show details of intercepted LoadImage() calls
Michael Brown [Wed, 27 Aug 2014 02:13:12 +0000 (03:13 +0100)] 
[efi] Show details of intercepted LoadImage() calls

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[mromprefix] Allow for .mrom images larger than 128kB
Michael Brown [Tue, 26 Aug 2014 11:33:40 +0000 (12:33 +0100)] 
[mromprefix] Allow for .mrom images larger than 128kB

The .mrom payload has a code type of 0xff and so the initialisation
length field (single byte at offset 0x02) does not need to be
present.  Use only the PCI header's image length field, which allows
the .mrom payload to be up to 32MB in size.

Inspired-by: Swift Geek <swiftgeek@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[mromprefix] Use PCI length field to obtain length of individual images
Michael Brown [Tue, 26 Aug 2014 11:29:54 +0000 (12:29 +0100)] 
[mromprefix] Use PCI length field to obtain length of individual images

mromprefix.S currently uses the initialisation length field (single
byte at offset 0x02) to determine the length of a ROM image within a
multi-image ROM BAR.  For PCI ROM images with a code type other than
0, the initialisation length field may not be present.

Fix by using the PCI header's image length field instead.

Inspired-by: Swift Geek <swiftgeek@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[util] Use PCI length field to obtain length of individual images
Michael Brown [Tue, 26 Aug 2014 10:42:42 +0000 (11:42 +0100)] 
[util] Use PCI length field to obtain length of individual images

Option::ROM currently uses the initialisation length field (single
byte at offset 0x02) to determine the length of a ROM image within a
multi-image ROM file.  For PCI ROM images with a code type other than
0, the initialisation length field may not be present.

Fix by using the PCI header's image length field instead.  Note that
this does not prevent us from correctly handling ISA ROMs, since ISA
ROMs do not support multiple images within a single ROM BAR anyway.

Inspired-by: Swift Geek <swiftgeek@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[prefix] Report both %esi and %ecx when opening payload fails
Michael Brown [Tue, 26 Aug 2014 13:53:46 +0000 (14:53 +0100)] 
[prefix] Report both %esi and %ecx when opening payload fails

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[prefix] Halt system without burning CPU if we cannot access the payload
Michael Brown [Tue, 26 Aug 2014 13:46:14 +0000 (14:46 +0100)] 
[prefix] Halt system without burning CPU if we cannot access the payload

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[build] Avoid deleting config header files if build is interrupted
Michael Brown [Tue, 26 Aug 2014 14:05:48 +0000 (15:05 +0100)] 
[build] Avoid deleting config header files if build is interrupted

With extremely unlucky timing, it is possible to interrupt a build and
cause make to delete config/named.h (and possibly any local
configuration headers).

Mark config/named.h and all local configuration headers as .PRECIOUS
to prevent make from ever deleting them.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[build] Avoid using embedded script in VirtualBox named configuration
Robin Smidsrød [Fri, 22 Aug 2014 17:27:00 +0000 (19:27 +0200)] 
[build] Avoid using embedded script in VirtualBox named configuration

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[build] Allow ISA ROMs to be built
Michael Brown [Thu, 21 Aug 2014 15:34:26 +0000 (16:34 +0100)] 
[build] Allow ISA ROMs to be built

The build process has for a long time assumed that every ROM is a PCI
ROM, and will always include the PCI header and PCI-related
functionality (such as checking the PCI BIOS version, including the
PCI bus:dev.fn address within the ROM product name string, etc.).

While real ISA cards are no longer in use, some virtualisation
environments (notably VirtualBox) have support only for ISA ROMs.
This can cause problems: in particular, VirtualBox will call our
initialisation entry point with random garbage in %ax, which we then
treat as the PCI bus:dev.fn address of the autoboot device: this
generally prevents the default boot sequence from using any network
devices.

Create .isarom and .pcirom prefixes which can be used to explicitly
specify the type of ROM to be created.  (Note that the .mrom prefix
always implies a PCI ROM, since the .mrom mechanism relies on
reconfiguring PCI BARs.)

Make .rom a magic prefix which will automatically select the
appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or
ISA_ROM() macro.  To maintain backwards compatibility, we default to
building a PCI ROM for anything which is not directly derived from a
PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom).

Add a selection of targets to "make everything" to ensure that the
(relatively obscure) ISA ROM build process is included within the
per-commit QA checks.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[build] Remove obsolete references to .zrom build targets
Michael Brown [Fri, 22 Aug 2014 15:40:30 +0000 (16:40 +0100)] 
[build] Remove obsolete references to .zrom build targets

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[romprefix] Do not preserve unused register %di
Michael Brown [Thu, 21 Aug 2014 14:59:11 +0000 (15:59 +0100)] 
[romprefix] Do not preserve unused register %di

Since some PnP BIOSes fail to set %es:di to point to the PnP signature
on entry, we identify a PnP BIOS by scanning through the top 64kB of
base memory looking for the PnP structure.  We therefore don't
actually use the values of %es:di provided to the initialisation entry
point, and so there is no need to preserve them.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Dump details of any calls to our dummy block and disk I/O protocols
Michael Brown [Fri, 22 Aug 2014 13:57:15 +0000 (14:57 +0100)] 
[efi] Dump details of any calls to our dummy block and disk I/O protocols

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Add definitions of GUIDs observed during Windows boot
Michael Brown [Thu, 21 Aug 2014 15:54:23 +0000 (16:54 +0100)] 
[efi] Add definitions of GUIDs observed during Windows boot

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[build] Add named configuration for VirtualBox
Robin Smidsrød [Thu, 21 Aug 2014 14:59:17 +0000 (16:59 +0200)] 
[build] Add named configuration for VirtualBox

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[intel] Apply PBS/PBA errata workaround only to ICH8 PCI device IDs
Michael Brown [Wed, 20 Aug 2014 23:15:45 +0000 (00:15 +0100)] 
[intel] Apply PBS/PBA errata workaround only to ICH8 PCI device IDs

ICH8 devices have an errata which requires us to reconfigure the
packet buffer size (PBS) register, and correspondingly adjust the
packet buffer allocation (PBA) register.  The "Intel I/O Controller
Hub ICH8/9/10 and 82566/82567/82562V Software Developer's Manual"
notes for the PBS register that:

  10.4.20   Packet Buffer Size - PBS (01008h; R/W)

  Note: The default setting of this register is 20 KB and is
        incorrect. This register must be programmed to 16 KB.

  Initial value: 0014h
                 0018h (ICH9/ICH10)

It is unclear from this comment precisely which devices require the
workaround to be applied.  We currently attempt to err on the side of
caution: if we detect an initial value of either 0x14 or 0x18 then the
workaround will be applied.  If the workaround is applied
unnecessarily, then the effect should be just that we use less than
the full amount of the available packet buffer memory.

Unfortunately this approach does not play nicely with other device
drivers.  For example, the Linux e1000e driver will rewrite PBA while
assuming that PBS still contains the default value, which can result
in inconsistent values between the two registers, and a corresponding
inability to transmit or receive packets.  Even more unfortunately,
the contents of PBS and PBA are not reset by anything less than a
power cycle, meaning that this error condition will survive a hardware
reset.

The Linux driver (written and maintained by Intel) applies the PBS/PBA
errata workaround only for devices in the ICH8 family, identified via
the PCI device ID.  Adopt a similar approach, using the PCI_ROM()
driver data field to indicate when the workaround is required.

Reported-by: Donald Bindner <dbindner@truman.edu>
Debugged-by: Donald Bindner <dbindner@truman.edu>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[intel] Display before and after values for both PBS and PBA
Michael Brown [Wed, 20 Aug 2014 22:16:01 +0000 (23:16 +0100)] 
[intel] Display before and after values for both PBS and PBA

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[intel] Display PBS value when applying ICH errata workaround
Michael Brown [Wed, 20 Aug 2014 21:59:54 +0000 (22:59 +0100)] 
[intel] Display PBS value when applying ICH errata workaround

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[build] Allow for named configurations at build time
Michael Brown [Tue, 19 Aug 2014 15:17:25 +0000 (16:17 +0100)] 
[build] Allow for named configurations at build time

Allow named configurations to be specified via the CONFIG=... build
parameter.  For headers in config/*.h which support named
configurations, the following files will be included when building
with CONFIG=<name>:

  - config/defaults/<platform>.h (e.g. config/defaults/pcbios.h)

  - config/<header>.h

  - config/<name>/<header>.h (only if the directory config/<name> exists)

  - config/local/<header>.h (autocreated if necessary)

  - config/local/<name>/<header>.h (autocreated if necessary)

This mechanism allows for predefined named configurations to be
checked in to the source tree, as a directory config/<name> containing
all of the required header files.

The mechanism also allows for users to define multiple local
configurations, by creating header files in the directory
config/local/<name>.

Note that the config/*.h files which are used only to configure
internal iPXE APIs (e.g. config/ioapi.h) cannot be modified via a
named configuration.  This avoids rebuilding the entire iPXE codebase
whenever switching to a different named configuration.

Inspired-by: Robin Smidsrød <robin@smidsrod.no>
Tested-by: Robin Smidsrød <robin@smidsrod.no>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[smc9000] Avoid using CONFIG as a preprocessor macro
Michael Brown [Tue, 19 Aug 2014 13:38:27 +0000 (14:38 +0100)] 
[smc9000] Avoid using CONFIG as a preprocessor macro

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[readline] Add CTRL-W shortcut to remove a word
Marin Hannache [Tue, 19 Aug 2014 11:05:36 +0000 (12:05 +0100)] 
[readline] Add CTRL-W shortcut to remove a word

Signed-off-by: Marin Hannache <git@mareo.fr>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[xen] Cope with unexpected initial backend states
Michael Brown [Wed, 13 Aug 2014 23:03:43 +0000 (00:03 +0100)] 
[xen] Cope with unexpected initial backend states

Under some circumstances (e.g. if iPXE itself is booted via iSCSI, or
after an unclean reboot), the backend may not be in the expected
InitWait state when iPXE starts up.

There is no generic reset mechanism for Xenbus devices.  Recent
versions of xen-netback will gracefully perform all of the required
steps if the frontend sets its state to Initialising.  Older versions
(such as that found in XenServer 6.2.0) require the frontend to
transition through Closed before reaching Initialising.

Add a reset mechanism for netfront devices which does the following:

 - read current backend state

 - if backend state is anything other than InitWait, then set the
   frontend state to Closed and wait for the backend to also reach
   Closed

 - set the frontend state to Initialising and wait for the backend to
   reach InitWait.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[xen] Use version 1 grant tables by default
Michael Brown [Wed, 13 Aug 2014 16:23:11 +0000 (17:23 +0100)] 
[xen] Use version 1 grant tables by default

Using version 1 grant tables limits guests to using 16TB of grantable
RAM, and prevents the use of subpage grants.  Some versions of the Xen
hypervisor refuse to allow the grant table version to be set after the
first grant references have been created, so the loaded operating
system may be stuck with whatever choice we make here.  We therefore
currently use version 2 grant tables, since they give the most
flexibility to the loaded OS.

Current versions (7.2.0) of the Windows PV drivers have no support for
version 2 grant tables, and will merrily create version 1 entries in
what the hypervisor believes to be a version 2 table.  This causes
some confusion.

Avoid this problem by attempting to use version 1 tables, since
otherwise we may render Windows unable to boot.

Play nicely with other potential bootloaders by accepting either
version 1 or version 2 grant tables (if we are unable to set our
requested version).

Note that the use of version 1 tables on a 64-bit system introduces a
possible failure path in which a frame number cannot fit into the
32-bit field within the v1 structure.  This in turn introduces
additional failure paths into netfront_transmit() and
netfront_refill_rx().

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[xen] Accept alternative Xen platform PCI device ID 5853:0002
Michael Brown [Wed, 13 Aug 2014 12:17:33 +0000 (13:17 +0100)] 
[xen] Accept alternative Xen platform PCI device ID 5853:0002

At some point during XenServer development history, the Windows PV
drivers changed to using a PCI device ID of 5853:0002 rather than
5853:0001.  Current (7.2.0) drivers will bind to either 5853:0001 or
5853:0002, and the general approach taken by the world at large
(including Amazon EC2) seems to be to use only 5853:0001.

However, the current version of XenServer (6.2.0) will create the
platform device as 5853:0002 (via the platform:device_id VM parameter)
for any VMs created using the built-in templates for Windows Vista or
later.

Accept either PCI ID, since the underlying device is identical.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[readline] Ensure cursor is visible when prompting for input
Michael Brown [Wed, 6 Aug 2014 14:11:38 +0000 (15:11 +0100)] 
[readline] Ensure cursor is visible when prompting for input

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Support displaying and hiding cursor
Michael Brown [Wed, 6 Aug 2014 14:11:18 +0000 (15:11 +0100)] 
[efi] Support displaying and hiding cursor

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[bios] Support displaying and hiding cursor
Michael Brown [Wed, 6 Aug 2014 14:10:58 +0000 (15:10 +0100)] 
[bios] Support displaying and hiding cursor

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Generalise snpnet_pci_info() to efi_locate_device()
Michael Brown [Wed, 6 Aug 2014 13:04:02 +0000 (14:04 +0100)] 
[efi] Generalise snpnet_pci_info() to efi_locate_device()

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Move abstract device path and handle functions to efi_utils.c
Michael Brown [Wed, 6 Aug 2014 12:52:41 +0000 (13:52 +0100)] 
[efi] Move abstract device path and handle functions to efi_utils.c

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Try various possible SNP receive filters
Curtis Larsen [Tue, 5 Aug 2014 18:27:10 +0000 (19:27 +0100)] 
[efi] Try various possible SNP receive filters

The behavior observed in the Apple EFI (1.10) RecieveFilters() call
is:

  - failure if any of the PROMISCUOUS or MULTICAST filters are
    included

  - success if only UNICAST is included, however the result is
    UNICAST|BROADCAST

  - success if only UNICAST and BROADCAST are included

  - if UNICAST, or UNICAST|BROADCAST are used, but the previous call
    tried (and failed) to set UNICAST|BROADCAST|MULTICAST, then the
    result is UNICAST|BROADCAST|MULTICAST

Work around this apparently broken SNP implementation by trying
RecieveFilterMask, then falling back to UNICAST|BROADCAST|MULTICAST,
then UNICAST|BROADCAST, and finally UNICAST.

Modified-by: Michael Brown <mcb30@ipxe.org>
Tested-by: Curtis Larsen <larsen@dixie.edu>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Open device path protocol only at point of use
Michael Brown [Tue, 5 Aug 2014 19:49:42 +0000 (20:49 +0100)] 
[efi] Open device path protocol only at point of use

Some EFI 1.10 systems (observed on an Apple iMac) do not allow us to
open the device path protocol with an attribute of
EFI_OPEN_PROTOCOL_BY_DRIVER and so we cannot maintain a safe,
long-lived pointer to the device path.  Work around this by instead
opening the device path protocol with an attribute of
EFI_OPEN_PROTOCOL_GET_PROTOCOL whenever we need to use it.

Debugged-by: Curtis Larsen <larsen@dixie.edu>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Provide centralised definitions of commonly-used GUIDs
Michael Brown [Tue, 5 Aug 2014 22:07:12 +0000 (23:07 +0100)] 
[efi] Provide centralised definitions of commonly-used GUIDs

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Reset multicast filter list when setting SNP receive filters
Michael Brown [Tue, 5 Aug 2014 17:00:17 +0000 (18:00 +0100)] 
[efi] Reset multicast filter list when setting SNP receive filters

According to the UEFI specification, the MCastFilter parameter (which
we currently pass as NULL, along with a zero MCastFilterCnt) is
optional only if ResetMCastFilter is true.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Add ability to dump SNP device mode information
Michael Brown [Tue, 5 Aug 2014 16:32:16 +0000 (17:32 +0100)] 
[efi] Add ability to dump SNP device mode information

Originally-implemented-by: Curtis Larsen <larsen@dixie.edu>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Report errors from attempting to disconnect existing drivers
Curtis Larsen [Tue, 5 Aug 2014 15:45:01 +0000 (16:45 +0100)] 
[efi] Report errors from attempting to disconnect existing drivers

Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Print raw device path when we have no DevicePathToTextProtocol
Michael Brown [Fri, 1 Aug 2014 09:51:15 +0000 (10:51 +0100)] 
[efi] Print raw device path when we have no DevicePathToTextProtocol

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Also try original ComponentName protocol for retrieving driver names
Michael Brown [Fri, 1 Aug 2014 09:36:25 +0000 (10:36 +0100)] 
[efi] Also try original ComponentName protocol for retrieving driver names

The ComponentName and ComponentName2 protocols differ only in the
standard which is used for language name codes.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Add excessive sanity checks into efi_debug functions
Michael Brown [Thu, 31 Jul 2014 23:03:39 +0000 (00:03 +0100)] 
[efi] Add excessive sanity checks into efi_debug functions

Try very hard to avoid ever doing something invalid while attempting
to generate a debug message.

Debugged-by: Curtis Larsen <larsen@dixie.edu>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Improve debugging of the debugging facilities
Michael Brown [Thu, 31 Jul 2014 22:44:43 +0000 (23:44 +0100)] 
[efi] Improve debugging of the debugging facilities

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Dump handle information around connect/disconnect attempts
Michael Brown [Thu, 31 Jul 2014 11:45:18 +0000 (12:45 +0100)] 
[efi] Dump handle information around connect/disconnect attempts

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Dump existing openers when we are unable to open a protocol
Michael Brown [Thu, 31 Jul 2014 11:28:26 +0000 (12:28 +0100)] 
[efi] Dump existing openers when we are unable to open a protocol

Dump the existing openers of a protocol whenever we are unable to open
a protocol using attributes of BY_DEVICE, EXCLUSIVE, or
BY_CHILD_CONTROLLER.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Avoid unnecessarily passing pointers to EFI_HANDLEs
Michael Brown [Thu, 31 Jul 2014 11:22:40 +0000 (12:22 +0100)] 
[efi] Avoid unnecessarily passing pointers to EFI_HANDLEs

efi_file_install() and efi_download_install() are both used to install
onto existing handles.  There is therefore no need to allow for each
of their calls to InstallMultipleProtocolInterfaces() to create a new
handle.

By passing the handle directly (rather than a pointer to the handle),
we avoid potential confusion (and erroneous debug message colours).

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Allow compiler to perform type checks on EFI_HANDLE
Michael Brown [Thu, 31 Jul 2014 11:17:59 +0000 (12:17 +0100)] 
[efi] Allow compiler to perform type checks on EFI_HANDLE

The EFI headers define EFI_HANDLE as a void pointer, which renders
type checking on anything dealing with EFI handles somewhat useless.
Work around this bizarre sabotage attempt by redefining EFI_HANDLE as
a pointer to an anonymous structure.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Use efi_handle_name() instead of efi_devpath_text() where applicable
Michael Brown [Thu, 31 Jul 2014 10:21:09 +0000 (11:21 +0100)] 
[efi] Use efi_handle_name() instead of efi_devpath_text() where applicable

Using efi_devpath_text() is marginally more efficient if we already
have the device path protocol available, but the mild increase in
efficiency is not worth compromising the clarity of the pattern:

  DBGC ( device, "THING %p %s ...", device, efi_handle_name ( device ) );

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Use efi_handle_name() instead of efi_handle_devpath_text()
Michael Brown [Thu, 31 Jul 2014 09:44:25 +0000 (10:44 +0100)] 
[efi] Use efi_handle_name() instead of efi_handle_devpath_text()

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Add ability to dump all openers of a given protocol on a handle
Michael Brown [Wed, 30 Jul 2014 23:09:58 +0000 (00:09 +0100)] 
[efi] Add ability to dump all openers of a given protocol on a handle

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Provide efi_handle_name() for debugging
Michael Brown [Wed, 30 Jul 2014 23:05:04 +0000 (00:05 +0100)] 
[efi] Provide efi_handle_name() for debugging

Provide a function efi_handle_name() (as a generalisation of
efi_handle_devpath_text()) which tries various methods to produce a
human-readable name for an EFI handle.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Expand the range of well-known EFI GUIDs in debug messages
Michael Brown [Wed, 30 Jul 2014 23:00:18 +0000 (00:00 +0100)] 
[efi] Expand the range of well-known EFI GUIDs in debug messages

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Ignore failures when attempting to install SNP HII protocol
Michael Brown [Wed, 30 Jul 2014 17:44:09 +0000 (18:44 +0100)] 
[efi] Ignore failures when attempting to install SNP HII protocol

HII seems to fail on several systems.  Since it is non-essential,
treat HII problems as non-fatal.

Debugged-by: Curtis Larsen <larsen@dixie.edu>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[netdevice] Avoid registering duplicate network devices
Michael Brown [Wed, 30 Jul 2014 17:11:20 +0000 (18:11 +0100)] 
[netdevice] Avoid registering duplicate network devices

Reject network devices which appear to be duplicates of those already
available via a different underlying hardware device.  On a Xen PV-HVM
system, this allows us to filter out the emulated PCI NICs (which
would otherwise appear alongside the netfront NICs).

Note that we cannot use the Xen facility to "unplug" the emulated PCI
NICs, since there is no guarantee that the OS we subsequently load
will have a native netfront driver.

We permit devices with the same MAC address if they are attached to
the same underlying hardware device (e.g. VLAN devices).

Inspired-by: Marin Hannache <git@mareo.fr>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Report exact failure when unable to open the device path
Michael Brown [Wed, 30 Jul 2014 16:53:51 +0000 (17:53 +0100)] 
[efi] Report exact failure when unable to open the device path

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Fix incorrect debug message level when device has no device path
Michael Brown [Wed, 30 Jul 2014 16:15:39 +0000 (17:15 +0100)] 
[efi] Fix incorrect debug message level when device has no device path

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Fill in loaded image's DeviceHandle if firmware fails to do so
Michael Brown [Wed, 30 Jul 2014 15:16:10 +0000 (16:16 +0100)] 
[efi] Fill in loaded image's DeviceHandle if firmware fails to do so

Some EFI 1.10 implementations (observed with a mid-2011 iMac) seem to
fail to fill in the DeviceHandle for our loaded images.  It is
plausible that these implementations fill in the DeviceHandle only if
loading the image from a device path (rather than directly from a
memory buffer).

Work around this problem by filling in DeviceHandle if the firmware
leaves it empty.

We cannot sensibly fill in FilePath, because we have no way of knowing
whether or not the firmware will treat this as a pointer to be freed
when the image returns.

Reported-by: Curtis Larsen <larsen@dixie.edu>
Tested-by: Curtis Larsen <larsen@dixie.edu>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Unload started images only on failure
Michael Brown [Wed, 30 Jul 2014 15:07:25 +0000 (16:07 +0100)] 
[efi] Unload started images only on failure

If the StartImage() call returns with no error, then the image must
have been started and returned successfully.  It either unloaded
itself, or it intended to remain loaded (e.g. it was a driver).  We
therefore do not unload successful images.

If there was an error, we attempt to unload the image.  This may not
work.  In particular, there is no way to tell whether an error
returned from StartImage() was due to being unable to start the image
(in which case we probably should call UnloadImage()), or due to the
image itself returning an error (in which case we probably should not
call UnloadImage()).  We therefore ignore any failures from the
UnloadImage() call itself.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Default to releasing network devices for use via SNP
Michael Brown [Wed, 30 Jul 2014 13:21:10 +0000 (14:21 +0100)] 
[efi] Default to releasing network devices for use via SNP

We currently treat network devices as available for use via the SNP
API only if RX queue processing has been frozen.  (This is similar in
spirit to the way that RX queue processing is frozen for the network
device currently exposed via the PXE API.)

The default state of a freshly created network device is for the RX
queue to not be frozen, and thus to be unavailable for use via SNP.
This causes problems when devices are added through code paths other
than _efidrv_start() (which explicitly releases devices for use via
SNP).

We don't actually need to freeze RX queue processing, since calls via
the SNP API will always use netdev_poll() rather than net_poll(), and
so will never trigger the RX queue processing code path anyway.

We can therefore simplify the code to use a single global flag to
indicate whether network devices are claimed for use by iPXE or
available for use via SNP.  Using a global flag allows the default
state for dynamically created network devices to behave sensibly.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[xen] Add support for Xen netfront virtual NICs
Michael Brown [Mon, 28 Jul 2014 22:39:28 +0000 (23:39 +0100)] 
[xen] Add support for Xen netfront virtual NICs

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[xen] Add basic support for PV-HVM domains
Michael Brown [Mon, 28 Jul 2014 22:38:30 +0000 (23:38 +0100)] 
[xen] Add basic support for PV-HVM domains

Add basic support for Xen PV-HVM domains (detected via the Xen
platform PCI device with IDs 5853:0001), including support for
accessing configuration via XenStore and enumerating devices via
XenBus.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[xen] Import selected public headers
Michael Brown [Mon, 28 Jul 2014 22:32:53 +0000 (23:32 +0100)] 
[xen] Import selected public headers

Import selected headers from the xen/include/public directory of the
Xen repository at git://xenbits.xen.org/xen.git

The script ./include/xen/import.pl can be used to automatically import
any required headers and their dependencies (in a similar fashion to
./include/ipxe/efi/import.pl).  Trailing whitespace is stripped and an
appropriate FILE_LICENCE declaration is added to each header file.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[lotest] Discard packets arriving on the incorrect network device
Michael Brown [Tue, 29 Jul 2014 14:15:28 +0000 (15:15 +0100)] 
[lotest] Discard packets arriving on the incorrect network device

Commit 24bbaf6 ("[lotest] Allow loopback testing on shared networks")
introduced a regression in which loopback testing packets would be
accepted from any network device.  This produces unexpected results,
such as VLAN loopback testing succeeding even when incorrectly using
the underlying trunk device as either transmitter or receiver.

Fix by discarding any loopback testing packets which arrive on a
network device other than the current loopback testing receiver.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[ioapi] Centralise notion of PAGE_SIZE
Michael Brown [Sat, 26 Jul 2014 14:31:08 +0000 (15:31 +0100)] 
[ioapi] Centralise notion of PAGE_SIZE

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[build] Set GITVERSION only if there is a git repository
Florian Schmaus [Mon, 28 Jul 2014 15:47:48 +0000 (16:47 +0100)] 
[build] Set GITVERSION only if there is a git repository

The $(BIN)/version.%.o target will fail if iPXE is built within a
non-git repository, e.g. when the user downloaded and extracted an
archive containing iPXE sources, *and* if any parent directory of the
iPXE sources is a git repository (or even contains a directory named
".git").  This is because git will by default ascend the directory
tree and look for ".git".

The problem typically manifests on source based distributions, see for
example https://bugs.gentoo.org/show_bug.cgi?id=482804

Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Show more diagnostic information when building with DEBUG=efi_wrap
Michael Brown [Sat, 26 Jul 2014 10:22:36 +0000 (11:22 +0100)] 
[efi] Show more diagnostic information when building with DEBUG=efi_wrap

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[lacp] Set "aggregatable" flag in response LACPDU
Sven Ulland [Mon, 21 Jul 2014 13:41:25 +0000 (15:41 +0200)] 
[lacp] Set "aggregatable" flag in response LACPDU

Some switches do not allow an individual link (as defined in IEEE Std
802.3ad-2000 section 43.3.5) to work alone in a link aggregation group
as described in section 43.3.6.  This is verified on Dell's
PowerConnect M6220, based on the Broadcom Strata XGS-IV chipset.

Set the LACP_STATE_AGGREGATABLE flag in the actor.state field to
announce link aggregation in the response LACPDU, which will have the
switch enable the link aggregation group and allow frames to pass.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[x86_64] Add functions to read and write model-specific registers
Michael Brown [Sun, 20 Jul 2014 10:10:24 +0000 (11:10 +0100)] 
[x86_64] Add functions to read and write model-specific registers

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[i386] Add functions to read and write model-specific registers
Michael Brown [Sun, 20 Jul 2014 10:10:00 +0000 (11:10 +0100)] 
[i386] Add functions to read and write model-specific registers

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