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.

The check for unresolved symbols does not explicitly specify an output
architecture format, and so causes a warning when building an i386 EFI
binary on an x86_64 platform.  This warning is harmless, and
specifying the output architecture in multiple places is cumbersome,
so just inhibit the warning.

At POST time some BIOSes return invalid e820 maps even though
they indicate that the data is valid.  We add a check that the first
region returned by e820 is RAM type and declare the map to be invalid
if it is not.

This extends the sanity checks from 8b20e5d ("[pcbios] Sanity-check
the INT15,e820 and INT15,e801 memory maps").

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

EFI provides a copy of the SMBIOS table accessible via the EFI system
table, which we should use instead of manually scanning through the
F000:0000 segment.

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.

Remove the assortment of miscellaneous hacks to guess the "network
boot device", and replace them each with a call to last_opened_netdev().

It still isn't guaranteed correct, but it won't be any worse than
before, and it will at least be consistent.

When trying to find the "first open network device", it helps to
actually check the NETDEV_OPEN flag.

Signed-off-by: Laurent Vivier <Laurent.Vivier@bull.net>

This brings us in to line with Linux definitions, and also simplifies
adding x86_64 support since both platforms have 2-byte shorts, 4-byte
ints and 8-byte long longs.

__cdecl is a misleading name, since it currently encapsulates both
cdecl and regparm(0) attributes.  Rename to __asmcall.

The initial PXE implementation in Etherboot had the goal of being
architecture-agnostic, but this goal has not been realised.

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.

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

gcc 4.4 adds another few warnings, and also seems to complain if we
place %ebp in the clobber list for any inline asm.

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 function is a major kludge, but can be made slightly more
accurate by ignoring net devices that aren't open.  Eventually it
needs to be removed entirely.

Settings can be constructed using a dotted-decimal notation, to allow
for access to unnamed settings.  The default interpretation is as a
DHCP option number (with encapsulated options represented as
"<encapsulating option>.<encapsulated option>".

In several contexts (e.g. SMBIOS, Phantom CLP), it is useful to
interpret the dotted-decimal notation as referring to non-DHCP
options.  In this case, it becomes necessary for these contexts to
ignore standard DHCP options, otherwise we end up trying to, for
example, retrieve the boot filename from SMBIOS.

Allow settings blocks to specify a "tag magic".  When dotted-decimal
notation is used to construct a setting, the tag magic value of the
originating settings block will be ORed in to the tag number.
Store/fetch methods can then check for the magic number before
interpreting arbitrarily-numbered settings.

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.

Someone at Dell must have a full-time job designing ways to screw up
implementations of INT 15,e820.  This latest gem is courtesy of a Dell
Xanadu system, which arbitrarily decides to obliterate the contents of
%esi.

Preserve %esi, %edi and %ebp across calls to INT 15,e820, in case
someone tries a variation on this trick in future.

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>

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.

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.

The userptr_t is now the fundamental type that gets used for conversions.
For example, virt_to_phys() is implemented in terms of virt_to_user() and
user_to_phys().

We now have two implementations for the timer API: one using the
time-of-day counter at 40:70 and one using RDTSC.  Both make use of
timer2_udelay().

The copy_{to,from}_phys() functions were obsoleted long ago by
copy_{to,from}_user().

relocate_to() also disappeared some time ago.

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.

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.

The arch/i386/Config file has long been marked as deprecated.  Move all
the pertinent bits to arch/i386/Makefile instead and remove
arch/i386/Config.

Although the E820 API allows for a caller to provide only a 20-byte
buffer, there exists at least one combination (HP BIOS, 32-bit WinPE)
that relies on information found only in the "extended attributes"
field, which requires a 24-byte buffer.

Allow for up to a 64-byte E820 buffer, in the hope of coping with
future idiocies like this one.

The ACPI specification defines an additional 4-byte field at offset 20
for an E820 memory map entry.  This field is presumably optional,
since generally E820 gets given only a 20-byte buffer to fill.
However, the bits of this optional field are defined as:

  bit 0 : region is enabled
  bit 1 : region is non-volatile memory rather than RAM

so it seems as though callers that pass in only a 20-byte buffer may
be missing out on some rather important information.

gcc should (I think) be warning about this anyway, but seems to do so
only when assertions are enabled for this object.