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>

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 binutils versions will drag in an object to satisfy the entry
symbol; some won't.  Try to cope with this exciting variety of
behaviour by ensuring that all entry symbols are unique.

Remove the explicit inclusion of the prefix object on the linker
command line, since the entry symbol now provides all the information
needed to identify the prefix.

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

Commit 623469d ("[build] Eliminate unused sections at link-time")
introduced a regression in several build formats, in which the prefix
would end up being garbage-collected out of existence.  Fix by
ensuring that an entry symbol exists in each possible prefix, and is
required by the linker script.

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

Reported-by: Jedrzej Kalinowski <kalinoj1@iem.pw.edu.pl>
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>

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>

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>

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>

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>

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>

The standard option ROM format provides a header indicating the size
of the entire ROM, which the BIOS will reserve space for, load, and
call as necessary. However, this space is strictly limited to 128k for
all ROMs. gPXE ameliorates this somewhat by reserving space for itself
in high memory and relocating the majority of its code there, but on
systems prior to PCI3 enough space must still be present to load the
ROM in the first place. Even on PCI3 systems, the BIOS often limits the
size of ROM it will load to a bit over 64kB.

These space problems can be solved by providing an artificially small
size in the ROM header: just enough to let the prefix code (at the
beginning of the ROM image) be loaded by the BIOS. To the BIOS, the
gPXE ROM will appear to be only a few kilobytes; it can then load
the rest of itself by accessing the ROM directly using the PCI
interface reserved for that task.

There are a few problems with this approach. First, gPXE needs to find
an unmapped region in memory to map the ROM so it can read from it;
this is done using the crude but effective approach of scanning high
memory (over 0xF0000000) for a sufficiently large region of all-ones
(0xFF) reads. (In x86 architecture, all-ones is returned for accesses
to memory regions that no mapped device can satisfy.) This is not
provably valid in all situations, but has worked well in practice.
More importantly, this type of ROM access can only work if the PCI ROM
BAR exists at all. NICs on physical add-in PCI cards generally must
have the BAR in order for the BIOS to be able to load their ROM, but
ISA cards and LAN-on-Motherboard cards will both fail to load gPXE
using this scheme.

Due to these uncertainties, it is recommended that .xrom only be used
when a regular .rom image is infeasible due to crowded option ROM
space. However, when it works it could allow loading gPXE images
as large as a flash chip one could find - 128kB or even higher.

Signed-off-by: Marty Connor <mdc@etherboot.org>

For extremely tight space requirements and specific applications, it is
sometimes desirable to create gPXE images that cannot provide the PXE API
functionality to client programs. Add a configuration header option,
PXE_STACK, that can be removed to remove this stack. Also add PXE_MENU
to control the PXE boot menu, which most uses of gPXE do not need.

Signed-off-by: Marty Connor <mdc@etherboot.org>

gPXE currently takes advantage of the feature of PCI3.0 that allows
option ROMs to relocate the bulk of their code to high memory and so
take up only a small amount of space in the option ROM area. Currently,
the relocation can only take place if the BIOS's implementation of PMM
can be made to return blocks aligned to an even megabyte, because of
the A20 gate. AMI BIOSes, in particular, will not return allocations
that gPXE can use.

Ameliorate the situation somewhat by adding a prefix, .hrom, that works
identically to .rom except in the case that PMM allocation fails. Where
.rom would give up and place itself entirely in option ROM space, .hrom
moves to a block (assumed free) at HIGHMEM_LOADPOINT = 4MB. This allows
for the use of larger gPXE ROMs than would otherwise be possible.

Because there is no way to check that the area at HIGHMEM_LOADPOINT is
really free, other devices using that memory during the boot process
will cause failure for gPXE, the other device, or both. In practice
such conflicts will likely not occur, but this prefix should still be
considered EXPERIMENTAL.

Signed-off-by: Marty Connor <mdc@etherboot.org>

