IBM BIOSes ignore the PnP header offset stored at address 0x1a and
instead scan for the $PnP signature on a 16-byte boundary. (This
alignment is not mandated by the PnP specification.)
Force PnP header to a 16-byte boundary to work around these BIOSes.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Several BIOSes (including most IBM BIOSes and many virtual machine
BIOSes) do not provide detectable PnP support, but will use the BEV
entry point for a PnP option ROM. On these semi-PnP BIOSes, iPXE will
respond to the absence of detectable PnP support by hooking INT19,
which disrupts the boot order.
BIOSes that genuinely require hooking INT19 seem to be very rare
nowadays. It may therefore be preferable to assume that the absence
of detectable PnP support indicates a semi-PnP BIOS rather than a
non-PnP BIOS.
Change the default behaviour so that INT19 will never be hooked unless
the compile-time option NONPNP_HOOK_INT19 is enabled. Leave the
redundant PnP detection routine in-place to allow for debugging via
the ROM banner line.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Revert commit 38cd351 ("[romprefix] Attempt to gracefully handle
semi-PnP IBM BIOSes"), since the test for the "IBM " signature in %edi
is not sufficient to identify an IBM BIOS.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
(Ab)use the "ident" field in transmitted IPv4 packets to convey
metadata about the network device. In particular:
bits 0-3 represent the low bits of the "RX" good packet counter
bits 4-7 represent the low bits of the "RXE" bad packet counter
bits 8-15 represent the transmitted packet sequence number
This allows some relevant information about the internal state of the
network device to be read out from a packet trace from a non-debug
build of iPXE. In particular, it allows a packet trace containing
packets transmitted by iPXE to indicate whether or not any packets
have been received by iPXE.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Booting from an HTTP SAN will require HTTP range requests, which are
defined only in HTTP/1.1 and above. HTTP/1.1 mandates support for
"Transfer-Encoding: chunked", so we must support it.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
This reverts commit 15c1200 ("[hermon] Work around missing mport
support in current BOFM implementations").
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Newer BOFM builds provide support for mapping multiple physical ports
to a single PCI bus:dev.fn via PCI VPD descriptions. These builds
will also leave the {slot,port} field intact, and will populate the
mport field with a meaningful value.
Older BOFM builds will zero out the {slot,port} field. A zero value
in this field may indicate either a genuine zero value (i.e. slot 0
first port) or an older build.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some IBM BIOSes provide partial support for PnP: they will use the BEV
entry point but will not advertise PnP support. This causes iPXE to
hook INT 19, which disrupts the boot process.
Attempt to improve this situation by detecting an IBM BIOS and
treating it as a PnP BIOS despite the absence of a PnP signature.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some versions of binutils have curious concepts of what constitutes
subtraction. For example:
0x00000000000000f0 _text16_late = .
0x0000000000000898 _mtext16 = .
0x0000000000000898 _etext16 = .
0x0000000000000898 _text16_late_filesz = ABSOLUTE ((_mtext16 - _text16_late))
0x00000000000007a8 _text16_late_memsz = ABSOLUTE ((_etext16 - _text16_late))
This has interesting side-effects such as producing sizes for .bss
segments that are negative, causing the majority of addressable memory
to be zeroed out.
Fix by using the form
ABSOLUTE ( x ) - ABSOLUTE ( y )
rather than
ABSOLUTE ( x - y )
Reported-by: H. Peter Anvin <hpa@zytor.com>
Suggested-by: H. Peter Anvin <hpa@zytor.com>
Tested-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
This allows older versions of ELTORITO.SYS (such as the version found
on the FreeDOS installation CD-ROM) to use iPXE's emulated CD-ROM
drive.
Reported-by: Robin Smidsrød <robin@smidsrod.no>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Make the build command line less cumbersome by accepting
make DEBUG=int13 EMBED=test.ipxe
rather then
make DEBUG=int13 EMBEDDED_IMAGE=test.ipxe
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Expose the multiple-SAN-drive capability of the iPXE core via the iPXE
command line by adding commands to hook and unhook additional drives.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some PXE stacks (notably old Etherboot/gPXE stacks) will claim to use
the timer interrupt, rather than reporting that interrupts are not
supported. Since using the timer interrupt is equivalent to polling
anyway, we may as well genuinely poll these stacks.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
PCI_ROM() and ISA_ROM() macros occur only within driver files.
Running parserom.pl on non-driver files is therefore redundant.
Skip running parserom.pl on any files outside a "drivers" directory.
This reduces the time taken to generate build rules and dependencies
after a "make veryclean" by around 12%.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
There is no plausible scenario I can think of in which "isset" would
be used with more than one argument. Simplify the code by specifying
that exactly one argument is required.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Current BOFM versions are unable to create entries with mport>1, which
means that only the port 1 MAC address can be explicitly specified.
Work around this by using the provided MAC address as a base address
for all subsequent ports. For example, if BOFM assigns the address
00:1A:64:76:00:09 for port 1
then we will assign the addresses
00:1A:64:76:00:09 for port 1
00:1A:64:76:00:0a for port 2
Future BOFM versions that may correctly support mport will work with
this scheme without modification provided that the BOFM entries are
created in increasing order of mport. Since BOFM tools tend to
generate entries in increasing order (of slot, port, etc), this is not
an unreasonable compromise.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
GNU gold (part of newer binutils builds) does not appear to be
designed to support generic linker functionality, since its source
code contains several Linux-specific hard-coded assumptions about the
layout of ELF binaries. Attempting to build iPXE using GNU gold will
generally cause some kind of "linker internal error".
Provide an explicit error message suggesting the use of GNU ld
instead.
Reported-by: Chris Hills <chaz@chaz6.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Commit 3f442d3 ("[tcp] Record ts_recent on first received packet")
failed to achieve its stated intention.
Fix this (and reduce the code size) by moving the ts_recent update to
tcp_rx_seq(). This is the code responsible for advancing the window,
called by both tcp_rx_syn() and tcp_rx_data(), and so the window check
is now redundant.
Reported-by: Frank Weed <zorbustheknight@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Commit b5f5f73 ("[cmdline] Expand settings within each command-line
token individually") introduced a regression into the "isset" command:
it is now possible for command-line arguments to be empty strings, and
so "isset" cannot simply check for a non-empty argument list.
Restore previous behaviour by checking for the presence of any
non-empty arguments, rather than checking for a non-empty argument
list.
Reported-by: Nemtallah Daher <n.daher@csuohio.edu>
Tested-by: Nemtallah Daher <n.daher@csuohio.edu>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Set the current working URI to NULL rather than to "tftp://0.0.0.0/".
Reported-by: Piotr Jaroszyński <p.jaroszynski@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Standardise on using init_editstring() to initialise an embedded
editable string, to match the coding style used by other embedded
objects.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
A PCI_ROM() entry containing a vendor or device ID of PCI_ANY_ID
(0xffff) indicates to pci_find_driver() that the entry's vendor or
device ID should be ignored when matching against the device's vendor
or device ID. It does not represent a PCI ROM that should be built.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Each PCI ROM currently ends up appearing twice in the $(ROMS) list:
once under its designated name (e.g. "rtl8139.rom"), once under its
PCI IDs (e.g. "bin/10ec8139.rom").
Include only the latter of these in the $(ROMS) list, so that doing
"make allroms" will generate only one copy of each ROM.
Reported-by: Bastian Blank <waldi@debian.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
For devices that start in a link-down state, the user will see a
message such as:
[Link status: The socket is not connected (http://ipxe.org/38086001)]
Waiting for link-up on net0...
This is potentially misleading, since it suggests that there is a
genuine problem. Add a dedicated error message for "link down",
giving instead:
[Link status: Down (http://ipxe.org/38086101)]
Waiting for link-up on net0...
Reported-by: Tal Aloni <tal.aloni.il@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The original EFI BOFM protocol has a design flaw that limits the size
of the table to 1kB, since the table is embedded within the
IBM_BOFM_DRIVER_CONFIGURATION_PROTOCOL structure. Version 2 of the
protocol works around this problem.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
iPXE operates the forcedeth NIC in promiscuous mode, and never changes
the unicast MAC address filter registers. We should not therefore set
the flag indicating (to other drivers loaded later) that the MAC
address order has already been corrected.
Reported-by: Tal Aloni <tal.aloni.il@gmail.com>
Tested-by: Tal Aloni <tal.aloni.il@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The forcedeth driver currently implements unicast MAC address
filtering in software. This is almost invariably the wrong thing to
do (since the network stack must already be able to cope with unwanted
packets) and it breaks FCoE (which requires the card to operate in
promiscuous mode).
Also, the implementation is buggy: is_local_ether_addr() is used to
check for a locally-assigned Ethernet address (not to check for a
unicast address), and the current link-layer address is in
netdev->ll_addr, not netdev->hw_addr.
Fix by removing this code.
Reported-by: Tal Aloni <tal.aloni.il@gmail.com>
Tested-by: Tal Aloni <tal.aloni.il@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
A scriptlet is a single iPXE command that can be stored in
non-volatile option storage and used to override the default
"autoboot" behaviour without having to reflash the iPXE image.
For example, a scriptlet could contain
autoboot || reboot
to instruct iPXE to reboot the system if booting fails.
Unlike an embedded image, the presence of a scriptlet does not inhibit
the initial "Press Ctrl-B..." prompt. This allows the user to recover
from setting a faulty scriptlet.
Originally-implemented-by: Glenn Brown <glenn@myri.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Perform settings expansion after tokenisation, and only at the point
of executing each command. This allows statements such as
dhcp && echo ${net0/ip}
to work correctly.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
It is currently possible to construct a sequence of commands to be
executed regardless of success or failure using "|| &&" as the command
separator. (The "||" captures the failure case, the blank command
converts it to a success case.)
Allow ";" to be used as a more visually appealing (and
space-efficient) alternative.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Temporary modification to prevent valgrind.h from breaking compilation
with gcc 4.6. When this problem is fixed upstream, a new and
unmodified copy of valgrind.h should be imported.
Signed-off-by: Thomas Miletich <thomas.miletich@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Avoid unused-but-set variable warning in gcc 4.6 which was introduced
by commit 9215b7f ("[forcedeth] Clear the MII link status register on
link status changes").
Signed-off-by: Thomas Miletich <thomas.miletich@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
An iPXE .exe image can be loaded from DOS. Tested using bin/ipxe.exe
to load a Linux kernel and simple initramfs from within MS-DOS 6.22.
(EDD must be disabled using the "edd=off" kernel parameter, since the
loaded kernel image has already overwritten parts of DOS' INT 13
wrapper.)
Signed-off-by: Michael Brown <mcb30@ipxe.org>
In the unlikely (but observable) event that INT 15,88 returns less
memory above 1MB than is required for the temporary decompression
area, ignore it and use the 1MB point anyway.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Make the allocators used by malloc and linux_umalloc valgrindable.
Include valgrind headers in the codebase to avoid a build dependency
on valgrind.
Signed-off-by: Piotr Jaroszyński <p.jaroszynski@gmail.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
There is no need to explicitly call basename() to construct an image
name in imgfetch_core_exec(), since image_set_uri() will do so
automatically anyway (and will do so without getting confused by URIs
with query strings).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
netdev_close() assumes that devices that are open are on the
open_list, which wasn't true if device specific opening failed.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The "read" command allows a script to prompt a user to enter a
setting. For example:
echo -n Static IP address:
read net0/ip
Total cost: 17 bytes.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Commit 6861304 ("[tcp] Handle out-of-order received packets")
introduced a regression in which ts_recent would not be updated until
the first packet is received in the ESTABLISHED state, i.e. the
timestamp from the SYN+ACK packet would be ignored. This causes the
connection to be dropped by strictly-conforming TCP peers, such as
FreeBSD.
Fix by delaying the timestamp window check until after processing the
received SYN flag.
Reported-by: winders@sonnet.com
Signed-off-by: Michael Brown <mcb30@ipxe.org>
bin/ipxe.lkrn is built anyway in order to create bin/ipxe.iso, so
there is no additional cost to including it within the default build.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Normalise the progress figures to ensure that multiplication by 100
(to produce a percentage) cannot result in integer overflow.
Reported-by: Sven Dreyer <sven@dreyer-net.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
iPXE documentation tends to refer to "settings" rather than "options",
since settings can be more general than DHCP options.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some PXE stacks advertise that interrupts are not supported, despite
requiring the use of interrupts. Attempt to cope with such cards
without breaking others by always hooking the interrupt, and using the
"interrupts supported" flag only to decide whether or not to wait for
an interrupt before calling PXENV_UNDI_ISR_IN_PROCESS.
The possible combinations are therefore:
1. Card generates interrupts and claims to support interrupts
iPXE will call PXENV_UNDI_ISR_IN_PROCESS only after an interrupt
has been observed. (This is required to avoid lockups in some PXE
stacks, which spuriously sulk if called before an interrupt has
been generated.)
Such a card should work correctly.
2. Card does not generate interrupts and does not claim to support
interrupts
iPXE will call PXENV_UNDI_ISR_IN_PROCESS indiscriminately, matching
the observed behaviour of at least one other PXE NBP (winBoot/i).
Such a card should work correctly.
3. Card generates interrupts but claims not to support interrupts
iPXE will call PXENV_UNDI_ISR_IN_PROCESS indiscriminately. An
interrupt will still result in a call to PXENV_UNDI_ISR_IN_START.
Such a card may work correctly.
4. Card does not generate interrupts but claims to support interrupts
Such a card will not work at all.
Reported-by: Jerry Cheng <jaspers.cheng@msa.hinet.net>
Tested-by: Jerry Cheng <jaspers.cheng@msa.hinet.net>
Reported-by: Mauricio Silveira <mauricio@livreti.com.br>
Tested-by: Mauricio Silveira <mauricio@livreti.com.br>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Improve the appearance of the "config" user interface by ensuring that
settings appear in some kind of logical order.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Commit 5fbd020 ("[settings] Display canonical setting name in output
of "show" command") introduced a regression causing all setting
expansions (e.g. "${net0/mac}") to expand to an empty string.
Fix by returning the formatted value length from
fetchf_named_setting(), as expected by the caller.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow the user to browse through the settings block hierarchy.
Originally-implemented-by: Glenn Brown <glenn@myri.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Display only settings relevant to the current scope. For example,
"config net0" no longer displays SMBIOS settings, and "config smbios"
displays only SMBIOS settings.
Originally-implemented-by: Glenn Brown <glenn@myri.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Enable the "show" command to display the full, canonicalised name of
the fetched setting. For example:
iPXE> show mac
net0/mac:hex = 52:54:00:12:34:56
iPXE> dhcp && show ip
DHCP (net0 52:54:00:12:34:56)... ok
net0.dhcp/ip:ipv4 = 10.0.0.168
iPXE> show net0/6
net0.dhcp/dns:ipv4 = 10.0.0.6
Inspired-by: Glenn Brown <glenn@myri.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Expose settings_name(), shrink the unnecessarily large static buffer,
properly name root settings block, and simplify.
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Expose a function setting_applies() to allow a caller to determine
whether or not a particular setting is applicable to a particular
settings block.
Restrict DHCP-backed settings blocks to accepting only DHCP-based
settings.
Restrict network device settings blocks to accepting only DHCP-based
settings and network device-specific settings such as "mac".
Inspired-by: Glenn Brown <glenn@myri.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The "us" keyboard layout contains a mapping for keycode 86 (which
seems not to correspond to any physical key on many US keyboards) to
the ASCII character '<'. This mapping causes conflicts with the
mapping for keycode 51, which also maps (with shift) to '<'.
Change the keyboard mapping generator to choose the lowest keycode for
each ASCII character as indicating the relevant mapping to use, on the
basis that a lower keycode roughly indicates a "more normal" key. On
a German keyboard, which has keys for both keycode 51 and keycode 86
present, this causes '<' to be remapped to ';', which is a closer
match to typical user expectations.
Reported-by: Sven Dreyer <sven@dreyer-net.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown
Greg Jednaszewski
Bastian Blank
Gilles Espinasse
Thomas Miletich
Piotr Jaroszyński
Glenn Brown
Yann Cézard