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.

This allows settings to be expanded in a way that is safe to include
within a URI string, such as

  kernel http://10.0.0.1/boot.php?mf=${manufacturer:uristring}

where the ${manufacturer} setting may contain characters that are not
permitted (or have reserved purposes) within a URI.

Since whitespace characters will be URI-encoded (e.g. "%20" for a
space character), this also works around the problem that spaces
within an expanded setting would cause the shell to split command-line
arguments incorrectly.

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.

It is possible for the BIOS to use the UNDI API to bring up the NIC
prior to system boot.  If this happens, UNM_NIC_REG_CMDPEG_STATE will
contain the value 0xf00f (UNM_NIC_REG_CMDPEG_STATE_INITIALIZE_ACK),
and we should skip initialising the command PEG.

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

The firmware will now determine the right port mode on all cards, so
the PXE driver doesn't have to set it.  (Setting the port mode
apparently breaks some newer cards.)

At least one Dell system calls the UNDI loader entry point with the
BIOS console disabled.  The serial console is active only after a call
to initialise(), so move the debug message in undi_loader() so that it
can be displayed via the serial console.

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.

The domain etherboot.org was actually registered on 2000-01-09, not
2000-09-01.  (To put it another way, it was registered on 1/9/2000 (US
date format) rather than 1/9/2000 (sensible date format); this may
illuminate the cause of the error.)

"iqn.2000-09.org.etherboot:" is still valid as per RFC3720, but may be
surprising to users, so change it to something less unexpected.

Thanks to the anonymous contributor for pointing this one out.

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>

DUET (the EFI test environment) seems not to handle LF, so inhibit the
CR->LF conversion that the pty does for us by default.  This doesn't
affect operation of gPXE, which will happily accept either CR or LF.

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

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>

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.

Commit f58cc3f introduced a temporary workaround for a bug in current
prototype silicon, but failed to apply it to all eight PCI functions
within the device.

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.

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.

pxenv_udp_write() needs to specify a net device, otherwise ipv4 is
unable to route broadcast transmissions.

Determine the network-layer packet type and fill it in for UNDI
clients.  This is required by some NBPs such as emBoot's winBoot/i.

This change requires refactoring the link-layer portions of the
gPXE netdevice API, so that it becomes possible to strip the
link-layer header without passing the packet up the network stack.

Some dumb NBPs (e.g. emBoot's winBoot/i) never call PXENV_UNDI_ISR
with FuncFlag=PXENV_UNDI_ISR_START; they just sit in a tight polling
loop merrily violating the PXE spec with repeated calls to
PXENV_UNDI_ISR_IN_PROCESS.  Force a extra calls to netdev_poll() to
cope with these out-of-spec clients.

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

fetch_string_setting() was subtracting one from the length of the
to-be-NUL-terminated buffer in order to obtain the length of the
unterminated buffer to be passed to fetch_setting().  This works
extremely well unless the length of the to-be-NUL-terminated buffer is
zero, at which point we end up giving fetch_setting() a buffer of
length -1UL, thereby inviting it to overwrite as much memory as it
wants...

The ProxyDHCPREQUEST is a unicast packet, so the first request will
almost always be lost due to not having the IP address in the ARP
cache.  If the minimum retry time is set to one second (as per commit
ff2b6a5), then ProxyDHCP will time out and give up before managing to
successfully transmit a request.

The DHCP timers need to be reworked anyway, so this mild hack is
acceptable for now.

New min_timeout and max_timeout fields in struct retry_timer allow
users of this timer to set their own desired minimum and maximum
timeouts, without being constrained to a single global minimum and
maximum. Users of the timer can still elect to use the default global
values by leaving the min_timeout and max_timeout fields as 0.

Allow initiator to verify target authentication using CHAP.

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

(D'oh)

WinPE seems to have a bug that causes it to always use the TFTP server
IP address and filename from the ProxyDHCPACK packet, even if the
ProxyDHCPACK packet doesn't exist.  This causes it to end up
attempting to fetch a file such as

  tftp://0.0.0.0/bootmgr.exe

If we don't have a ProxyDHCPACK to use, we pretend that it was a copy
of the DHCPACK packet.  This works around the problem, and hopefully
won't surprise any NBPs.

Altiris erroneously cares about the ordering of DHCP options, and will
get confused if we don't construct them in the order it expects.

This is observed (so far) only when attempting to deploy 64-bit Win2k3.