The option ROM header contains a one-byte field indicating the number
of 512-byte sectors in the ROM image.  Currently it is linked to
contain the number of uncompressed sectors, with an instruction to the
compressor to correct it.  This causes link failure when the
uncompressed size of the ROM image is over 128k.

Fix by replacing the SUBx compressor fixup with an ADDx fixup that
adds the total compressed output length, scaled as requested, to an
addend stored in the field where the final length value will be
placed.  This is similar to the behavior of ELF relocations, and
ensures that an overflow error will not be generated unless the
compressed size is still too large for the field.

This also allows us to do away with the _filesz_pgh and _filesz_sect
calculations exported by the linker script.

Output tested bitwise identical to the old SUBx mechanism on hd, dsk,
lkrn, and rom prefixes, on both 32-bit and 64-bit processors.

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

Some BIOSes support the BIOS Boot Specification (BBS) but fail to set
%es:%di correctly when calling the option ROM initialisation entry
point.  This causes gPXE to identify the BIOS as non-PnP (and so
non-BBS), leaving the user unable to control the boot order.

Fix by scanning for the $PnP signature ourselves, rather than relying
on the BIOS having passed in %es:%di correctly.

Tested-by: Helmut Adrigan <helmut.adrigan@chello.at>

The version of the GNU assembler shipped with Fedora 10
(2.18.50.0.9-8.fc10) complains about character literals in some of our
assembly code.  Changing $'x' to $( 'x' ) seems to fix the problem.
Yes, the whitespace is required; using just $('x') does not work.

Reported by Kevin O'Connor <kevin@koconnor.net>.

There are code paths other than PMM allocation that can result in our
changing the ROM checksum.  For example, we attempt to update our
product string to incorporate the PCI bus:dev.fn number.  In a system
that does not support PMM, we could therefore end up with an incorrect
checksum.

Fix by attempting to update the checksum unconditionally.

On non-BBS systems, we have to hook INT 19 in order to be able to boot
from the gPXE ROM at all.  However, doing this unconditionally will
prevent the user from booting via any other devices.

Previously, the INT 19 entry point would prompt the user to press B in
order to boot from gPXE, which makes it impossible to perform an
unattended network boot.  We now prompt the user to press N to skip
booting from gPXE, which allows for unattended operation.

This should be a better match for most real-world scenarios.  Most
modern systems support BBS and so are unaffected by this change.  Very
old (non-BBS) systems tend not to have PXE ROMs by default anyway; if
the user has added a gPXE ROM then they probably do want to boot from
the network.  Newer non-BBS systems are essentially limited to IBM
servers, which will recapture the INT 19 vector anyway and implement
their own boot-ordering selection mechanism.

Code paths that automatically allocate memory from the FBMS at 40:13
should also free it, if possible.

Freeing this memory will not be possible if either

  1. The FBMS has been modified since our allocation, or

  2. We have not been able to unhook one or more BIOS interrupt vectors.

The only way that PMM allows us to request a block in a region with
A20=0 is to ask for a block with an alignment of 2MB.  Due to the PMM
API design, the only way we can do this is to ask for a block with a
size of 2MB.

Unfortunately, some BIOSes will hit problems if we allocate a 2MB
block.  In particular, it may not be possible to enter the BIOS setup
screen; the BIOS setup code attempts a PMM allocation, fails, and
hangs the machine.

We now try allocating only as much as we need via PMM.  If the
allocated block has A20=1, we free the allocated block, double the
allocation size, and try again.  Repeat until either we obtain a block
with A20=0 or allocation fails.  (This is guaranteed to terminate by
the time we reach an allocation size of 2MB.)

Some hardware vendors have been known to remove all gPXE-related
branding from ROMs that they build.  While this is not prohibited by
the GPL, it is a little impolite.

Add a facility for adding branding messages via two #defines
(PRODUCT_NAME and PRODUCT_SHORT_NAME) in config/general.h.  This
should accommodate all known OEM-mandated branding requirements.
Vendors with branding requirements that cannot be satisfied by using
PRODUCT_NAME and/or PRODUCT_SHORT_NAME should contact us so that we
can extended this facility as necessary.

