[debug] Allow debug message colours to be customised via DBGCOL=...

When multiple iPXE binaries are running concurrently (e.g. in the case
of undionly.kpxe using an underlying iPXE driver via the UNDI
interface) it would be helpful to be able to visually distinguish
debug messages from each binary.

Allow the range of debug colours used to be customised via the
DBGCOL=...  build parameter.  For example:

  # Restrict to colours 31-33 (red, green, yellow)
  make DBGCOL=31-33

  # Restrict to colours 34-36 (blue, magenta, cyan)
  make DBGCOL=34-36

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Expose build timestamp, build name, and product names

Expose the build timestamp (measured in seconds since the Epoch) and
the build name (e.g. "rtl8139.rom" or "ipxe.efi"), and provide the
product name and product short name in a single centralised location.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Allow device paths to be easily included in debug messages

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Provide a meaningful EFI SNP device name

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Restructure EFI driver model

Provide a single instance of EFI_DRIVER_BINDING_PROTOCOL (attached to
our image handle); this matches the expectations scattered throughout
the EFI specification.

Open the underlying hardware device using EFI_OPEN_PROTOCOL_BY_DRIVER
and EFI_OPEN_PROTOCOL_EXCLUSIVE, to prevent other drivers from
attaching to the same device.

Do not automatically connect to devices when being loaded as a driver;
leave this task to the platform firmware (or to the user, if loading
directly from the EFI shell).

When running as an application, forcibly disconnect any existing
drivers from devices that we want to control, and reconnect them on
exit.

Provide a meaningful driver version number (based on the build
timestamp), to allow platform firmware to automatically load newer
versions of iPXE drivers if multiple drivers are present.

Include device paths within debug messages where possible, to aid in
debugging.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Fix erroneous object name in version object

Commit 8290a95 ("[build] Expose build timestamp, build name, and
product names") introduced a regression in the build process which
resulted in broken final binaries which had names based on object
files (e.g. "undionly.kpxe" or "intel.rom") rather than on device IDs
(e.g. "8086100e.mrom").

The underlying problem is the -DOBJECT=<name> macro which is used to
generate the obj_<name> symbols used to select objects required for
the final binary.  The macro definition is derived from the initial
portion (up to the first dot) of the object being built.  In the case
of e.g. undionly.kpxe.version.o, this gives -DOBJECT=undionly.  This
results in undionly.kpxe.version.o claiming to be the "undionly"
object; the real "undionly" object will therefore never get dragged in
to the build.

Fix by renaming $(BIN)/%.version.o to $(BIN)/version.%.o, so that the
object is always built with -DOBJECT=version (as might be expected,
since it is built from core/version.c).

Final binaries which have names based on device IDs (such as
"8086100e.mrom") are not affected by this problem, since the object
name "8086100e" will not conflict with that of the underlying "intel"
object.

This problem was not detected by the per-commit smoke testing
procedure, which happens to use the binary bin/8086100e.mrom.

Reported-by: Christian Hesse <list@eworm.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Add yet another potential location for isolinux.bin

Reported-by: Martin Sofaru <ipxe@fhloston.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Allow network devices to be created on top of arbitrary SNP devices

Signed-off-by: Michael Brown <mcb30@ipxe.org>
Merge pull request #5 from ipxe/master

Merge latest changes from the upstream (ipxe:master)