Commit ea12dc0 ("[build] Avoid hard-coding the path to perl")
introduced a build failure for fully clean trees (e.g. after running
"make veryclean"), since the dependency upon $(PARSEROM) now includes
a dependency upon "perl" (which doesn't exist) rather than upon
"/usr/bin/perl" (which does exist).

There should of course be no dependency upon the perl binary at all;
the dependency should be upon "./util/parserom.pl" alone.

Fix by removing the $(PERL) from the definition of Perl-based utility
paths, and adding $(PERL) at the point of usage.

Reported-by: Stefan Hajnoczi <stefanha@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

Add preprocessor magic to the error definitions to enable every error
usage to be tracked.

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

See RFC 4578 for details.

Signed-off-by: Joshua Oreman <oremanj@rwcr.net>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

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

The linker chooses to look for _start first and always picks
efidrvprefix.o to satisfy it (probably because it's earlier in the
archive) which causes a multiple definition error when the linker
later has to pick efiprefix.o for other symbols.

Fix by using EFI-specific TGT_LD_FLAGS with an explicit entry point.

Signed-off-by: Piotr Jaroszyński <p.jaroszynski@gmail.com>
Signed-off-by: Joshua Oreman <oremanj@rwcr.net>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

Dependencies are considered in left-to-right order so the source file
needs to come first in this case.

Signed-off-by: Piotr Jaroszyński <p.jaroszynski@gmail.com>
Signed-off-by: Joshua Oreman <oremanj@rwcr.net>
Signed-off-by: Michael Brown <mcb30@ipxe.org>

On 64-bit systems with both 32-bit and 64-bit libraries installed, ld
tends to generate noisy "skipping incompatible /usr/lib/libxxx.so"
messages when building elf2efi.c.

Fix by passing --no-warn-search-mismatch to ld.

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>

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

Include config/local/$file in config/$file where it makes sense and
create empty local configs during build if not present.

Modified-by: Michael Brown <mcb30@etherboot.org>
Signed-off-by: Michael Brown <mcb30@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>

Embedded image support uses .incbin in inline assembly to include binary
files.  The file dependency is not spotted by ccache when deciding
whether or not to rebuild embedded.o.  This results in builds that
contain an outdated version of the embedded image when ccache is used.

Reported-by: Tim 'Shaggy' Bielawa <tbielawa@jabber.org>
Reported-by: Matt Domsch <Matt_Domsch@dell.com>
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>

The bin/xxx.sizes targets examine the list of obj_ symbols in bin/xxx.tmp
to determine which objects to measure the size of. These symbols have been
normalized to C identifiers, so the result is an error message from `size'
when examining a target that includes objects that were originally named
with hyphens.

Fix by turning obj_foo_bar into $(wildcard bin/foo?bar.o) instead of
bin/foo_bar.o.

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>

Debug builds for filenames with hyphens such as:

     $ make bin/via-rhine.dsk DEBUG=via-rhine

fail with:

     [BUILD] bin/via-rhine.dbg1.o
     <command-line>: error: missing whitespace after the macro name
     make: *** [bin/via-rhine.dbg1.o] Error 1

This is because "-" is not a legal character in C identifiers, and
gcc rejects "-Ddebug_via-rhine=1" as an argument.

Signed-off-by: Daniel Verkamp <daniel@drv.nu>
Signed-off-by: Joshua Oreman <oremanj@rwcr.net>
Signed-off-by: Marty Connor <mdc@etherboot.org>

gcc 4.4 defaults to using .cfi assembler directives for debugging
information, which causes unneeded .eh_frame sections to be generated.
These sections are already stripped out by our linker script, so don't
affect the final build, but do distort the output of "size" when run
on individual .o files; the .eh_frame size is included within the size
reported for .text.  This makes it difficult to accurately judge the
effects of source code changes upon object code size.

Fix by adding -fno-dwarf2-cfi-asm to CFLAGS if we detect that this
option is supported by the gcc that we are compiling with.

Tested-by: Daniel Verkamp <daniel@drv.nu>

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

You can now type e.g.

  make bin/rtl8139.rom.sizes

in order to see the (uncompressed) sizes of all of the object files
linked in to bin/rtl8139.rom.  This should make it easier to identify
relevant code bloat.

Now that there are no remaining multiple-object source files, kill off
the mechanism in order to simplify the Makefile.

You can now type e.g.

  make bin/rtl8139.rom.deps

to see a list of the source files included in the build of
bin/rtl8139.rom.  This is intended to assist with copyright vetting.

Other new debugging targets include

  make bin/rtl8139.rom.objs

to see a list of object files linked in to bin/rtl8139.rom, and

  make bin/rtl8139.rom.nodeps

to see a list of the source files that are *not* required for the
build of bin/rtl8139.rom.

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 "seq" command is GNU-specific; a BSD userland will not have it.
Use POSIX-conforming "awk" instead.

Reported-by: Joshua Oreman <oremanj@rwcr.net>
Suggested-by: Stefan Hajnoczi <stefanha@gmail.com>

On Mac OS X, it is necessary to build binutils manually; the system
does not provide bfd.h or the libbfd or libiberty libraries.

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

Some builds of the GNU assembler will treat a '/' character as a
comment delimiter.  Adding "--divide" will cause it to be treated as a
division operator, as we expect.  The "--divide" option is not
available in all gas versions, so apply it only conditionally.

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

bin/embedded.o has a build dependency on bin/.embedded.list, which
gets generated automatically by the Makefile.  However, if the
EMBEDDED_IMAGE list is empty, bin/.embedded.list will never be
created, and so bin/embedded.o will be rebuilt every time due to a
missing dependency.

Fix by forcing bin/.embedded.list to be created even if the list is
empty.

Having a default script containing

  #!gpxe
  autoboot

can cause problems when entering commands to load and start a kernel
manually; the default script image will still be present when the
kernel is started and so will be treated as an initrd.  It is possible
to work around this by typing "imgfree" before any other commands, but
this is counter-intuitive.

Fix by allowing the embedded image list to be empty (in which case we
just call autoboot()), and making this the default.

Reported by alkisg@gmail.com.

This patch extends the embedded image feature to allow multiple
embedded images instead of just one.

gPXE now always boots the first embedded image on startup instead of
doing the hardcoded DHCP boot (aka autoboot).

Based heavily upon a patch by Stefan Hajnoczi <stefanha@gmail.com>.

Add --fatal-warnings to ASFLAGS; this is the equivalent of -Werror in
CFLAGS (which we have used since July 2007).

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 some systems, libbfd is supplied only as a static library; linking
will fail unless -liberty is also specified.

FreeBSD requires the object format to be specified as elf_i386_fbsd,
rather than elf_i386.

Based on a patch from Eygene Ryabinkin <rea-fbsd@codelabs.ru>

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.

-Wformat-nonliteral is not enabled by -Wall and needs to be explicitly
 specified.

Modified the few files that use nonliteral format strings to work with
this new setting in place.

Inspired by a patch from Carl Karsten <carl@personnelware.com> and an
identical patch from Rorschach <r0rschach@lavabit.com>.

Allow for the build CPU architecture and platform to be specified as part
of the make command goals.  For example:

  make bin/rtl8139.rom      # Standard i386 PC-BIOS build

  make bin-efi/rtl8139.efi  # i386 EFI build

The generic syntax is "bin[-[arch-]platform]", with the default
architecture being "i386" (regardless of the host architecture) and the
default platform being "pcbios".

Non-path targets such as "srcs" can be specified using e.g.

  make bin-efi srcs

Note that this changeset is merely Makefile restructuring to allow the
build architecture and platform to be determined by the make command
goals, and to export these to compiled code via the ARCH and PLATFORM
defines.  It doesn't actually introduce any new build platforms.

Some older versions of gcc don't complain about unknown compiler flags
unless you ask them to actually compile; asking them to merely
preprocess won't trigger the error.

Fix the -fno-stack-protector test by making it attempt to compile an
empty file, rather than preprocess an empty file.

?= in a Makefile means that that variable can be overridden by the
environment.  This is confusing to users, especially with a generic
name like "ARCH".

Signed-off-by: H. Peter Anvin <hpa@zytor.com>