ipxe.git
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>
8 years ago[natsemi] Check for ioremap() failures
Michael Brown [Wed, 16 Jul 2014 14:54:49 +0000 (15:54 +0100)] 
[natsemi] Check for ioremap() failures

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[myson] Check for ioremap() failures
Michael Brown [Wed, 16 Jul 2014 14:53:43 +0000 (15:53 +0100)] 
[myson] Check for ioremap() failures

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[skel] Check for ioremap() failures
Michael Brown [Wed, 16 Jul 2014 14:52:48 +0000 (15:52 +0100)] 
[skel] Check for ioremap() failures

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[vmxnet3] Check for ioremap() failures
Michael Brown [Wed, 16 Jul 2014 14:51:38 +0000 (15:51 +0100)] 
[vmxnet3] Check for ioremap() failures

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[realtek] Check for ioremap() failures
Michael Brown [Wed, 16 Jul 2014 14:50:18 +0000 (15:50 +0100)] 
[realtek] Check for ioremap() failures

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[intel] Check for ioremap() failures
Michael Brown [Wed, 16 Jul 2014 14:49:08 +0000 (15:49 +0100)] 
[intel] Check for ioremap() failures

Debugged-by: Anton D. Kachalov <mouse@yandex-team.ru>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[ioapi] Fail ioremap() when attempting to map a zero bus address
Michael Brown [Wed, 16 Jul 2014 14:27:16 +0000 (15:27 +0100)] 
[ioapi] Fail ioremap() when attempting to map a zero bus address

When a 32-bit iPXE binary is running on a system which allocates PCI
memory BARs above 4GB, our PCI subsystem will return the base address
for any such BARs as zero (with a warning message if DEBUG=pci is
enabled).  Currently, ioremap() will happily map an address pointing
to the start of physical memory, providing no sensible indication of
failure.

Fix by always returning NULL if we are asked to ioremap() a zero bus
address.

With a totally flat memory model (e.g. under EFI), this provides an
accurate failure indication since no PCI peripheral will be mapped to
the zero bus address.

With the librm memory model, there is the possibility of a spurious
NULL return from ioremap() if the bus address happens to be equal to
virt_offset.  Under the current virtual memory map, the NULL virtual
address will always be the start of .textdata, and so this problem
cannot occur; a NULL return from ioremap() will always be an accurate
failure indication.

Debugged-by: Anton D. Kachalov <mouse@yandex-team.ru>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Use EFI_CONSOLE_CONTROL_PROTOCOL to set text mode if available
Curtis Larsen [Wed, 16 Jul 2014 14:08:24 +0000 (15:08 +0100)] 
[efi] Use EFI_CONSOLE_CONTROL_PROTOCOL to set text mode if available

On some older EFI 1.10 implementations (observed with an old iMac), we
must use the (now obsolete) EFI_CONSOLE_CONTROL_PROTOCOL to switch the
console into text mode.

Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Include EFI_CONSOLE_CONTROL_PROTOCOL header
Michael Brown [Wed, 16 Jul 2014 13:15:40 +0000 (14:15 +0100)] 
[efi] Include EFI_CONSOLE_CONTROL_PROTOCOL header

The EFI_CONSOLE_CONTROL_PROTOCOL does not exist in the current UEFI
specification, but is required to enable text output on some older EFI
1.10 implementations (observed on an old iMac).

The header is not present in any of the standard include directories,
but can still be found in the EDK2 codebase as part of
EdkCompatibilityPkg.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Print well-known GUIDs by name in debug messages
Michael Brown [Wed, 16 Jul 2014 01:16:24 +0000 (02:16 +0100)] 
[efi] Print well-known GUIDs by name in debug messages

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Allow for interception of boot services calls by loaded image
Michael Brown [Wed, 16 Jul 2014 00:25:37 +0000 (01:25 +0100)] 
[efi] Allow for interception of boot services calls by loaded image

When building with DEBUG=efi_wrap, print details of calls made by the
loaded image to selected boot services functions.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Install our own disk I/O protocol and claim exclusive use of it
Michael Brown [Mon, 14 Jul 2014 15:15:05 +0000 (16:15 +0100)] 
[efi] Install our own disk I/O protocol and claim exclusive use of it

The EFI FAT filesystem driver has a bug: if a block device contains no
FAT filesystem but does have an EFI_SIMPLE_FILE_SYSTEM_PROTOCOL
instance, the FAT driver will assume that it must have previously
installed the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.  This causes the FAT
driver to claim control of our device, and to refuse to stop driving
it, which prevents us from later uninstalling correctly.

Work around this bug by opening the disk I/O protocol ourselves,
thereby preventing the FAT driver from opening it.