This extends the sanity checks on the runtime segment address provided
in %bx, first implemented in commit 5600955.

We now allow the ROM to be placed anywhere above a000:0000 (rather
than c000:0000, as before), since this is the region allowed by the
PCI 3 spec.  If the BIOS asks us to place the runtime image such that
it would overlap with the init-time image (which is explicitly
prohibited by the PCI 3 spec), then we assume that the BIOS is faulty
and ignore the provided runtime segment address.

Testing on a SuperMicro BIOS providing overlapping segment addresses
shows that ignoring the provided runtime segment address is safe to do
in these circumstances.

Some PCI 3 BIOSes seem to provide a garbage value in %bx, which should
contain the runtime segment address.  Perform a basic sanity check: we
reject the segment if it is below the start of option ROM space.  If
the sanity check fails, we assume that the BIOS was not expecting us
to be a PCI 3 ROM, and we just leave our image in situ.

Not fully understood, but it seems that the LMA of bss sections matters
for some newer binutils builds.  Force all bss sections to have an LMA
at the end of the file, so that they don't interfere with other
sections.

The symptom was that objcopy -O binary -j .zinfo would extract the
.zinfo section from bin/xxx.tmp as a blob of the correct length, but
with zero contents.  This would then cause the [ZBIN] stage of the
build to fail.

Also explicitly state that .zinfo(.*) sections have @progbits, in case
some future assembler or linker variant decides to omit them.

Reduce the number of sections within the linker script to match the
number of practical sections within the output file.

Define _section, _msection, _esection, _section_filesz, _section_memsz,
and _section_lma for each section, replacing the mixture of symbols that
previously existed.

In particular, replace _text and _end with _textdata and _etextdata, to
make it explicit within code that uses these symbols that the .text and
.data sections are always treated as a single contiguous block.

In particular, allow BANNER_TIMEOUT=0 to inhibit the prompt banners
altogether.

Ironically, this request comes from the same OEM that originally
required the prompts to be present during POST.

On non-BBS systems we hook INT 19, since there is no other way we can
guarantee gaining control of the flow of execution.  If we end up
doing this, prompt the user before attempting boot, since forcibly
capturing INT 19 is rather antisocial.

IBM's iSCSI Firmware Initiator checks the UNDIROMID pointer in the
!PXE structure that gets created by the UNDI loader.  We didn't
previously fill this value in.

The IBM iSCSI Firmware Initiator complains that we don't have a bus
type field in the UNDI ROMID structure, so include one.

INT 1A,B101 (get PCI BIOS version) will overwrite %edi.

Include PMM allocation result in POST banner.

Include full product string in "starting execution" message.

Also mark ourselves as supporting DDIM in PnP header, for
completeness.

Commit 12f203c introduced a bug that caused the UNDI loader to attempt
to load the UNDI code and data segments to incorrect addresses.

On a system that doesn't support BBS, we end up hooking INT19 to gain
control of the boot process.  If the system is PCI3.0, we must take
care to use the runtime value for %cs, rather than the POST-time
value, otherwise we end up pointing INT19 to the temporary option ROM
POST scratch area.

Add the missing instructions to the code path that I never tested due
to not having a PCI 3.0 system available.

(D'oh)

Commit fd0aef9 introduced a typo that caused PMM detection to start at
paragraph 0xe00 rather than 0xe000.  (Detection would still work, since it
would scan until it ran out of base memory, but it would end up scanning
an unnecessarily large portion of base memory.)

Spotted by Sebastian Herbszt <herbszt@gmx.de>.

When the BIOS doesn't support BBS, hooking INT 19 is the only way to add
ourselves as a boot device.  If we have to do this, we should at least
try to chain to the original INT 19 vector if our boot fails.

Idea suggested by Andrew Schran <aschran@google.com>