In particular, allow BANNER_TIMEOUT=0 to inhibit the prompt banners
altogether.

Ironically, this request comes from the same OEM that originally
required the prompts to be present during POST.

Based on a patch provided by XenSource for Etherboot 5.4.

Some really moronic BIOSes bring up the PXE stack via the UNDI loader
entry point during POST, and then don't bother to unload it before
overwriting the code and data segments.  If this happens, we really
don't want to leave INT 15 hooked, because that will cause any loaded
OS to die horribly as soon as it attempts to fetch the system memory
map.

We use a heuristic to detect whether or not we are being loaded at the
top of free base memory.  If we determine that we are being loaded at
some other arbitrary location in base memory, then we assume that it's
not safe to hook INT 15.

On non-BBS systems we hook INT 19, since there is no other way we can
guarantee gaining control of the flow of execution.  If we end up
doing this, prompt the user before attempting boot, since forcibly
capturing INT 19 is rather antisocial.

Some systems seem to report insane memory maps (particularly at POST
time).  Detect and work around some of the common failure cases.

If the INT 15,e820 memory map reports a region [0,0), this confuses
the "truncate to even megabytes" logic, which ends up rounding the
region 'down' to [0,fff00000).

Fix by ensuring that the region's end address is at least 1, before we
subtract 1 to obtain the "last byte in region" address.

INT 15,e801 is capable of returning a memory range that extends to
4GB, so allow for this in the debug message that shows the data
returned by INT 15,e801.

Apparently some BIOSes will place option ROMs on 512-byte boundaries.
While this is against specification, it doesn't actually hurt
anything, so we may as well increase our scan granularity to 512
bytes.

Contributed by Luca <lucarx76@gmail.com>

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.

The multiboot specification states that, for raw images, if
load_end_addr is zero then it should be interpreted as meaning "use
the entire file", and if bss_end_addr is zero it should be interpreted
as meaning "no bss".

Explicitly state that we are using 32-bit addressing in 16-bit code.

GNU as 2.15 (FreeBSD/amd64 7-STABLE) got confused that 32-bit registers
are used in the code that was declared as 16-bit.  Add explicit modifier
'addr32' to make assembler happy.

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

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.

The IBM iSCSI Firmware Initiator complains that we don't have a bus
type field in the UNDI ROMID structure, so include one.

INT 1A,B101 (get PCI BIOS version) will overwrite %edi.

Include PMM allocation result in POST banner.

Include full product string in "starting execution" message.

Also mark ourselves as supporting DDIM in PnP header, for
completeness.

Commit 12f203c introduced a bug that caused the UNDI loader to attempt
to load the UNDI code and data segments to incorrect addresses.

On a system that doesn't support BBS, we end up hooking INT19 to gain
control of the boot process.  If the system is PCI3.0, we must take
care to use the runtime value for %cs, rather than the POST-time
value, otherwise we end up pointing INT19 to the temporary option ROM
POST scratch area.

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.

Add the missing instructions to the code path that I never tested due
to not having a PCI 3.0 system available.