Note that the alternative approach of opening the block I/O protocol
(and thereby in theory preventing DiskIo from attaching to the block
I/O protocol) causes an endless loop of calls to our DRIVER_STOP
method when starting the EFI shell.  I have no idea why this is.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Update EDK2 headers
Michael Brown [Mon, 14 Jul 2014 15:13:55 +0000 (16:13 +0100)] 
[efi] Update EDK2 headers

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[netdevice] Reset network device index when last device is unregistered
Michael Brown [Mon, 14 Jul 2014 11:14:18 +0000 (12:14 +0100)] 
[netdevice] Reset network device index when last device is unregistered

When functioning as an EFI driver, drivers can be disconnected and
reconnected multiple times (e.g. via the EFI shell "connect" command,
or by running an executable such as ipxe.efi which will temporarily
disconnect existing drivers).

Minimise surprise by resetting the network device index to zero
whenever the last device is unregistered.  This is not foolproof, but
it does handle the common case of having all devices unregistered and
then reregistered in the original order.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[crypto] Fix debug message
Michael Brown [Sat, 12 Jul 2014 13:24:40 +0000 (14:24 +0100)] 
[crypto] Fix debug message

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[crypto] Add support for iPAddress subject alternative names
Michael Brown [Fri, 11 Jul 2014 15:55:14 +0000 (16:55 +0100)] 
[crypto] Add support for iPAddress subject alternative names

Originally-implemented-by: Jarrod Johnson <jarrod.b.johnson@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Include SNP NIC driver within the all-drivers target
Michael Brown [Tue, 8 Jul 2014 15:28:22 +0000 (16:28 +0100)] 
[efi] Include SNP NIC driver within the all-drivers target

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Rewrite SNP NIC driver
Michael Brown [Fri, 4 Jul 2014 15:52:10 +0000 (16:52 +0100)] 
[efi] Rewrite SNP NIC driver

Rewrite the SNP NIC driver to use non-blocking and deferrable
transmissions, to provide link status detection, to provide
information about the underlying (PCI) hardware device, and to avoid
unnecessary I/O buffer allocations during receive polling.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Attempt to start only drivers claiming support for a device
Michael Brown [Tue, 8 Jul 2014 00:02:35 +0000 (01:02 +0100)] 
[efi] Attempt to start only drivers claiming support for a device

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Identify autoboot device by MAC address when chainloading
Michael Brown [Mon, 7 Jul 2014 23:35:49 +0000 (00:35 +0100)] 
[efi] Identify autoboot device by MAC address when chainloading

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[autoboot] Allow autoboot device to be identified by link-layer address
Michael Brown [Mon, 7 Jul 2014 22:55:55 +0000 (23:55 +0100)] 
[autoboot] Allow autoboot device to be identified by link-layer address

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Allow network devices to be created on top of arbitrary SNP devices
Michael Brown [Tue, 1 Jul 2014 16:58:09 +0000 (17:58 +0100)] 
[efi] Allow network devices to be created on top of arbitrary SNP devices

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[build] Add yet another potential location for isolinux.bin
Michael Brown [Thu, 26 Jun 2014 16:05:36 +0000 (17:05 +0100)] 
[build] Add yet another potential location for isolinux.bin

Reported-by: Martin Sofaru <ipxe@fhloston.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[build] Fix erroneous object name in version object
Michael Brown [Thu, 26 Jun 2014 15:25:18 +0000 (16:25 +0100)] 
[build] Fix erroneous object name in version object

