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>

REQUIRE_SYMBOL() formerly used a formulation of symbol requirement
that would allow a link to succeed despite lacking a required symbol,
because it did not introduce any relocations. Fix by renaming it to
REQUEST_SYMBOL() (since the soft-requirement behavior can be useful)
and add a REQUIRE_SYMBOL() that truly requires.

Add EXPORT_SYMBOL() and IMPORT_SYMBOL() for REQUEST_SYMBOL()-like
behavior that allows one to make use of the symbol, by combining a
weak external on the symbol itself with a REQUEST_SYMBOL() of a second
symbol.

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>

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.

_filesz was incorrectly forced to be aligned up to MAX_ALIGN.  In a
non-compressed build, this would cause a build failure unless _filesz
happened to already be aligned to MAX_ALIGN.

The section name seems to have significance for some versions of
binutils.

There is no way to instruct gcc that sections such as .bss16 contain
uninitialised data; it will emit them with contents explicitly set to
zero.  We therefore have to rely on the linker script to force these
sections to become uninitialised-data sections.  We do this by marking
them as NOLOAD; this seems to be the closest semantic equivalent in the
linker script language.

However, this gets ignored by some versions of ld (including 2.17 as
shipped with Debian Etch), which mark the resulting sections with
(CONTENTS,ALLOC,LOAD,DATA).  Combined with the fact that this version of
ld seems to ignore the specified LMA for these sections, this means that
they end up overlapping other sections, and so parts of .prefix (for
example) get obliterated by .data16's bss section.

Rename the .bss sections from .section_bss to .bss.section; this seems to
cause these versions of ld to treat them as uninitialised data.

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.

Some versions of ld choke on the "AT ( _xxx_lma )" in efi.lds with an
error saying "nonconstant expression for load base".  Since these were
only explicitly setting the LMA to the address that it would have had
anyway, they can be safely omitted.

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.

Wyse Streaming Manager server (WLDRM13.BIN) assumes that the PXENV+
entry point is at UNDI_CS:0000; apparently, somebody at Wyse has
difficulty distinguishing between the words "may" and "must"...

Add a dummy entry point at UNDI_CS:0000, which just jumps to the
correct entry point.

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.

Allow for an arbitrary number of splits of the system memory map via
INT 15,e820.

Features of the new map-mangling algorithm include:

  Supports random access to e820 map entries.

  Requires only sequential access support from the underlying e820
  map, even if our caller uses random access.

  Empty regions will always be stripped.

  Always terminates with %ebx=0, even if the underlying map terminates
  with CF=1.

  Allows for an arbitrary number of hidden regions, with underlying
  regions split into as many subregions as necessary.

Total size increase to achieve this is 193 bytes.

Define a list of N allowed memory regions, and split each underlying
e820 region into up to N subregions.  Strip resulting empty regions
out of the map, avoiding using the "return with CF set to strip last
empty region" trick, because it seems that bootmgr.exe in Win2k8 gets
upset if the memory map is terminated with CF set.

This is an intermediate checkin that defines a single allowed memory
region covering the entire 64-bit address space, and uses the existing
map-mangling code on top of the new region-splitting code.  This
sanitises the memory map to the point that Win2k8 is able to boot even
on a system that defines a final zero-length region at the 4GB mark.

I'm checking this in because it may be useful for future debugging
efforts to be able to run with the existing and known-working map
mangling code together with the map sanitisation capabilities of the
new map mangling code.

ROM initialisation vector now attempts to allocate a 2MB block using
PMM.  If successful, it copies the ROM image to this block, then
shrinks the ROM image to allow for more option ROMs.  If unsuccessful,
it leaves the ROM as-is.

ROM BEV now attempts to return to the BIOS, resorting to INT 18 only
if the BIOS stack has been corrupted.

_textdata_link_addr, _load_addr and _max_align in the linker scripts.
A bug in some versions of ld causes segfaults if the DEFINED() macro
is used in a linker script *and* the -Map option to ld is present.

We don't currently need to override any of these values; if we need to
do so in future then the solution will probably be to always specify
the values on the ld command line, and have the linker script not
define them at all.

compressor fixup section.

start of the non-prefix blocks in the loaded image, and rely on the
image ordering.  This should make introducing compression much easier.

image file.

causing the serial console to ignore input, because it happened to end up
linked with serial_ischar() at address 0, which core/console.c decided was
invalid).

Fix bug that caused over-allocation of .text16 and .data16 memory areas
by a factor of 16.

--nulltrap to the make target at the moment.)

install_prealloc.  I *think* these will suffice for all the 16-bit
prefixes.

advantage of the fact that we have to have a permanently-resident block
in base memory.

thinks they are.
Other bus drivers modified for consistency.

initial device, and will also allow for e.g. a device menu to be presented
to the user.