[intel] Add Intel I210 Gigabit Ethernet PCI ID

Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Ensure EFI binaries comply with Authenticode requirements

Authenticode requires that the size of the raw file must equal the
size of the OptionalHeader.SizeOfHeaders plus the sum of all sections'
SizeOfRawData.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[netdevice] Add vlan_tag() to get the VLAN tag of a network device

The iBFT has a VLAN field that should be filled in.  Add the
vlan_tag() function to extract the VLAN tag of a network device.

Since VLAN support is optional, define a weak function that returns 0
when iPXE is built without VLAN support.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[iscsi] Include 802.1Q VLAN identifier in iBFT

The iBFT NIC section has a VLAN field which must be filled in so that
iSCSI booting works over VLANs.

Unfortunately it is unclear from the IBM specification linked in
ibft.c whether the VLAN field is just the 802.1Q VLAN Identifier or
the full 802.1Q TCI.  For now just fill in the VID, the Priority Code
Point and Drop Eligible Indicator could be set in the future if it
turns out they should be present too.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[netdevice] Separate VLAN support from presence of VLAN-supporting drivers

Some NICs (e.g. Hermon) provide hardware support for stripping the
VLAN tag, but do not provide any way for this support to be disabled.
Drivers for this hardware must therefore call vlan_find() to identify
a suitable receiving network device.

Provide a weak version of vlan_find() which will always return NULL if
VLAN support has not been enabled (either directly, or by enabling
a feature such as FCoE which requires VLAN support).  This allows the
VLAN code to be omitted from builds where the user has not requested
support for VLANs.

Inspired-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[tg3] Fix various tg3 issues

Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[undi] Work around specific devices with known broken interrupt behaviour

Some PXE stacks are known to claim that IRQs are supported, but then
never generate interrupts.  No satisfactory solution has been found to
this problem; the workaround is to add the PCI vendor and device IDs
to a list of devices which will be treated as simply not supporting
interrupts.

This is something of a hack, since it will generate false positives
for identical devices with a working PXE stack (e.g. those that have
been reflashed with iPXE), but it's an improvement on the current
situation.

Reported-by: Richard Moore <rich@richud.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[zbin] Fix size used for memset in alloc_output_file

The output->buf field is a pointer, not an array, so sizeof() is not
applicable.  We must use the allocated string length instead.

Identified by gcc:

  util/zbin.c: In function ‘alloc_output_file’:
  util/zbin.c:146:37: warning: argument to ‘sizeof’ in ‘memset’ call
    is the same expression as the destination; did you mean to
    dereference it? [-Wsizeof-pointer-memaccess]
  memset ( output->buf, 0xff, sizeof ( output->buf ) );

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[menu] Prevent character code zero from acting as a shortcut key

Unrecognised keys may be returned by getkey() as character code zero,
which currently matches against the first menu item with no shortcut
key defined.

Prevent this unintended behaviour by explicitly checking that the menu
item has a defined shortcut key.

Reported-by: Ján ONDREJ (SAL) <ondrejj@salstar.sk>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[menu] Prevent separators with shortcut keys from being selected

Nothing currently prevents a menu separator from being assigned a
shortcut key, and then from being selected using that shortcut key.
This produces an inconsistency in the user interface, since separators
cannot be selected by other means of menu navigation (arrow keys, page
up/down, etc).

It would be trivial to prevent separators from being assigned shortcut
keys, but this would eliminate one potentially useful use case: having
a large menu and using shortcut keys to jump to a section within the
menu.

Fix by treating a shortcut key on a separator as equivalent to "select
the separator, then press the down arrow key".  This has the effect of
moving to the first non-separator menu item following the specified
separator, which is probably the most intuitive behaviour.  (The
existing logic for moving the selection already handles the various
nasty corner cases such as a menu ending with one or more separators.)

Reported-by: Ján ONDREJ (SAL) <ondrejj@salstar.sk>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[tftp] Allow TFTP block size to be controlled via the PXE TFTP API