Commit 8290a95 ("[build] Expose build timestamp, build name, and
product names") introduced a regression in the build process which
resulted in broken final binaries which had names based on object
files (e.g. "undionly.kpxe" or "intel.rom") rather than on device IDs
(e.g. "8086100e.mrom").

The underlying problem is the -DOBJECT=<name> macro which is used to
generate the obj_<name> symbols used to select objects required for
the final binary.  The macro definition is derived from the initial
portion (up to the first dot) of the object being built.  In the case
of e.g. undionly.kpxe.version.o, this gives -DOBJECT=undionly.  This
results in undionly.kpxe.version.o claiming to be the "undionly"
object; the real "undionly" object will therefore never get dragged in
to the build.

Fix by renaming $(BIN)/%.version.o to $(BIN)/version.%.o, so that the
object is always built with -DOBJECT=version (as might be expected,
since it is built from core/version.c).

Final binaries which have names based on device IDs (such as
"8086100e.mrom") are not affected by this problem, since the object
name "8086100e" will not conflict with that of the underlying "intel"
object.

This problem was not detected by the per-commit smoke testing
procedure, which happens to use the binary bin/8086100e.mrom.

Reported-by: Christian Hesse <list@eworm.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Restructure EFI driver model
Michael Brown [Wed, 25 Jun 2014 13:47:35 +0000 (14:47 +0100)] 
[efi] Restructure EFI driver model

Provide a single instance of EFI_DRIVER_BINDING_PROTOCOL (attached to
our image handle); this matches the expectations scattered throughout
the EFI specification.

Open the underlying hardware device using EFI_OPEN_PROTOCOL_BY_DRIVER
and EFI_OPEN_PROTOCOL_EXCLUSIVE, to prevent other drivers from
attaching to the same device.

Do not automatically connect to devices when being loaded as a driver;
leave this task to the platform firmware (or to the user, if loading
directly from the EFI shell).

When running as an application, forcibly disconnect any existing
drivers from devices that we want to control, and reconnect them on
exit.

Provide a meaningful driver version number (based on the build
timestamp), to allow platform firmware to automatically load newer
versions of iPXE drivers if multiple drivers are present.

Include device paths within debug messages where possible, to aid in
debugging.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Provide a meaningful EFI SNP device name
Michael Brown [Wed, 25 Jun 2014 13:45:08 +0000 (14:45 +0100)] 
[efi] Provide a meaningful EFI SNP device name

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[efi] Allow device paths to be easily included in debug messages
Michael Brown [Wed, 25 Jun 2014 13:44:13 +0000 (14:44 +0100)] 
[efi] Allow device paths to be easily included in debug messages

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[build] Expose build timestamp, build name, and product names
Michael Brown [Wed, 18 Jun 2014 23:35:04 +0000 (00:35 +0100)] 
[build] Expose build timestamp, build name, and product names

Expose the build timestamp (measured in seconds since the Epoch) and
the build name (e.g. "rtl8139.rom" or "ipxe.efi"), and provide the
product name and product short name in a single centralised location.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[debug] Allow debug message colours to be customised via DBGCOL=...
Michael Brown [Mon, 16 Jun 2014 15:28:20 +0000 (16:28 +0100)] 
[debug] Allow debug message colours to be customised via DBGCOL=...

When multiple iPXE binaries are running concurrently (e.g. in the case
of undionly.kpxe using an underlying iPXE driver via the UNDI
interface) it would be helpful to be able to visually distinguish
debug messages from each binary.

Allow the range of debug colours used to be customised via the
DBGCOL=...  build parameter.  For example:

  # Restrict to colours 31-33 (red, green, yellow)
  make DBGCOL=31-33

  # Restrict to colours 34-36 (blue, magenta, cyan)
  make DBGCOL=34-36

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[build] Check if git index actually exists
Peter Lemenkov [Mon, 16 Jun 2014 12:35:23 +0000 (13:35 +0100)] 
[build] Check if git index actually exists

If iPXE is used as a git submodule then the ../.git/index file will
not exist, and the build will fail.  Fix by checking that the git
index file exists before adding it as a build dependency.

Signed-off-by: Peter Lemenkov <lemenkov@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[smbios] Expose board serial number as ${board-serial}
Dale Hamel [Mon, 10 Mar 2014 22:48:37 +0000 (18:48 -0400)] 
[smbios] Expose board serial number as ${board-serial}

With blade servers, the chassis serial number (exposed via ${serial})
may not be unique.  Expose ${board-serial} as a named setting to
provide easy access to a more meaningful serial number.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[igbvf] Allow changing of MAC address
Hannes Reinecke [Tue, 3 Jun 2014 12:01:17 +0000 (14:01 +0200)] 
[igbvf] Allow changing of MAC address

The VF might not have assigned a MAC address upon startup, and will
end up with a random MAC address during probe().  With this patch the
MAC address can be changed later on.

Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[igbvf] Assign random MAC address if none is set
Hannes Reinecke [Tue, 3 Jun 2014 12:01:16 +0000 (14:01 +0200)] 
[igbvf] Assign random MAC address if none is set

If the VF doesn't have a MAC address assigned we should create a
random MAC address.

Signed-off-by: Hannes Reinecke <hare@suse.de>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[iscsi] Include IP address origin in iBFT
Michael Brown [Thu, 12 Jun 2014 15:05:48 +0000 (16:05 +0100)] 
[iscsi] Include IP address origin in iBFT

The iBFT includes an "origin" field to indicate the source of the IP
address.  We use the heuristic of assuming that the source should be
"manual" if the IP address originates directly from the network device
settings block, and "DHCP" otherwise.  This is an imperfect guess, but
is likely to be correct in most common situations.

Originally-implemented-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[iscsi] Read IPv4 settings only from the relevant network device
Michael Brown [Thu, 12 Jun 2014 15:08:28 +0000 (16:08 +0100)] 
[iscsi] Read IPv4 settings only from the relevant network device

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[scsi] Improve sense code parsing
Michael Brown [Mon, 2 Jun 2014 01:17:28 +0000 (02:17 +0100)] 
[scsi] Improve sense code parsing

Parse the sense data to extract the reponse code, the sense key, the
additional sense code, and the additional sense code qualifier.

Originally-implemented-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 years ago[ethernet] Provide eth_random_addr() to generate random Ethernet addresses
Hannes Reinecke [Sun, 1 Jun 2014 22:26:20 +0000 (23:26 +0100)] 
[ethernet] Provide eth_random_addr() to generate random Ethernet addresses

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