Some devices (e.g. the Atmel AT24C11) have no concept of a device
address; they respond to every device address and use this value as
the word address.  Some other devices use part of the device address
field to extend the word address field.

Generalise the i2c bit-bashing support to handle this by defining the
device address length and word address length as properties of an i2c
device.  The word address is assumed to overflow into the device
address field if the address used exceeds the width of the word
address field.

Also add a bus reset mechanism.  i2c chips don't usually have a reset
line, so rebooting the host will not clear any bizarre state that the
chip may be in.  We reset the bus by clocking SCL until we see SDA
high, at which point we know we can generate a start condition and
have it seen by all devices.  We then generate a stop condition to
leave the bus in a known state prior to use.

Finally, add some extra debugging messages to i2c_bit.c.

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.

The usefulness of DBGLVL_IO is limited by the fact that many cards
require large numbers of uninteresting I/O reads/writes at device
probe time, typically when driving a bit-bashing I2C/SPI bus to read
the MAC address.

This patch adds the DBG_DISABLE() and DBG_ENABLE() macros, which can
be used to temporarily disable and re-enable selected debug levels.
Note that debug levels must still be enabled in the build in order to
function at all: you can't use DBG_ENABLE(DBGLVL_IO) in an object
built with DEBUG=object:1 and expect it to do anything.

[] are shell metacharacters, and they can get confused by files in the
local directory.

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

?= 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>

Reported working by Martin Kreiner <m.kreiner@levigo.de>

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.

Our INT 15,e820 code was setting %es=%ss (as part of the "look ahead
in the memory map" logic), but failing to restore %es afterwards.
This is a serious bug, but wasn't affecting many platforms because
almost all callers seem to set %es=%ss anyway.

Use as "call dump_regs" from any real-mode code within .text16.
Should preserve all registers and flags.

Use individual page mappings rather than a single whole-region
mapping, to avoid the waste of memory that occurs due to the
constraint that each mapped block must be aligned on its own size.

Some BIOSes require us to pass in not only the continuation value (in
%ebx) as returned by the previous call to INT 15,e820 but also the
unmodified buffer (at %es:%di) as returned by the previous call to INT
15,e820.  Apparently, someone thought it would be a worthwhile
optimisation to fill in only the low dword of the "length" field and
the low byte of the "type field", assuming that the buffer would
remain unaltered from the previous call.

This problem was being triggered by the "peek ahead" logic in
get_mangled_e820(), which would read the next entry into a temporary
buffer in order to be able to guarantee terminating the map with
%ebx=0 rather than CF=1.  (Terminating with CF=1 upsets some Windows
flavours, despite being documented legal behaviour.)

Work around this problem by always fetching directly into our e820
cache; that way we can guarantee that the underlying call always sees
the previous buffer contents (and the same buffer address).

We were accidentally allocating only half the required amount of
memory (given the alignment method) for the firmware buffer, leading
to conflicts between the firmware buffer and gPXE code/data segments.

We were accidentally allocating only half the required amount of
memory (given the alignment method) for the firmware buffer, leading
to conflicts between the firmware buffer and gPXE code/data segments.

We seem to be having issues with various E820 memory maps.  These
problems are often difficult to reproduce, requiring access to the
specific system exhibiting the problem.

Add a facility for hooking in a fake E820 map generator, using an
arbitrary map defined in a C array, solely in order to be able to test
the map-mangling code against arbitrary E820 maps.

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.

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