The PXE TFTP API allows the caller to request a particular TFTP block
size.  Since mid-2008, iPXE has appended a "?blksize=xxx" parameter to
the TFTP URI constructed internally; nothing has ever parsed this
parameter.  Nobody seems to have cared that this parameter has been
ignored for almost five years.

Fix by using xfer_window(), which provides a fairly natural way to
convey the block size information from the PXE TFTP API to the TFTP
protocol layer.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Add vmware build target

Add "make vmware" build target, to build all of the ROMs used with
VMware.

Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[pcbios] Add extra debugging messages when unhiding iPXE from memory

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[nbiprefix] Set up real-mode stack before jumping to .text16

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[prefix] Use %cs as implicit parameter to uninstall()

romprefix.S currently calls uninstall() with an invalid value in %ax.
Consequently, base memory is not freed after a ROM boot attempt (or
after entering iPXE during POST).

The uninstall() function is physically present in .text16, and so can
use %cs to determine the .text16 segment address.  The .data16 segment
address is not required, since uninstall() is called only by code
paths which set up .data16 to immediately follow .text16.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[pcbios] Inhibit all calls to INT 15,e820 and INT 15,e801 during POST

Many BIOSes do not construct the full system memory map until after
calling the option ROM initialisation entry points.  For several
years, we have added sanity checks and workarounds to accommodate
charming quirks such as BIOSes which report the entire 32-bit address
space (including all memory-mapped PCI BARs) as being usable RAM.

The IBM x3650 takes quirky behaviour to a new extreme.  Calling either
INT 15,e820 or INT 15,e801 during POST doesn't just get you invalid
data.  We could cope with invalid data.  Instead, these nominally
read-only API calls manage to trash some internal BIOS state, with the
result that the system memory map is _never_ constructed.  This tends
to confuse subsequent bootloaders and operating systems.

[ GRUB 0.97 fails in a particularly amusing way.  Someone thought it
would be a good idea for memcpy() to check that the destination memory
region is a valid part of the system memory map; if not, then memcpy()
will sulk, fail, and return NULL.  This breaks pretty much every use
of memcpy() including, for example, those inserted implicitly by gcc
to copy non-const initialisers.  Debugging is _fun_ when a simple call
to printf() manages to create an infinite recursion, exhaust the
available stack space, and shut down the CPU. ]

Fix by completely inhibiting calls to INT 15,e820 and INT 15,e801
during POST.

We do now allow relocation during POST up to the maximum address
returned by INT 15,88 (which seems so far to always be safe).  This
allows us to continue to have a reasonable size of external heap, even
if the PMM allocation is close to the 1MB mark.

The downside of allowing relocation during POST is that we may
overwrite PMM-allocated memory in use by other option ROMs.  However,
the downside of inhibiting relocation, when combined with also
inhibiting calls to INT 15,e820 and INT 15,e801, would be that we
might have no external heap available: this would make booting an OS
impossible and could prevent some devices from even completing
initialisation.

On balance, the lesser evil is probably to allow relocation during
POST (up to the limit provided by INT 15,88).  Entering iPXE during
POST is a rare operation; on the even rarer systems where doing so
happens to overwrite a PMM-allocated region, then there exists a
fairly simple workaround: if the user enters iPXE during POST and
wishes to exit iPXE, then the user must reboot.  This is an acceptable
cost, given the rarity of the situation and the simplicity of the
workaround.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[romprefix] Display only one "Ctrl-B" prompt per PCI device during POST

If a multifunction PCI device exposes an iPXE ROM via each function,
then each function will display a "Press Ctrl-B to configure iPXE"
prompt, and delay for two seconds.  Since a single instance of iPXE
can drive all functions on the multifunction device, this simply adds
unnecessary delay to the boot process.

Fix by inhibiting the "Press Ctrl-B" prompt for all except the first
function on a PCI device.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Update to latest EDK2 headers

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[autoboot] Split main control flow out of main() into a new function ipxe()

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Add last_opened_snpdev()

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