(D'oh)

H. Peter Anvin <hpa@zytor.com> sent word that Sergey Vlasov
<vsu@altlinux.ru> discovered gPXE lkrn images fail to load in SYSLINUX
3.70 because we have initrd_addr_max zeroed.  This patch sets the same
value as the Linux kernel.

Also change the header jmp instruction to use a hardcoded opcode value
like Linux does.  Just in case the assembler decides to use a three-byte
instruction instead of the desired two-byte jmp.

Add yet another ugly hack to iscsiboot.c, this time to allow the user to
inhibit the shutdown/removal of the iSCSI INT13 device (and the network
devices, since they are required for the iSCSI device to function).

On the plus side, the fact that shutdown() now takes flags to
differentiate between shutdown-for-exit and shutdown-for-boot means that
another ugly hack (to allow returning via the PXE stack on BIOSes that
have broken INT 18 calls) will be easier.

I feel dirty.

Shifting all INT13 drive numbers causes problems on systems that use a
sparse drive number space (e.g. qemu BIOS, which uses 0xe0 for the CD-ROM
drive).

The strategy now is:

  Each drive is assigned a "natural" drive number, being the next
  available drive number in the system (based on the BIOS drive count).

  Each drive is accessed using its specified drive number.  If the
  specified drive number is -1, the natural drive number will be used.

  Accesses to the specified drive number will be delivered to the
  emulated drive, masking out any preexisting drive using this number.

  Accesses to the natural drive number, if different, will be remapped to
  the masked-out drive.

The overall upshot is that, for examples:

  System has no drives.  Emulated INT13 drive gets natural number 0x80
  and specified number 0x80.  Accesses to drive 0x80 go to the emulated
  drive, and there is no remapping.

  System has one drive.  Emulated INT13 drive gets natural number 0x81
  and specified number 0x80.  Accesses to drive 0x80 go to the emulated
  drive.  Accesses to drive 0x81 get remapped to the original drive 0x80.

We can just treat all non-kernel images as initrds, which matches our
behaviour for multiboot kernels.  This allows us to eliminate initrd as
an image type, and treat the "initrd" command as just another synonym for
"imgfetch".

__from_data16 and __from_text16 now take a pointer to a
.data16/.text16 variable, and return the real-mode offset within the
appropriate segment.  This matches the use case for every occurrence
of these macros, and prevents potential future bugs such as that fixed
in commit d51d80f.  (The bug arose essentially because "&pointer" is
still syntactically valid.)

zImage kernels require the real-mode portion to be loaded at 9000:0000
rather than 1000:0000.

When the 16-bit segment registers are accessed using 32-bit instructions
the high order bytes are undefined on older CPUs.  We now explicitly
zero the high order bytes when snapshotting the CPU state.  This ensures
that the GDB stub reports consistent values for the segment registers.

Commit fd0aef9 introduced a typo that caused PMM detection to start at
paragraph 0xe00 rather than 0xe000.  (Detection would still work, since it
would scan until it ran out of base memory, but it would end up scanning
an unnecessarily large portion of base memory.)

Spotted by Sebastian Herbszt <herbszt@gmx.de>.

Send a null command, specifically "pulse outputs" with no outputs
selected, to the KBC after changing A20.  This was apparently done by DOS,
presumably as a synchronization hack, and the authors of the UHCI spec
thought it was inherent.  Therefore, there are systems out there (e.g. HP
DL360 G5) which will stop responsing to "legacy USB" unless they see the
null command, 0xFF, written to port 0x64 at the end of the A20 toggling
sequence.

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

If we ever need these macros, they should be defined in
include/{big,little}_bswap.h, and the whole family should be defined.

When the BIOS doesn't support BBS, hooking INT 19 is the only way to add
ourselves as a boot device.  If we have to do this, we should at least
try to chain to the original INT 19 vector if our boot fails.

Idea suggested by Andrew Schran <aschran@google.com>

2.6.22+ kernels have an extra field in the bzimage_header structure to
indicate the maximum permitted command-line length.  Use this if it is
available.

A bug in read_smbios_string() was causing the starting offset of the
SMBIOS structure to be added twice, resulting in completely the wrong
strings being returned.

Bug identified by Martin Herweg <m.herweg@gmx.de>

We never set up specific multicast filters; native drivers will ask
the card to receive all multicast packets.  The only way to achieve
this via the UNDI API is to enable promiscuous mode.

Delete ELF as a generic image type.  The method for invoking an
ELF-based image (as well as any tables that must be set up to allow it
to boot) will always depend on the specific architecture.  core/elf.c
now only provides the elf_load() function, to avoid duplicating
functionality between ELF-based image types.

Add arch/i386/image/elfboot.c, to handle the generic case of 32-bit
x86 ELF images.  We don't currently set up any multiboot tables, ELF
notes, etc.  This seems to be sufficient for loading kernels generated
using both wraplinux and coreboot's mkelfImage.

Note that while Etherboot 5.4 allowed ELF images to return, we don't.
There is no callback mechanism for the loaded image to shut down gPXE,
which means that we have to shut down before invoking the image.  This
means that we lose device state, protection against being trampled on,
etc.  It is not safe to continue afterwards.

See http://etherboot.org/wiki/dev/gdbstub for documentation.