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.

treated as being provided by that object" code.

into account (and so remove the false positives due to .tbl.* symbols).

- value of n passed to wgetnstr should now be equivalent to output from strlen (i.e. length excluding NUL-terminating character)

- added mucurses_test.c build targets

the jmp instruction).

Added iSCSI testing.

the real pcap_inject in the case where we do have it.

libpcap are lacking the function.  For now, we always use the
substitute version, since there's no easy way to determine whether or
not we need it.

the first standalong uIP-based protocol module.

individual options.

Created the embryonic beginnings of a cleanly separated driver and
protocol stack API.

hijack daemon) and a functional but very ugly and very primitive
wrapper around uIP.

This passes proof-of-concept testing; it successfully initiates a TCP
connection and responds to pings.