[autoboot] Allow autoboot device to be identified by link-layer address

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Identify autoboot device by MAC address when chainloading

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Attempt to start only drivers claiming support for a device

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Rewrite SNP NIC driver

Rewrite the SNP NIC driver to use non-blocking and deferrable
transmissions, to provide link status detection, to provide
information about the underlying (PCI) hardware device, and to avoid
unnecessary I/O buffer allocations during receive polling.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Include SNP NIC driver within the all-drivers target

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[crypto] Add support for iPAddress subject alternative names

Originally-implemented-by: Jarrod Johnson <jarrod.b.johnson@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[crypto] Fix debug message

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[netdevice] Reset network device index when last device is unregistered

When functioning as an EFI driver, drivers can be disconnected and
reconnected multiple times (e.g. via the EFI shell "connect" command,
or by running an executable such as ipxe.efi which will temporarily
disconnect existing drivers).

Minimise surprise by resetting the network device index to zero
whenever the last device is unregistered.  This is not foolproof, but
it does handle the common case of having all devices unregistered and
then reregistered in the original order.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Update EDK2 headers

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Install our own disk I/O protocol and claim exclusive use of it

The EFI FAT filesystem driver has a bug: if a block device contains no
FAT filesystem but does have an EFI_SIMPLE_FILE_SYSTEM_PROTOCOL
instance, the FAT driver will assume that it must have previously
installed the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.  This causes the FAT
driver to claim control of our device, and to refuse to stop driving
it, which prevents us from later uninstalling correctly.

Work around this bug by opening the disk I/O protocol ourselves,
thereby preventing the FAT driver from opening it.

Note that the alternative approach of opening the block I/O protocol
(and thereby in theory preventing DiskIo from attaching to the block
I/O protocol) causes an endless loop of calls to our DRIVER_STOP
method when starting the EFI shell.  I have no idea why this is.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Allow for interception of boot services calls by loaded image

When building with DEBUG=efi_wrap, print details of calls made by the
loaded image to selected boot services functions.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Print well-known GUIDs by name in debug messages

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Include EFI_CONSOLE_CONTROL_PROTOCOL header

The EFI_CONSOLE_CONTROL_PROTOCOL does not exist in the current UEFI
specification, but is required to enable text output on some older EFI
1.10 implementations (observed on an old iMac).

The header is not present in any of the standard include directories,
but can still be found in the EDK2 codebase as part of
EdkCompatibilityPkg.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Use EFI_CONSOLE_CONTROL_PROTOCOL to set text mode if available

On some older EFI 1.10 implementations (observed with an old iMac), we
must use the (now obsolete) EFI_CONSOLE_CONTROL_PROTOCOL to switch the
console into text mode.

Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[ioapi] Fail ioremap() when attempting to map a zero bus address

When a 32-bit iPXE binary is running on a system which allocates PCI
memory BARs above 4GB, our PCI subsystem will return the base address
for any such BARs as zero (with a warning message if DEBUG=pci is
enabled).  Currently, ioremap() will happily map an address pointing
to the start of physical memory, providing no sensible indication of
failure.

Fix by always returning NULL if we are asked to ioremap() a zero bus
address.

With a totally flat memory model (e.g. under EFI), this provides an
accurate failure indication since no PCI peripheral will be mapped to
the zero bus address.

With the librm memory model, there is the possibility of a spurious
NULL return from ioremap() if the bus address happens to be equal to
virt_offset.  Under the current virtual memory map, the NULL virtual
address will always be the start of .textdata, and so this problem
cannot occur; a NULL return from ioremap() will always be an accurate
failure indication.

Debugged-by: Anton D. Kachalov <mouse@yandex-team.ru>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[intel] Check for ioremap() failures

Debugged-by: Anton D. Kachalov <mouse@yandex-team.ru>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[realtek] Check for ioremap() failures

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[vmxnet3] Check for ioremap() failures

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[skel] Check for ioremap() failures

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[myson] Check for ioremap() failures

Signed-off-by: Michael Brown <mcb30@ipxe.org>