The .mrom payload has a code type of 0xff and so the initialisation
length field (single byte at offset 0x02) does not need to be
present.  Use only the PCI header's image length field, which allows
the .mrom payload to be up to 32MB in size.

Inspired-by: Swift Geek <swiftgeek@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

mromprefix.S currently uses the initialisation length field (single
byte at offset 0x02) to determine the length of a ROM image within a
multi-image ROM BAR.  For PCI ROM images with a code type other than
0, the initialisation length field may not be present.

Fix by using the PCI header's image length field instead.

Inspired-by: Swift Geek <swiftgeek@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

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

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

The build process has for a long time assumed that every ROM is a PCI
ROM, and will always include the PCI header and PCI-related
functionality (such as checking the PCI BIOS version, including the
PCI bus:dev.fn address within the ROM product name string, etc.).

While real ISA cards are no longer in use, some virtualisation
environments (notably VirtualBox) have support only for ISA ROMs.
This can cause problems: in particular, VirtualBox will call our
initialisation entry point with random garbage in %ax, which we then
treat as the PCI bus:dev.fn address of the autoboot device: this
generally prevents the default boot sequence from using any network
devices.

Create .isarom and .pcirom prefixes which can be used to explicitly
specify the type of ROM to be created.  (Note that the .mrom prefix
always implies a PCI ROM, since the .mrom mechanism relies on
reconfiguring PCI BARs.)

Make .rom a magic prefix which will automatically select the
appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or
ISA_ROM() macro.  To maintain backwards compatibility, we default to
building a PCI ROM for anything which is not directly derived from a
PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom).

Add a selection of targets to "make everything" to ensure that the
(relatively obscure) ISA ROM build process is included within the
per-commit QA checks.

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

Since some PnP BIOSes fail to set %es:di to point to the PnP signature
on entry, we identify a PnP BIOS by scanning through the top 64kB of
base memory looking for the PnP structure.  We therefore don't
actually use the values of %es:di provided to the initialisation entry
point, and so there is no need to preserve them.

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

The bzImage boot protocol allows the real-mode code to be loaded at
any segment within base memory.  (The fact that both iPXE and recent
versions of Syslinux will load the real-mode code at 1000:0000 is a
coincidence; it is not guaranteed by the specification.)

Fix by making the code relocatable.

Reported-by: Andrew Stuart <andrew@shopcusa.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

The .lkrn prefix currently provides a zImage kernel with unused setup
sectors and the whole iPXE binary placed within the "protected mode
kernel" portion of the zImage.

The work carried out years ago to create the .mrom format provides a
mechanism allowing the iPXE binary to be split into a small real-mode
header and a larger payload.  This neatly matches the way that a
bzImage is loaded: the "setup sectors" can contain the header and the
"protected mode kernel" can contain the payload.

This removes the size restrictions on an iPXE .lkrn image (and hence
on derived image formats such as .iso).

Also remove obsolete copyright information, since none of the original
code or functionality now remains.

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

Ensure that all segment registers have zero in the low two bits before
transitioning to protected mode.  This allows the CPU state to
immediately be deemed to be "valid", and eliminates the need for any
further emulated instructions.

Load the protected-mode interrupt descriptor table after switching to
protected mode, since this avoids triggering an EXCEPTION_NMI and
corresponding VM exit.

This reduces the time taken by real_to_prot under KVM by around 50%.

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

We currently use flat real mode wherever real mode is required.  This
guarantees that we will not surprise some unsuspecting external caller
which has carefully set up flat real mode by suddenly reducing the
segment limits to 64kB.

However, operating in flat real mode imposes a severe performance
penalty in some virtualisation environments, since some CPUs cannot
fully virtualise flat real mode and so the hypervisor must fall back
to emulation.  In particular, operating under KVM on a pre-Westmere
Intel CPU will be at least an order of magnitude slower, to the point
that there is a visible teletype effect when printing anything to the
BIOS console.  (Older versions of KVM used to cheat and ignore the
"flat" part of flat real mode, which masked the problem.)

Switch (back) to using genuine real mode with 64kB segment limits
instead of flat real mode.  Hopefully this won't break anything.

Add an explicit switch to flat real mode before returning to the BIOS
from the ROM prefix, since we know that a PMM BIOS will call the ROM
initialisation point (and potentially the BEV) in flat real mode.

As noted in previous commit messages, it is not possible to restore
the real-mode segment limits after a transition to protected mode,
since there is no way 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>

