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 .elf, .elfd, .lmelf, and .lmelfd prefices were brought over from
legacy Etherboot and they do not build in gPXE.  This patch removes the
ELF prefices.

Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>

The unfinished .exe prefix was brought over from legacy Etherboot.
There has been no demand for .exe images so this patch removes the
prefix.

Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>

The DOS .com prefix was brought over from legacy Etherboot but does not
build.  There has been no demand for .com images so this patch removes
the prefix.

Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>

The .lkrn prefix allows gPXE to be loaded as a Linux bzImage.  The
bImage prefix was carried over from legacy Etherboot and does not build.
This patch removes the .bImage prefix, use .lkrn instead.

Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>

It might be the case that we wish to chain to an NBP without
being "in the way".  We now implement a hook in our exit path
for gPXE *.*pxe build targets.  The hook is a pointer to a
SEG16:OFF16 which we try to jump to during exit.  By default,
this pointer results in the usual exit path.

We also implement the "pxenv_file_exit_hook" PXE API routine
to allow the user to specify an alternate SEG16:OFF16 to jump
to during exit.

Unfortunately, this additional PXE extension has a cost
in code size.  Fortunately, a look at the size difference
for a gPXE .rom build target shows zero size difference
after compression.

The routine is documented in doc/pxe_extensions as follows:

FILE EXIT HOOK

Op-Code:	PXENV_FILE_EXIT_HOOK (00e7h)

Input:	Far pointer to a t_PXENV_FILE_EXIT_HOOK parameter
		structure that has been initialized by the caller.

Output:	PXENV_EXIT_SUCCESS or PXENV_EXIT_FAILURE must be
		returned in AX.  The Status field in the parameter
		structure must be set to one of the values represented
		by the PXENV_STATUS_xxx constants.

Description:Modify the exit path to jump to the specified code.
		Only valid for pxeprefix-based builds.

typedef struct s_PXENV_FILE_EXIT_HOOK {
        PXENV_STATUS_t Status;
        SEGOFF16_t Hook;
} t_PXENV_FILE_EXIT_HOOK;

Set before calling API service:

Hook:	The SEG16:OFF16 of the code to jump to.

Returned from API service:

Status:	See PXENV_STATUS_xxx constants.

Requested-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Shao Miller <shao.miller@yrdsb.edu.on.ca>
Signed-off-by: Marty Connor <mdc@etherboot.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>

If we don't unload the PXE stack before executing gPXE, automatically
take advantage of the cached DHCPACK that the underlying/parent PXE
stack can provide. If that cached DHCPACK contains option 175.178, or
the user sets the use-cached setting before invoking DHCP, the real
DHCP request will be skipped and the cached DHCPACK will be used for
network configuration. Otherwise, the cached settings block is thrown
away as soon as a fresh one is acquired.

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>

Add FILE_LICENCE declarations to almost all files that make up the
various standard builds of gPXE.

Etherboot 5.4 erroneously treats PXENV_UNLOAD_STACK as the "final
shutdown" call, and unhooks INT15.  When using gPXE's undionly.kpxe,
this results in gPXE overwriting the portion of Etherboot located in
high memory, because it is no longer hidden from the system memory map
at the time that gPXE loads.

Work around this by explicitly testing for Etherboot as the underlying
PXE stack (as is already done in undinet.c) and skipping the call to
PXENV_UNLOAD_STACK if necessary.

The build mechanism currently allows for multiple objects per source
file.  The only remaining user of this is unnrv2b.S.  Replace this
usage with a separate unnrv2b16.S wrapper file, as is currently used
for e.g. pxeprefix.S and kpxeprefix.S.

The parsing of the !PXE and PXENV+ structures share a fair bit of
code; merge the common code to save a few bytes.

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

Search for the PXE entry points (via the !PXE or PXENV+ structures)
through all known combinations of search methods.  Furthermore, if we
find a PXENV+ structure, attempt to use it to find the !PXE structure
if at all possible.

Certain combinations of PXE stack and BIOS result in a broken INT 18
call, which will leave the system displaying a "PRESS ANY KEY TO
REBOOT" message instead of proceeding to the next boot device.  On
these systems, returning via the PXE stack is the only way to continue
to the next boot device.  Returning via the PXE stack works only if we
haven't already blown away the PXE base code in pxeprefix.S.

