This function never did much in this driver anyway, and after commit
b5ed30b2 ("[tg3] Fix compilation on newer gcc versions") it became
apparent that its remaining functionality could be easily moved to
tg3_test_dma().
Signed-off-by: Thomas Miletich <thomas.miletich@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[prefix] Delay initrd image copy until memory map is ready
initrd_init() calls umalloc() to allocate space for the initrd image,
but does so before hide_etherboot() has been called. It is therefore
possible for the initrd to end up overwriting iPXE itself.
Fix by converting initrd_init() from an init_fn to a startup_fn.
Originally-fixed-by: Till Straumann <strauman@slac.stanford.edu>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Replace the old Etherboot tg3 driver with a more up-to-date driver
using the iPXE API.
Signed-off-by: Thomas Miletich <thomas.miletich@gmail.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
ANS X9.82 specifies that an Approved DRBG must consist of an Approved
algorithm wrapped inside an envelope which handles entropy gathering,
prediction resistance, automatic reseeding and other housekeeping
tasks.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Cryptographic random number generation requires an entropy source,
which is used as the input to a Deterministic Random Bit Generator
(DRBG).
iPXE does not currently have a suitable entropy source. Provide a
dummy source to allow the DRBG code to be implemented.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
NIST provides a set of known-answer tests for the HMAC_DRBG algorithm,
which can be used as part of the conformance testing for ANS X9.82.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
ANS X9.82 specifies several Approved algorithms for use in a
Deterministic Random Bit Generator (DRBG). One such algorithm is
HMAC_DRBG, which can be implemented using the existing iPXE SHA-1 and
HMAC functionality. This algorithm provides a maximum security
strength of 128 bits.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[lkrnprefix] Copy command line before installing iPXE
The command line may be situated in an area of base memory that will
be overwritten by iPXE's real-mode segments, causing the command line
to be corrupted before it can be used.
Fix by creating a copy of the command line on the prefix stack (below
0x7c00) before installing the real-mode segments.
Reported-by: Dave Hansen <dave@sr71.net>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[pxe] Provide PXENV_FILE_EXIT_HOOK only for ipxelinux.0 builds
PXENV_FILE_EXIT_HOOK is designed to allow ipxelinux.0 to unload both
the iPXE and pxelinux components without affecting the underlying PXE
stack. Unfortunately, it causes unexpected behaviour in other
situations, such as when loading a non-embedded pxelinux.0 via
undionly.kpxe. For example:
PXE ROM -> undionly.kpxe -> pxelinux.0 -> chain.c32 to boot hd0
would cause control to return to iPXE instead of booting from the hard
disk. In some cases, this would result in a harmless but confusing
"No more network devices" message; in other cases stranger things
would happen, such as being returned to the iPXE shell prompt.
The fundamental problem is that when pxelinux detects
PXENV_FILE_EXIT_HOOK, it may attempt to specify an exit hook and then
exit back to iPXE, assuming that iPXE will in turn exit cleanly via
the specified exit hook. This is not a valid assumption in the
general case, since the action of exiting back to iPXE does not
directly cause iPXE to exit itself. (In the specific case of
ipxelinux.0, this will work since the embedded script exits as soon as
pxelinux.0 exits.)
Fix the unexpected behaviour in the non-ipxelinux.0 cases by including
support for PXENV_FILE_EXIT_HOOK only when using a new .kkkpxe format.
The ipxelinux.0 build process should therefore now use undionly.kkkpxe
instead of undionly.kkpxe.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[pxe] Check for a valid PXE network device when applicable
Very nasty things can happen if a NULL network device is used. Check
that pxe_netdev is non-NULL at the applicable entry points, so that
this type of problem gets reported to the caller rather than being
allowed to crash the system.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
It can sometimes be awkward to prevent additional packets from being
received during a loopback test. Allow such additional packets to be
present without terminating the test.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
On at least one PXE stack (Realtek r8169), PXENV_UNDI_INITIALIZE has
been observed to fail intermittently due to a media test failure (PXE
error 0x00000061). Retrying the call to PXENV_UNDI_INITIALIZE
succeeds, and the NIC is then usable.
It is worth noting that this particular Realtek PXE stack is already
known to be unreliable: for example, it repeatably fails its own
boot-time media test after every warm reboot.
Fix by attempting PXENV_UNDI_INITIALIZE multiple times, with a short
delay between each attempt to allow the link to settle.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[dhcp] Add PXE-mandated DHCP options [128,135] to parameter request list
The PXE specification requires us to request DHCP options 128 to 135
inclusive, although these have no defined purpose.
Suggested-by: Ralf Buettner <rab@bootix.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The RS bit is used to instruct the NIC to update the TX descriptor
status byte. The RPS bit is used to instruct the NIC to defer this
update until after the packet has been transmitted on the wire (rather
than merely read into the transmit FIFO).
The driver currently sets RPS but not RS. Some e1000 models seem to
interpret this as implying that the status byte should be updated;
some don't. On the ones that don't, we never see any TX completions
and so rapidly run out of TX buffers.
Fix by setting the RS bit in the TX descriptor. (We don't care about
when the packet reaches the wire, so don't bother setting the RPS
bit.)
Reported-by: Miroslav Halas <miroslav.halas@bankofamerica.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[iscsi] Fail immediately if target rejects any of our parameters
Some iSCSI targets (observed with stgt) can be configured to reject
connections that do not use header or data digests, and will respond
with "HeaderDigest=Reject" and/or "DataDigest=Reject", while still
allowing the connection to proceed to the full feature phase.
According to a strict reading of RFC3720, we are perfectly safe to
ignore these "Reject" messages: upon such a rejection "the negotiated
key is left at its current value (or default if no value was set)".
Since the default value for both HeaderDigest and DataDigest is
"None", then the only viable conclusion to be drawn is that the value
resulting from "Reject" is still "None".
Unfortunately, stgt doesn't seem to agree with this interpretation of
events, causing us to eventually report an unhelpful "connection timed
out" message to the user when we don't get any response to our first
PDU in full feature phase.
Fix by detecting any rejected parameters and immediately reporting an
error, which at least gives the user some insight as to what the real
problem may be.
Reported-by: Michal Suchanek <hramrach@centrum.cz>
Tested-by: Michal Suchanek <hramrach@centrum.cz>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Include UNDI PCI driver within all-drivers build
Commit 9b99d2a ("[build] Avoid generating ROMs with "match-any" vendor
or device IDs") introduced a regression which caused the UNDI PCI
driver to be omitted from the list of all drivers, and thus to be
excluded from the all-drivers build.
Fix by ensuring that the per-driver section of the Makefile is
generated even when there are no ROMs to be built.
Reported-by: Sven Dreyer <sven@dreyer-net.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[hermon] Ensure hardware is quiescent when no interfaces are open
WinPE has been observed to call PXENV_UNDI_SHUTDOWN but not
PXENV_STOP_UNDI. This means that Hermon hardware is left partially
active (firmware running and one event queue mapped) when WinPE starts
up, which can cause a Blue Screen of Death.
Fix by ensuring that the hardware is left quiescent (with the firmware
stopped) when no interfaces are open.
Reported-by: Itay Gazit <itayg@mellanox.co.il>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[ipoib] Report packets as broadcast when ambiguous
Avoid spurious matches for peer key 0 against empty peer cache
entries, and set the LL_MULTICAST flag in addition to LL_BROADCAST.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[rtl8139] Perform only 8-bit ioport access on the ChipCmd register
The ChipCmd register is only an 8-bit register. The 16-bit access
used by iPXE was causing an issue when used with qemu emulated rtl8139
device which was improperly aligning IOs.
Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow an initrd (such as an embedded script) to be passed to iPXE when
loaded as a .lkrn (or .iso) image. This allows an embedded script to
be varied without recompiling iPXE.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Specify a driver name of "undionly" and a device name based on the
UNDI-reported underlying hardware device. For example:
net0: 52:54:00:12:34:56 using undionly on UNDI-PCI00:03.0 (open)
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[netdevice] Allow driver to preinitialise the link-layer address
Drivers are currently expected to initialise only the hardware
address, with the link-layer protocol code taking care of converting
this into a valid link-layer address. Some drivers (e.g. undinet) can
legitimately determine both the hardware and link-layer addresses,
which may differ.
Allow for this situation by checking to see if the link-layer address
is empty before initialising it from the hardware address.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[librm] Avoid (harmless) collisions with linker symbols
The symbol_text16 is defined globally by the linker. Use rm_text16
instead of _text16 for the local variable within librm.S to avoid
confusion when reading linker maps.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[image] Eliminate the register_and_xxx_image() functions
All users of imgdownload() require registration of the image, so make
registration an integral part of imgdownload() itself and simplify the
"action" parameter to be one of image_select(), image_exec() et al.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Paul Sands