[e1000] Use the alternate MAC in NVRAM when available
The 82571 supports an alternate MAC address location in NVRAM.
When this is set, use this for the MAC rather than the default
physical MAC address.
Ported from linux-2.6.git 93ca161027
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Tested-by: Thomas Miletich <thomas.miletich@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>
[e820mangler] Add missing CLC ins. for success path
The get_underlying_e820 function should return with CF unset on success.
Reported-by: Timothy Stack <tstack@vmware.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>
[linker] Add mechanism for subsystem-dependent configuration options
It is often the case that some module of gPXE is only relevant if the
subsystem it depends on is already being included. For instance,
commands to manage wireless interfaces are quite useless if no
compiled-in driver has pulled in the wireless networking stack. There
may be a user-modifiable configuration options for these dependent
modules, but even if enabled, they should not be included when they
would be useless.
Solve this by allowing the creation of config_subsystem.c, for
configuration directives like those in the global config.c that should
only be considered when subsystem.c is included in the final gPXE
build.
For consistency, move core/config.c to the config/ directory, where
the other config_subsystem.c files will eventually reside.
Signed-off-by: Marty Connor <mdc@etherboot.org>
[linker] Expand and correct symbol requirement macros
REQUIRE_SYMBOL() formerly used a formulation of symbol requirement
that would allow a link to succeed despite lacking a required symbol,
because it did not introduce any relocations. Fix by renaming it to
REQUEST_SYMBOL() (since the soft-requirement behavior can be useful)
and add a REQUIRE_SYMBOL() that truly requires.
Add EXPORT_SYMBOL() and IMPORT_SYMBOL() for REQUEST_SYMBOL()-like
behavior that allows one to make use of the symbol, by combining a
weak external on the symbol itself with a REQUEST_SYMBOL() of a second
symbol.
Signed-off-by: Marty Connor <mdc@etherboot.org>
[pxebs] Consistently interpret PXE type field as little-endian
The PXE menu code also treated the type as big-endian, which went
unnoticed until the first fix because its ntohs() was matched by a
htons() in the PXE boot server discovery code.
Signed-off-by: Marty Connor <mdc@etherboot.org>
[int13] Guard against BIOSes that "fix" the drive count
Some BIOSes (observed with an AMI BIOS on a SunFire X2200) seem to
reset the BIOS drive counter at 40:75 after a failed boot attempt.
This causes problems when attempting a Windows direct-to-iSCSI
installation: bootmgr.exe calls INT 13,0800 and gets told that there
are no hard disks, so never bothers to read the MBR in order to obtain
the boot disk signature. The Windows iSCSI initiator will detect the
iBFT and connect to the target, and everything will appear to work
except for the error message "This computer's hardware may not support
booting to this disk. Ensure that the disk's controller is enabled in
the computer's BIOS menu."
Fix by checking the BIOS drive counter on every INT 13 call, and
updating it whenever necessary.
[autoboot] Ensure that an error message is always printed for a boot failure
The case of an unsupported SAN protocol will currently not result in
any error message. Fix by printing the error message at the top level
using strerror(), rather than using hard-coded error messages in the
error paths.
[susieq] Update qib_genbits.pl to handle SusieQ definitions
The latest RTL-generated register lists include (mostly redundant)
xxx_MSB values alongside xxx_LSB and xxx_RMASK, and also include
default register values.
Some subnet managers expect the GetResponse from a SetPortInfo MAD to
contain the new link state. The transition is not immediate, so we
often end up returning the previous link state. This can cause the SM
to fail to activate the port.
Fix by waiting for up to 20us for the link state transition to take
effect.
[ipoib] Mask out non-QPN bits in the IPoIB destination MAC when sending
The first byte of the IPoIB MAC address is used for flags indicating
support for "connected mode". Strip out the non-QPN bits of the first
dword when constructing the address vector for transmitted IPoIB
packets, so as not to end up passing an invalid QPN in the BTH.
[infiniband] Make node description invariant across all ports
IBA section 14.2.5.2 states that "the contents of the NodeDescription
attribute are the same for all ports on a node". Satisfy this by
using the HCA GUID rather than the port GUID to form the node
description string.
[ipv4] Ignore non-open net devices when performing routing
We do not discard routing table entries when closing an interface. It
is plausible that multiple interfaces may be on the same physical
network; if so, then we may end up in a situation whereby outbound
packets attempt to route via a closed interface.
Fix by ignoring non-open net devices in ipv4_route().
ipv4.c calculates the default subnet mask before calling
fetch_ipv4_setting() to retrieve the configured subnet mask (if any).
However, as of commit 612f4e7 "[settings] Avoid returning
uninitialised data on error in fetch_xxx_setting()",
fetch_ipv4_setting() will zero the IP address if the setting does not
exist, rather than leaving it unaltered.
Fix by fetching the setting first and calculating the default subnet
mask only if necessary.
[ipv4] Use a zero address to indicate "no gateway", rather than INADDR_NONE
ipv4.c uses a gateway address of INADDR_NONE to represent "no
gateway". It initialises the gateway address to INADDR_NONE before
calling fetch_ipv4_setting() to retrieve the configured gateway
address (if any).
However, as of commit 612f4e7 "[settings] Avoid returning
uninitialised data on error in fetch_xxx_setting()",
fetch_ipv4_setting() will zero the IP address if the setting does not
exist, rather than leaving it unaltered.
Fix by using a zero IP address to indicate "no gateway", so that a
non-existent gateway address setting will be treated as such.
The PXE type field is canonically little-endian, but the pxebs command
treats it as big-endian in converting the type number passed on the
command line to a field value to search against. Fix, to prevent the
necessity of incantations like "pxebs net0 1536" to select menu item #6.
Signed-off-by: Michael Brown <mcb30@etherboot.org>
Modified-by: Michael Brown <mcb30@etherboot.org>
Error message was:
[BUILD] bin/atl1e.oncc1: warnings being treated as errors
drivers/net/atl1e.c: In function 'atl1e_get_permanent_address':
drivers/net/atl1e.c:1326: error: dereferencing type-punned pointer will break strict-aliasing rules
make: *** [bin/atl1e.o] Error 1
Reported-by: Giandomenico De Tullio <ghisha@email.it>
Signed-off-by: Michael Brown <mcb30@etherboot.org>
Modified-by: Michael Brown <mcb30@etherboot.org>
[netdevice] Add the concept of an "Ethernet-compatible" MAC address
The iBFT is Ethernet-centric in providing only six bytes for a MAC
address. This is most probably an indirect consequence of a similar
design flaw in the Windows NDIS stack. (The WinOF IPoIB stack
performs all sorts of contortions in order to pretend to the NDIS
layer that it is dealing with six-byte MAC addresses.)
There is no sensible way in which to extend the iBFT without breaking
compatibility with programs that expect to parse it. Add the notion
of an "Ethernet-compatible" MAC address to our link layer abstraction,
so that link layers can provide their own workarounds for this
limitation.
[zbin] Fix 64-bit compilation warnings for util/zbin.c
Recent gcc versions generate more warnings when compiling util/zbin.c
on a 64-bit system:
util/zbin.c: In function `read_file':
util/zbin.c:85: warning: format `%d' expects type `int', but
argument 3 has type `size_t'
util/zbin.c:91: warning: format `%d' expects type `int', but
argument 3 has type `size_t'
util/zbin.c: In function `read_zinfo_file':
util/zbin.c:119: warning: format `%d' expects type `int', but
argument 4 has type `size_t'
util/zbin.c: In function `alloc_output_file':
util/zbin.c:134: warning: format `%d' expects type `int', but
argument 3 has type `size_t'
util/zbin.c: In function `process_zinfo_add':
util/zbin.c:244: warning: format `%d' expects type `int', but
argument 3 has type `size_t'
util/zbin.c:266: warning: format `%d' expects type `int', but
argument 7 has type `size_t'
util/zbin.c:286: warning: format `%#x' expects type `unsigned int',
but argument 7 has type `size_t'
util/zbin.c: In function `write_output_file':
util/zbin.c:348: warning: format `%d' expects type `int', but
argument 3 has type `size_t'
This patch eliminates these warnings.
Signed-off-by: Marty Connor <mdc@etherboot.org>
gcc 3.3.3 gave the following error when compiling sis190.c
drivers/net/sis190.c: In function 'sis190_get_mac_addr_from_apc':
drivers/net/sis190.c:966: warning: 'isa_bridge' might be used
uninitialized in this function
make: *** [bin/sis190.o] Error 1
This patch allows error-free compilation.
Signed-off-by: Marty Connor <mdc@etherboot.org>
Recent gcc versions generate warnings when compiling util/zbin.c
( tested with gcc-4.3.3 ):
util/zbin.c: In function ‘process_zinfo_pack’:
util/zbin.c:200: warning: format ‘%#zx’ expects type ‘size_t’, but argument 6
has type ‘long unsigned int’
util/zbin.c: In function ‘process_zinfo_add’:
util/zbin.c:257: warning: format ‘%#lx’ expects type ‘long unsigned int’, but
argument 4 has type ‘int’
util/zbin.c:266: warning: format ‘%#lx’ expects type ‘long unsigned int’, but
argument 4 has type ‘int’
util/zbin.c:266: warning: format ‘%d’ expects type ‘int’, but argument 8 has
type ‘long unsigned int’
util/zbin.c:286: warning: format ‘%#lx’ expects type ‘long unsigned int’, but
argument 6 has type ‘int’
util/zbin.c:286: warning: format ‘%#lx’ expects type ‘long unsigned int’, but
argument 7 has type ‘size_t’
This patch eliminates these warnings.
Tested with gcc-4.3.3 on Ubuntu 9.04 and gcc-4.1.2 on Debian Etch.
Signed-off-by: Marty Connor <mdc@etherboot.org>
[ath5k] Save proper cacheline size when fixing PCI configuration
Some BIOSes set the PCI cacheline size to zero for the card; the ath5k
driver fixes it to a reasonable in PCI config space, but failed to
correct the internal value it had already read. This resulted in
divide-by-zero errors when cacheline-aligning various data structures.
Fix by setting the internal cachelsz to a sane value at the same time
as we write that value to PCI config space.
Signed-off-by: Marty Connor <mdc@etherboot.org>
This adds basic rfkill support for enabling the wireless card on certain
laptops, and changes miscellaneous other details that may help in obscure
cases.
Also change the error handling to not report CRC errors, which due to the
basic facts of wireless may happen even more frequently than valid packets.
Signed-off-by: Marty Connor <mdc@etherboot.org>
Add the 82576 to the e1000 driver.
- Examining the Linux 2.6.30-rc4 igb driver, which supports this card and;
- Information available in the Intel® 82576 Gigabit Ethernet
Controller Datasheet v2.1, which is available from Intel's web site.
I only have a dual-ported card with Copper PHY, so any code paths relating
to Fibre haven't been tested. Also, I have only tested using auto-negotiation
of speed and duplex, and no flow control. Other code paths relating to
those settings also have not been exercised.
Signed-off-by: Simon Horman <horms@verge.net.au>
Sponsored-by: Thomas Miletich <thomas.miletich@gmail.com>
Modified-by: Thomas Miletich <thomas.miletich@gmail.com>
Modified-by: Marty Connor <mdc@etherboot.org>
Signed-off-by: Marty Connor <mdc@etherboot.org>
Enable interrupts in sis900_irq(). Doing so allows some programs using
gPXE's UNDI interface to work properly, including Symantec Ghost.
Tested-by: Hubert Mercier <hubert.mercier@unilim.fr>
Signed-off-by: Marty Connor <mdc@etherboot.org>
The mtools version check does not handle GNU mtools 4.0.10. This commit
makes the pattern more general so it matches older mtools as well as the
newer "mtools (GNU mtools) 4.0.10" string.
Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>
A jump instruction starts at the third byte of an option ROM image, and
it is required that the bytes in the whole image add up to zero. To
achieve this, a checksum byte is usually placed after the jump. The jump
can be either a short jump (2 bytes, EB xx) or a near jump (3 bytes,
E9 xx xx). gPXE's romprefix.S uses a near jump, but modrom.pl assumed
a short jump, and clobbered the high byte of the offset. This caused
modrom-modified gPXE ROM images to crash the system during POST.
Fix by making modrom.pl place the checksum at byte 6, like makerom.pl does.
Signed-off-by: Marty Connor <mdc@etherboot.org>
Thomas Miletich