Currently, if you attempt to build 64-bit EFI binaries on a 32-bit
system without a suitable cross-compiling version of libbfd, the iPXE
build will die with a segmentation fault in elf2efi64.

Fix by properly handling the return value from bfd_check_format().

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>

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

Signed-off-by: Piotr Jaroszyński <p.jaroszynski@gmail.com>
Signed-off-by: Marty Connor <mdc@etherboot.org>

The function recorder is a crash and hang debugging tool.  It logs each
function call into a memory buffer while gPXE runs.  After the machine
is reset, and if the contents of memory have not been overwritten, gPXE
will detect the memory buffer and print out its contents.

This allows developers to see a trace of the last functions called
before a crash or hang.  The util/fnrec.sh script can be used to convert
the function addresses back into symbol names.

To build with fnrec:

    make FNREC=1

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

Debian based systems may have genisoimage(1) instead of mkisofs(1).
They are command-line compatible so the util/geniso script should be
able to choose either one.

This patch also changes the use of the mkisofs quiet (-q) flag to its
long form (-quiet).  This should be compatible with more versions of
cdrtools and cdrkit.

Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
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>

This is useful when comparing size optimizations.

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

Recent gcc versions generate more warnings when compiling util/zbin.c
on a 64-bit system:

util/zbin.c: In function `read_file':
util/zbin.c:85: warning: format `%d' expects type `int', but
                argument 3 has type `size_t'
util/zbin.c:91: warning: format `%d' expects type `int', but
                argument 3 has type `size_t'
util/zbin.c: In function `read_zinfo_file':
util/zbin.c:119: warning: format `%d' expects type `int', but
                 argument 4 has type `size_t'
util/zbin.c: In function `alloc_output_file':
util/zbin.c:134: warning: format `%d' expects type `int', but
                 argument 3 has type `size_t'
util/zbin.c: In function `process_zinfo_add':
util/zbin.c:244: warning: format `%d' expects type `int', but
                 argument 3 has type `size_t'
util/zbin.c:266: warning: format `%d' expects type `int', but
                 argument 7 has type `size_t'
util/zbin.c:286: warning: format `%#x' expects type `unsigned int',
                 but argument 7 has type `size_t'
util/zbin.c: In function `write_output_file':
util/zbin.c:348: warning: format `%d' expects type `int', but
                 argument 3 has type `size_t'

This patch eliminates these warnings.

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

src/util/gensdsk is a shell script and should have execute permission.

Reported-by: sobtwmxt sobtwmxt@sdf.lonestar.org

Recent gcc versions generate warnings when compiling util/zbin.c
( tested with gcc-4.3.3 ):

util/zbin.c: In function ‘process_zinfo_pack’:
util/zbin.c:200: warning: format ‘%#zx’ expects type ‘size_t’, but argument 6
has type ‘long unsigned int’
util/zbin.c: In function ‘process_zinfo_add’:
util/zbin.c:257: warning: format ‘%#lx’ expects type ‘long unsigned int’, but
argument 4 has type ‘int’
util/zbin.c:266: warning: format ‘%#lx’ expects type ‘long unsigned int’, but
argument 4 has type ‘int’
util/zbin.c:266: warning: format ‘%d’ expects type ‘int’, but argument 8 has
type ‘long unsigned int’
util/zbin.c:286: warning: format ‘%#lx’ expects type ‘long unsigned int’, but
argument 6 has type ‘int’
util/zbin.c:286: warning: format ‘%#lx’ expects type ‘long unsigned int’, but
argument 7 has type ‘size_t’

This patch eliminates these warnings.

Tested with gcc-4.3.3 on Ubuntu 9.04 and gcc-4.1.2 on Debian Etch.

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

The mtools version check does not handle GNU mtools 4.0.10.  This commit
makes the pattern more general so it matches older mtools as well as the
newer "mtools (GNU mtools) 4.0.10" string.

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

A jump instruction starts at the third byte of an option ROM image, and
it is required that the bytes in the whole image add up to zero. To
achieve this, a checksum byte is usually placed after the jump. The jump
can be either a short jump (2 bytes, EB xx) or a near jump (3 bytes,
E9 xx xx). gPXE's romprefix.S uses a near jump, but modrom.pl assumed
a short jump, and clobbered the high byte of the offset. This caused
modrom-modified gPXE ROM images to crash the system during POST.

Fix by making modrom.pl place the checksum at byte 6, like makerom.pl does.

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>

If isolinux.bin is not installed in the expected location the error
message shown is slightly misleading.

Signed-off-by: Vibi Sreenivasan <vibi_sreenivasan@cms.com>
Signed-off-by: Michael Brown <mcb30@etherboot.org>

The MIT and ISC licenses are legally equivalent to the bsd2 license,
but with slightly different verbiage.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Michael Brown <mcb30@etherboot.org>

The geniso, genliso and gensdsk scripts contain hard-coded temporary
directory names, and so could potentially collide with each other when
run as part of a concurrent build (e.g. "make -j 4").

Fix by using mktemp to generate suitable temporary directory names.

We add a syslinux floppy disk type using parts of the genliso script.
This floppy image cat be dd'ed to a physical floppy or used in
instances where a virtual floppy with an mountable DOS filesystem is
useful.

We also modify the genliso script to only generate .liso images
rather than creating images depending on how it is called.

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

It is now possible to run e.g.

  make bin/rtl8139.dsk.licence

in order to see a licensing assessment for any given gPXE build.  The
assessment will either produce a single overall licence for the build
(based on combining all the licences used within the source files for
that build), or will exit with an error stating why a licence
assessment is not possible (for example, if there are files involved
that do not yet contain an explicit FILE_LICENCE() declaration).

Commit b149a99 ([build] Round up SUBx deltas) introduced a
signed/unsigned issue that affects gPXE images built on 32-bit hosts.
The zbin fixup utility performed an unsigned division, which led to
.usb images with an incorrect number of sectors to load.

The issue snuck by on 64-bit hosts since uint32_t is promoted to long.
On 32-bit hosts it is promoted to unsigned long.

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

Sometimes it's just so much fun doing things the complicated way that
you forget to check the man page for the existence of a simpler
syntax.

Some utilities that expect a floppy disk image (e.g. iLO?) may test
for a file of the correct size.  Reinstate the .pdsk image format in
order to provide this if needed.

QEMU will silently round down a disk or ROM image file to the nearest
512 bytes.  Fix by always padding .rom, .dsk and .hd images to the
nearest 512-byte boundary.

Originally-fixed-by: Stefan Hajnoczi <stefanha@gmail.com>

The zbin compressor fixup utility rounds down file sizes before
calculating their difference.  This produces incorrect values and may
cause truncated gPXE images to be loaded at boot.

The following example explains the problem:
ilen    = 48 bytes     (uncompressed input file)
olen    = 17 bytes     (compressed output file)
divisor = 16 bytes     (paragraph granularity)
fixmeup = 3 paragraphs (value to fix up)

olen / divisor - ilen / divisor
= 1 - 3
= -2 paragraphs  (old delta calculation)

( align ( olen, divisor ) - align ( ilen, divisor ) ) / divisor
= 2 - 3
= -1 paragraphs  (new delta calculation)

If we perform the SUBx operation with old delta:
fixmeup + -2 = 1 paragraph gets loaded by the prefix

With the new delta:
fixmeup + -1 = 2 paragraphs get loaded by the prefix

The old delta calculation removes the last paragraph; the prefix will
load a truncated copy of gPXE into memory.  We need to load 2
paragraphs since olen is 17 bytes.  Loading only 1 paragraph (16
bytes) would truncate the last byte.

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

This is required in order to build on Mac OS X.

Suggested-by: Joshua Oreman <oremanj@rwcr.net>

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

The UEFI specification does not mention ROM checksums, and reassigns
the field typically used as a checksum byte.  The UEFI shell
"loadpcirom" utility does not verify ROM checksums, but it seems that
some UEFI BIOSes do.

Merge in the changes that allow for building EFI driver images (that
can be loaded using the EFI shell's "load" command) as well as EFI
applications.

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.

Currently the only supported platform for x86_64 is EFI.

Building an EFI64 gPXE requires a version of gcc that supports
__attribute__((ms_abi)).  This currently means a development build of
gcc; the feature should be present when gcc 4.4 is released.

In the meantime; you can grab a suitable gcc tree from

  git://git.etherboot.org/scm/people/mcb30/gcc/.git

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.

Undefined symbols shouldn't reach sortobjdump.pl, but if they do then it
is not a helpful place to report the error.

Must check that argument to a fclose() is not NULL -- we can get to the
'err' label when file was not opened.  fclose(NULL) is known to produce
core dump on some platforms and we don't want zbin to fail so loudly.

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

Option::ROM was assuming that ROM images using a short jump
instruction for the init entry point would have a zero byte at offset
5; this is not necessarily true.

Add support for manipulating the jump instruction that forms the
option ROM initialisation entry point, so that mergerom.pl can treat
it just like other entry points.

Add support for merging the initialisation entry point (and IBM BOFM
table) to mergerom.pl; this is another slightly icky but unfortunately
necessary GPL vs. NDA workaround.  When mergerom.pl replaces an entry
point in the original ROM, it now fills in the corresponding entry
point in the merged ROM with the original value; this allows (for
example) a merged initialisation entry point to do some processing and
then jump back to the original entry point.

This utility is required as a workaround for legal restrictions on
including GPL and non-GPL code within the same expansion ROM image.

While this is not encouraged, we are prepared to accept that
concatenation of ROM images and updating of the ROM header data
structures can be classed as "mere aggregation" within the terms of
the GPL.

If in any doubt, assume that you cannot include GPL and non-GPL code
within the same expansion ROM image.  Contact the Etherboot team for
clarification on your specific circumstances.

The Option::ROM module provides an easy way to read and edit fields
within option ROM headers.

During development it is often handy to change the config.h options from
their defaults, for example to enable debugging features.

To prevent accidental commits of debugging config.h changes, mdc
suggested having a config-local.h that is excluded from source control.
This file acts as a temporary config.h and can override any of the
defaults.

This commit is an attempt to implement the config-local.h feature.

The config.h file now has the following as its last line:
/* @TRYSOURCE config-local.h */

The @TRYSOURCE directive causes config-local.h to be included at that
point in the file.  If config-local.h does not exist, no error will be
printed and parsing will continue as normal.  Therefore, mkconfig.pl is
"trying" to "source" config-local.h.

The generate-by-PCI-device-ID rules (bin/pci_VVVV_DDDD.rom) are generally
used for building actual ROM images to be burned, and the burning
utilities generally run under some DOS variant.  Change the filename from
pci_VVVV_DDDD.rom to VVVVDDDD.rom so that it is compatible with the DOS
8.3-character filename limit.

needing to know the gPXE internal ROM name.