Commit c429bf0 ("[romprefix] Store boot bus:dev.fn address as autoboot
device location") introduced a regression by using register %cx to
temporarily hold the PCI bus:dev.fn address, despite the fact that %cx
was already being used to hold the stored BIOS stack segment.
Consequently, when returning to the BIOS after a failed or cancelled
boot attempt, iPXE would end up calling INT 18 with the stack segment
set equal to the PCI bus:dev.fn address.  Writing to essentially
random areas of memory tends to upset even the more robust BIOSes.

Fix by using register %ax to temporarily hold the PCI bus:dev.fn
address.

Reported-by: Anton D. Kachalov <mouse@yandex-team.ru>
Tested-by: Anton D. Kachalov <mouse@yandex-team.ru>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

Per the BIOS Boot Specification, the initialization phase of the ROM
is called with the PFA (PCI Function Address) in the %ax register.
The intention is that the ROM code will store that device address
somewhere and use it for booting from that device when the Boot Entry
Vector (BEV) is called.  iPXE does store the PFA, but doesn't use it
to select the boot network device.  This renders BIOS IPL lists fairly
ineffective.

Fix by using the BBS-specified bus:dev.fn address as the autoboot
device location.

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

iPXE currently prints a "Press Ctrl-B" banner twice: once when the ROM
is first called for initialisation and again if we attempt to boot
from the ROM.  This slows boot, especially when the NIC is not the
primary boot device.  Tools such as libguestfs make use of QEMU VMs
for performing maintenance on disk images and may make use of NICs in
the VM for network support.  If iPXE introduces a static init-time
delay, that directly translates to increased runtime for the tools.

Fix by allowing the ROM banner timeout to be configured independently
of the main banner timeout.

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

Originally-implemented-by: Christian Hesse <list@eworm.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

When chainloading, always retrieve the cached DHCPACK packet from the
underlying PXE stack, and apply it as the original contents of the
"net<X>.dhcp" settings block.  This allows cached DHCP settings to be
used for any chainloaded iPXE binary (not just undionly.kkpxe).

This change eliminates the undocumented "use-cached" setting.  Issuing
the "dhcp" command will now always result in a fresh DHCP request.

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

Commit 2422647 ("[prefix] Allow prefix to specify an arbitrary maximum
address for relocation") introduced a regression into the UNDI ROM
loader by preserving an extra register on the stack without modifying
the %sp-relative addresses used in the routine.

Fix by correcting the %sp-relative addresses to allow for the extra
preserved variable.

Signed-off-by: Frediano Ziglio <frediano.ziglio@citrix.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

Report the cause of the failure when we are unable to open the .mrom
payload.  There are two possible failure cases:

 - Unable to find a suitable memory BAR to borrow (e.g. if the NIC
   doesn't have a memory BAR that is at least as large as the
   expansion ROM BAR, or if the memory BAR has been assigned a 64-bit
   address which won't fit into the 32-bit expansion ROM BAR).  This
   will be reported as "BABABABA".

 - Unable to find correct ROM image within the BAR.  This will be
   reported as the address (within the borrowed BAR) at which we first
   fail to find a valid 55AA signature.

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

Commit 2629b7e ("[pcbios] Inhibit all calls to INT 15,e820 and INT
15,e801 during POST") introduced a regression into .lkrn images when
used with no corresponding initrd.

Specifically, the semantics of the "maximum address for relocation"
value passed to install_prealloc() in %ebp changed so that zero became
a special value meaning "inhibit use of INT 15,e820 and INT 15,e801".
The %ebp value meaing "no upper limit on relocation" was changed from
zero to 0xffffffff, and all prefixes providing fixed values for %ebp
were updated to match the new semantics.

The .lkrn prefix provides the initrd base address as the maximum
address for relocation.  When no initrd is present, this address will
be zero, and so will unintentionally trigger the "inhibit INT 15,e820
and INT 15,e801" behaviour.

Fix by explicitly setting %ebp to 0xffffffff if no initrd is present
before calling install_prealloc().

Reported-by: Ján ONDREJ (SAL) <ondrejj@salstar.sk>
Tested-by: Ján ONDREJ (SAL) <ondrejj@salstar.sk>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

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>

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.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>

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

Some AMI BIOSes apparently break in exciting ways when asked for PMM
allocations for sizes that are not multiples of 4kB.

Fix by rounding up the image source area to the nearest 4kB.  (The
temporary decompression area is already rounded up to the nearest
128kB, to facilitate sharing between multiple iPXE ROMs.)

Reported-by: Itay Gazit <itayg@mellanox.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

PCI3.0 allows us to report a "runtime size" which can be smaller than
the actual ROM size.  On systems that support PMM our runtime size
will be small (~2.5kB), which helps to conserve the limited option ROM
space.  However, there is no guarantee that the PMM allocation will
succeed, and so we need to report the worst-case runtime size in the
PCI header.

Move the "shrunk ROM size" field from the PCI header to a new "iPXE
ROM header", allowing it to be accessed by ROM-manipulation utilities
such as disrom.pl.

Reported-by: Anton D. Kachalov <mouse@yandex-team.ru>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

Suggested-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

PXENV_FILE_CMDLINE is an iPXE extension, and will not be supported by
most PXE stacks.  Do not report any errors to the user, since in
almost all cases the error will mean simply "not loaded by iPXE".

Reported-by: Patrick Domack <patrickdk@patrickdk.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

Use PXENV_FILE_CMDLINE to retrieve the command line (if any) provided
by the invoking PXE stack.

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

Some BIOSes (observed on a Supermicro system with an AMI BIOS) seem to
use the area immediately below 0x7c00 to store data related to the
boot process.  This data is currently liable to be overwritten by the
temporary stack used while decompressing and installing iPXE.

Try to avoid any such problems by placing the temporary stack
immediately after the loaded iPXE binary.  Any memory used by the
stack could then potentially have been overwritten anyway by a larger
binary.

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

PMM defines the return code 0xffffffff as meaning "unsupported
function".  It's hard to imagine a PMM BIOS that doesn't support
pmmAllocate(), but apparently such things do exist.

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

A .mrom image currently assumes that it is the first image within the
expansion ROM BAR, which may not be correct when multiple images are
present.

Fix by scanning through the BAR until we locate an image matching our
build ID.

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

The header of a .mrom image declares its length to be only a few
kilobytes; the remainder is accessed via a sideband mechanism.  This
makes it difficult to append an additional ROM image, such as an EFI
ROM.

Add a second, dummy ROM header covering the payload portion of the
.mrom image, allowing consumers to locate any appended ROM images in
the usual way.

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

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

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>

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>

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>

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

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

iPXE specifies a value of 0 for cmdline_size, causing GRUB to not pass
in a command line.  Fix by setting cmdline_size to the maximum value
of 2047.

Signed-off-by: Valentine Barshak <gvaxon@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

Signed-off-by: Valentine Barshak <gvaxon@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

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>

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>

Reported-by: David Yeske <dyeske@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>

Signed-off-by: Bastian Blank <waldi@debian.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

iPXE allocates its first PMM block using the image source length,
which is rounded up to the nearest 16-byte paragraph.  It then copies
in data of a length calculated from the ROM size, which is
theoretically less than or equal to the image source length, but is
rounded up to the nearest 512-byte sector.  This can result in copying
beyond the end of the allocated PMM block, which can corrupt the PMM
data structures (and other essentially arbitrary areas of memory).

Fix by rounding up the image source length to the nearest 512-byte
sector before using it as the PMM allocation length.

Reported-by: Alex Williamson <alex.williamson@redhat.com>
Reported-by: Jarrod Johnson <jarrod.b.johnson@gmail.com>
Reported-by: Itay Gazit <itayg@mellanox.co.il>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

Some prefixes (e.g. .lkrn) allow a command line to be passed in to
iPXE.  At present, this command line is ignored.

If a command line is provided, treat it as an embedded script (without
an explicit "#!ipxe" magic marker).  This allows for patterns of
invocation such as

  title  iPXE
  kernel /boot/ipxe.lkrn dhcp && \
         sanboot iscsi:10.0.4.1::::iqn.2010-04.org.ipxe.dolphin:storage

Here GRUB is instructed to load ipxe.lkrn with an embedded script
equivalent to

  #!ipxe
  dhcp
  sanboot iscsi:10.0.4.1::::iqn.2010-04.org.ipxe.dolphin:storage

This can be used to effectively vary the embedded script without
having to rebuild ipxe.lkrn.

Originally-implemented-by: Dave Hansen <dave@sr71.net>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

The "size" bit (aka the D/B) bit should (as far as I can tell) be
irrelevant for accesses to a non-code, non-stack, expand-upwards
segment.  However, VirtualBox fails on some accesses via this segment
if this bit is not set.

This change allows iPXE to boot under VirtualBox without having to
disable VT-x/AMD-V support.

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