Support qemu-like arguments for network setup:
--net driver_name[,setting=value]*
and global settings:
--settings setting=value[,setting=value]*
Signed-off-by: Piotr Jaroszyński <p.jaroszynski@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add makefiles, ld scripts and default config for linux platform for
both i386 and x86_64.
Signed-off-by: Piotr Jaroszyński <p.jaroszynski@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
pcbios specific get_memmap() is used by the b44 driver making
all-drivers builds fail on other platforms. Move it to the I/O API
group and provide a dummy implementation on EFI.
Signed-off-by: Piotr Jaroszyński <p.jaroszynski@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
COM32 binaries generally expect to run with interrupts
enabled. Syslinux does so, and COM32 programs will execute cli/sti
pairs when running a critical section, to provide mutual exclusion
against BIOS interrupt handlers. Previously, under iPXE, the IDT was
not valid, so any interrupt (e.g. a timer tick) would generally cause
the machine to triple fault.
This change introduces code to:
- Create a valid IDT at the same location that syslinux uses
- Create an "interrupt jump buffer", which contains small pieces of
code that simply record the vector number and jump to a common
handler
- Thunk down to real mode and execute the BIOS's interrupt handler
whenever an interrupt is received in a COM32 program
- Switch IDTs and enable/disable interrupts when context switching to
and from COM32 binaries
Testing done:
- Booted VMware ESX using a COM32 multiboot loader (mboot.c32)
- Built with GDBSERIAL enabled, and tested breakpoints on int22 and
com32_irq
- Put the following code in a COM32 program:
asm volatile ( "sti" );
while ( 1 );
Before this change, the machine would triple fault
immediately. After this change, it hangs as expected. Under Bochs,
it is possible to see the interrupt handler run, and the current
time in the BIOS data area gets incremented.
Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
An assembly version of memswap() is in an x86 word-length-agnostic
header file, but it used 32-bit registers to store pointers, leading
to memory errors responding to ARP queries on 64-bit systems.
Signed-off-by: Joshua Oreman <oremanj@rwcr.net>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The existence and usage of the BEV entry point is covered by the PnP
spec, not the BBS spec; the BBS spec merely describes a policy for
selecting the boot device order. iPXE should therefore check only for
a PnP BIOS in order to decide whether or not to hook INT19.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Commit ea12dc0 ("[build] Avoid hard-coding the path to perl")
introduced a build failure for fully clean trees (e.g. after running
"make veryclean"), since the dependency upon $(PARSEROM) now includes
a dependency upon "perl" (which doesn't exist) rather than upon
"/usr/bin/perl" (which does exist).
There should of course be no dependency upon the perl binary at all;
the dependency should be upon "./util/parserom.pl" alone.
Fix by removing the $(PERL) from the definition of Perl-based utility
paths, and adding $(PERL) at the point of usage.
Reported-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Remove data-xfer as an interface type, and replace data-xfer
interfaces with generic interfaces supporting the data-xfer methods.
Filter interfaces (as used by the TLS layer) are handled using the
generic pass-through interface capability. A side-effect of this is
that deliver_raw() no longer exists as a data-xfer method. (In
practice this doesn't lose any efficiency, since there are no
instances within the current codebase where xfer_deliver_raw() is used
to pass data to an interface supporting the deliver_raw() method.)
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Remove name-resolution as an interface type, and replace
name-resolution interfaces with generic interfaces supporting the
resolv_done() method.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
strerror() has not been able to use the PXE-only error table since
commit 9aa61ad ("Add per-file error identifiers") back in 2007.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Most of iPXE uses __attribute__((packed)) anyway, and PACKED conflicts
with an identically-named macro in the upstream EFI header files.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
See RFC 4578 for details.
Signed-off-by: Joshua Oreman <oremanj@rwcr.net>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The linker chooses to look for _start first and always picks
efidrvprefix.o to satisfy it (probably because it's earlier in the
archive) which causes a multiple definition error when the linker
later has to pick efiprefix.o for other symbols.
Fix by using EFI-specific TGT_LD_FLAGS with an explicit entry point.
Signed-off-by: Piotr Jaroszyński <p.jaroszynski@gmail.com>
Signed-off-by: Joshua Oreman <oremanj@rwcr.net>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
This removes the need for inline safety wrappers, marginally reducing
the size penalty of weak functions, and works around an apparent
binutils bug that causes undefined weak symbols to not actually be
NULL when compiling with -fPIE (as EFI builds do).
A bug in versions of binutils prior to 2.16 (released in 2005) will
cause same-file weak definitions to not work with those
toolchains. Update the README to reflect our new dependency on
binutils >= 2.16.
Signed-off-by: Joshua Oreman <oremanj@rwcr.net>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
COMBOOT API calls set the carry flag on failure. This was not being
propagated because the COMBOOT interrupt handler used iret to return
with EFLAGS restored from the stack. This patch propagates CF before
returning from the interrupt.
Reported-by: Geoff Lywood <glywood@vmware.com>
Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Microsoft WDS can end up calling PXENV_RESTART_TFTP to execute a
second-stage NBP which then exits. Specifically, wdsnbp.com uses
PXENV_RESTART_TFTP to execute pxeboot.com, which will exit if the user
does not press F12. iPXE currently treats PXENV_RESTART_TFTP as a
normal PXE API call, and so attempts to return to wdsnbp.com, which
has just been vaporised by pxeboot.com.
Use rmsetjmp/rmlongjmp to preserve the stack state as of the initial
NBP execution, and to restore this state immediately prior to
executing the NBP loaded via PXENV_RESTART_TFTP. This matches the
behaviour in the PXE spec (which says that "if TFTP is restarted,
control is never returned to the caller"), and allows pxeboot.com to
exit relatively cleanly back to iPXE.
As with all usage of setjmp/longjmp, there may be subtle corner case
bugs due to not gracefully unwinding any state accumulated by the time
of the longjmp call, but this seems to be the only viable way to
provide the specified behaviour.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add an infrastructure allowing the prefix to provide an open_payload()
method for obtaining out-of-band access to the whole iPXE image. Add
a mechanism within this infrastructure that allows raw access to the
expansion ROM BAR by temporarily borrowing an address from a suitable
memory BAR on the same PCI card.
For cards that have a memory BAR that is at least as large as their
expansion ROM BAR, this allows large iPXE ROMs to be supported even on
systems where PMM fails, or where option ROM space pressure makes it
impossible to use PMM shrinking. The BIOS sees only a stub ROM of
approximately 3kB in size; the remainder (which can be well over 64kB)
is loaded only at the time iPXE is invoked.
As a nice side-effect, an iPXE .mrom image will continue to work even
if its PMM-allocated areas are overwritten between initialisation and
invocation.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The only remaining useful function of makerom.pl is to correct the ROM
and PnP checksums; the PCI IDs are set at link time, and padding is
performed using padimg.pl.
Option::ROM already provides a facility for correcting the checksums,
so we may as well just use this instead.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
It is common for system memory maps to be grotesquely unreliable
during POST. Many sanity checks have been added to the memory map
reading code, but these do not catch all problems.
Skip relocation entirely if called during POST. This should avoid the
problems typically encountered, at the cost of slightly disrupting the
memory map of an operating system booted via iPXE when iPXE was
entered during POST. Since this is a very rare special case (used,
for example, when reflashing an experimental ROM that would otherwise
prevent the system from completing POST), this is an acceptable cost.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some BIOSes (at least some AMI BIOSes) tend to refuse to allocate a
single area large enough to hold both the iPXE image source and the
temporary decompression area, despite promising a largest available
PMM memory block of several megabytes. This causes ROM image
shrinking to fail on these BIOSes, with undesirable consequences:
other option ROMs may be disabled due to shortage of option ROM space,
and the iPXE ROM may itself be corrupted by a further BIOS bug (again,
observed on an AMI BIOS) which causes large ROMs to end up overlapping
reserved areas of memory. This can potentially render a system
unbootable via any means.
Increase the chances of a successful PMM allocation by dropping the
alignment requirement (which is redundant now that we can enable A20
from within the prefix); this allows us to reduce the allocation size
from 2MB down to only the required size.
Increase the chances still further by using two separate allocations:
one to hold the image source (i.e. the copy of the ROM before being
shrunk) and the other to act as the decompression area. This allows
ROM image shrinking to take place even on systems that fail to
allocate enough memory for the temporary decompression area.
Improve the behaviour of iPXE in systems with multiple iPXE ROMs by
sharing PMM allocations where possible. Image source areas can be
shared with any iPXE ROMs with a matching build identifier, and the
temporary decompression area can be shared with any iPXE ROMs with the
same uncompressed size (rounded up to the nearest 128kB).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Use INT 15,88 to find a suitable temporary decompression area, rather
than a fixed address. This hopefully gives us a better chance of not
treading on any PMM-allocated areas, in BIOSes where PMM support
exists but tends not to give us the large blocks that we ask for.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Always call INT 15,88 even if we don't use the result. This allows
DEBUG=memmap to show the complete result set returned by all of the
INT 15 memory-map calls.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Randomly generate a 32-bit build identifier that can be used to
identify identical iPXE ROMs when multiple such ROMs are present in a
system (e.g. when a multi-function NIC exposes the same iPXE ROM image
via each function's expansion ROM BAR).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The existing "iPXE starting execution" message indicates that the BEV
(or INT19) was invoked, but gives no indication on whether or not the
iPXE source was successfully retrieved (e.g. from PMM). Split the
"starting execution message" into "starting execution...ok"; the "ok"
indicates that the main iPXE body was successfully decompressed and
relocated.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Now that we can use odd megabytes, there is no particular need to use
an even megabyte as the fallback temporary load point.
Note that the old warnings about avoiding 2MB pre-date our ability to
cooperate with other PXE ROMs by using PMM.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
iPXE is now capable of operating in odd megabytes of memory, so remove
the obsolete code enforcing an even-megabyte constraint.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Use the shared code in libflat to perform the A20 transitions
automatically on each transition from real to protected mode. This
allows us to remove all explicit calls to gateA20_set().
The old warnings about avoiding automatically enabling A20 are
essentially redundant; they date back to the time when we would always
start hammering the keyboard controller without first checking to see
if gate A20 was already enabled (which it almost always is).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
iPXE currently insists on residing in an even megabyte. This imposes
undesirably severe constraints upon our PMM allocation strategy, and
limits our options for mechanisms to access ROMs greater than 64kB in
size.
Add A20 handling code to libflat so that prefixes are able to access
memory even in odd megabytes.
The algorithms and tuning parameters in the new A20 handling code are
based upon a mixture of the existing iPXE A20 code and the A20 code
from the 2.6.32 Linux kernel.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The flatten_real_mode routine is not needed until after decompressing
.text16.early, and currently performs various contortions to
compensate for the fact that .prefix may not be writable. Move
flatten_real_mode to .text16.early to save on (compressed) binary size
and simplify the code.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add a section .text16.early which is always kept inline with the
prefix. This will allow for some code sharing between the .prefix and
.text16 sections.
Note that the simple solution of just prepending the .prefix section
to the .text16 section will not work, because a bug in Wyse Streaming
Manager server (WLDRM13.BIN) requires us to place a dummy PXENV+ entry
point at the start of .text16.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Use flat real mode rather than 16-bit protected mode for access to
high memory during installation. This simplifies the code by reducing
the number of CPU modes we need to think about, and also increases the
amount of code in common between the normal and (somewhat
hypothetical) KEEP_IT_REAL methods of operation.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
When returning to real mode, set 4GB segment limits instead of 64kB
limits. This change improves our chances of successfully returning to
a PMM-capable BIOS aftering entering iPXE during POST; the BIOS will
have set up flat real mode before calling our initialisation point,
and may be disconcerted if we then return in genuine real mode.
This change is unlikely to break anything, since any code that might
potentially access beyond 64kB must use addr32 prefixes to do so; if
this is the case then it is almost certainly code written to expect
flat real mode anyway.
Note that it is not possible to restore the real-mode segment limits
to their original values, since it is not possible to know which
protected-mode segment descriptor was originally used to initialise
the limit portion of the segment register.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The .hrom prefix provides an experimental mechanism for reducing
option ROM space usage on systems where PMM allocation fails, by
pretending that PMM allocation succeeded and gave us an address fixed
at compilation time. This is unreliable, and potentially dangerous.
In particular, when multiple gPXE ROMs are present in a system, each
gPXE ROM will assume ownership of the same fixed address, resulting in
undefined behaviour.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The .xrom prefix provides an experimental mechanism for loading ROM
images greater than 64kB in size by mapping the expansion ROM BAR in
at a hopefully-unused address. This is unreliable, and potentially
dangerous. In particular, there is no guarantee that any PCI bridges
between the CPU and the device will respond to accesses for the
"unused" memory region that is chosen, and it is possible that the
process of scanning for the "unused" memory region may end up issuing
reads to other PCI devices. If this ends up trampling on a register
with read side-effects belonging to an unrelated PCI device, this may
cause undefined behaviour.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Access to the gpxe.org and etherboot.org domains and associated
resources has been revoked by the registrant of the domain. Work
around this problem by renaming project from gPXE to iPXE, and
updating URLs to match.
Also update README, LOG and COPYRIGHTS to remove obsolete information.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
gPXE currently overwrites the filename stored in the cached DHCP
packets when a call to PXENV_TFTP_READ_FILE or PXENV_RESTART_TFTP is
made. This code has existed for many years as a workaround for RIS,
which seemed to require that this be done.
pxe_set_cached_filename() causes problems with the Bootix NBP, and a
recent test demonstrates that RIS will complete successfully even with
pxe_set_cached_filename() removed. There have been many changes to
the DHCP and PXE logic since this code was first added, and it is
quite plausible that it was masking a bug that no longer exists.
Reported-by: Alex Zeffertt <alex.zeffertt@eu.citrix.com>
Debugged-by: Shao Miller <Shao.Miller@yrdsb.edu.on.ca>
Signed-off-by: Michael Brown <mcb30@etherboot.org>
Current gPXE code always returns "OURS" in response to
PXENV_UNDI_ISR:START. This is harmless for non-shared interrupt
lines, and avoids the complexity of trying to determine whether or not
we really did cause the interrupt. (This is a non-trivial
determination; some drivers don't have interrupt support and hook the
system timer interrupt instead, for example.)
A problem occurs when we have a shared interrupt line, the other
device asserts an interrupt, and the controlling ISR does not chain to
the other device's ISR when we return "OURS". Under these
circumstances, the other device's ISR never executes, and so the
interrupt remains asserted, causing an interrupt storm.
Work around this by returning "OURS" if and only if our net device's
interrupt is currently recorded as being enabled. Since we always
disable interrupts as a result of a call to PXENV_UNDI_ISR:START, this
guarantees that we will eventually (on the second call) return "NOT
OURS", allowing the other ISR to be called. Under normal operation,
including a non-shared interrupt situation, this change will make no
difference since PXENV_UNDI_ISR:START would be called only when
interrupts were enabled anyway.
Signed-off-by: Michael Brown <mcb30@etherboot.org>