In most circumstances, we do want to blow away the PXE base code.
Base memory is a limited resource, and it is desirable to reclaim as
much as possible.  When we perform an iSCSI boot, we need to place the
iBFT above the 512kB mark, because otherwise it may not be detected by
the loaded OS; this may not be possible if the PXE base code is still
occupying that memory.

Introduce a new prefix type .kkpxe which will preserve both the PXE
base code and the UNDI driver (as compared to .kpxe, which preserves
the UNDI driver but uninstalls the PXE base code).  This prefix type
can be used on systems that are known to experience the specific
problem of INT 18 being broken, or in builds (such as gpxelinux.0) for
which it is particularly important to know that returning to the BIOS
will work.

Written by H. Peter Anvin <hpa@zytor.com> and Stefan Hajnoczi
<stefanha@gmail.com>, minor structural alterations by Michael Brown
<mcb30@etherboot.org>.

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.

Try to avoid future problems caused by implicit section flags and/or
type information by instituting a policy that all .section
declarations must explicitly state the flags and type.

Most of this change was achieved using

    perl -pi \
      -e 's/".text"$/".text", "ax", \@progbits/ ; ' \
      -e 's/".text16"$/".text16", "ax", \@progbits/ ; ' \
      -e 's/".text16.null"$/".text16.null", "ax", \@progbits/ ; ' \
      -e 's/".text16.data"$/".text16.data", "aw", \@progbits/ ; ' \
      -e 's/".data"$/".data", "aw", \@progbits/ ; ' \
      -e 's/".data16"$/".data16", "aw", \@progbits/ ; ' \
      -e 's/".bss"$/".bss", "aw", \@nobits/ ; ' \
      -e 's/".bss16"$/".bss16", "aw", \@nobits/ ; ' \
      -e 's/".prefix"$/".prefix", "ax", \@progbits/ ; ' \
      -e 's/".prefix.lib"$/".prefix.lib", "awx", \@progbits/ ; ' \
      -e 's/".prefix.data"$/".prefix.data", "aw", \@progbits/ ; ' \
      -e 's/".weak"$/".weak", "a", \@nobits/ ; ' \
      `git grep -l '\.section'`

elf2efi converts a suitable ELF executable (containing relocation
information, and with appropriate virtual addresses) into an EFI
executable.  It is less tightly coupled with the gPXE build process
and, in particular, does not require the use of a hand-crafted PE
image header in efiprefix.S.

elf2efi correctly handles .bss sections, which significantly reduces
the size of the gPXE EFI executable.

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

With a 16-bit operand, lgdt/lidt will load only a 24-bit base address,
ignoring the high-order bits.  This meant that we could fail to fully
restore the GDT across a call into gPXE, if the GDT happened to be
located above the 16MB mark.

Not all of our lgdt/lidt instructions require a data32 prefix (for
example, reloading the real-mode IDT can never require a 32-bit base
address), but by adding them everywhere we will hopefully not forget
the necessary ones in future.

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.

We have EFI APIs for CPU I/O, PCI I/O, timers, console I/O, user
access and user memory allocation.

EFI executables are created using the vanilla GNU toolchain, with the
EXE header handcrafted in assembly and relocations generated by a
custom efilink utility.

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.

Explicitly state that we are using 32-bit addressing in 16-bit code.

GNU as 2.15 (FreeBSD/amd64 7-STABLE) got confused that 32-bit registers
are used in the code that was declared as 16-bit.  Add explicit modifier
'addr32' to make assembler happy.

Signed-off-by: Eygene Ryabinkin <rea-fbsd@codelabs.ru>

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)

H. Peter Anvin <hpa@zytor.com> sent word that Sergey Vlasov
<vsu@altlinux.ru> discovered gPXE lkrn images fail to load in SYSLINUX
3.70 because we have initrd_addr_max zeroed.  This patch sets the same
value as the Linux kernel.

Also change the header jmp instruction to use a hardcoded opcode value
like Linux does.  Just in case the assembler decides to use a three-byte
instruction instead of the desired two-byte jmp.

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