[efi] Add definitions of GUIDs observed during Windows boot

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Dump details of any calls to our dummy block and disk I/O protocols

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[romprefix] Do not preserve unused register %di

Since some PnP BIOSes fail to set %es:di to point to the PnP signature
on entry, we identify a PnP BIOS by scanning through the top 64kB of
base memory looking for the PnP structure.  We therefore don't
actually use the values of %es:di provided to the initialisation entry
point, and so there is no need to preserve them.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Remove obsolete references to .zrom build targets

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Allow ISA ROMs to be built

The build process has for a long time assumed that every ROM is a PCI
ROM, and will always include the PCI header and PCI-related
functionality (such as checking the PCI BIOS version, including the
PCI bus:dev.fn address within the ROM product name string, etc.).

While real ISA cards are no longer in use, some virtualisation
environments (notably VirtualBox) have support only for ISA ROMs.
This can cause problems: in particular, VirtualBox will call our
initialisation entry point with random garbage in %ax, which we then
treat as the PCI bus:dev.fn address of the autoboot device: this
generally prevents the default boot sequence from using any network
devices.

Create .isarom and .pcirom prefixes which can be used to explicitly
specify the type of ROM to be created.  (Note that the .mrom prefix
always implies a PCI ROM, since the .mrom mechanism relies on
reconfiguring PCI BARs.)

Make .rom a magic prefix which will automatically select the
appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or
ISA_ROM() macro.  To maintain backwards compatibility, we default to
building a PCI ROM for anything which is not directly derived from a
PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom).

Add a selection of targets to "make everything" to ensure that the
(relatively obscure) ISA ROM build process is included within the
per-commit QA checks.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Avoid using embedded script in VirtualBox named configuration

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Avoid deleting config header files if build is interrupted

With extremely unlucky timing, it is possible to interrupt a build and
cause make to delete config/named.h (and possibly any local
configuration headers).

Mark config/named.h and all local configuration headers as .PRECIOUS
to prevent make from ever deleting them.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[prefix] Halt system without burning CPU if we cannot access the payload

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[prefix] Report both %esi and %ecx when opening payload fails

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[util] Use PCI length field to obtain length of individual images

Option::ROM currently uses the initialisation length field (single
byte at offset 0x02) to determine the length of a ROM image within a
multi-image ROM file.  For PCI ROM images with a code type other than
0, the initialisation length field may not be present.

Fix by using the PCI header's image length field instead.  Note that
this does not prevent us from correctly handling ISA ROMs, since ISA
ROMs do not support multiple images within a single ROM BAR anyway.

Inspired-by: Swift Geek <swiftgeek@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[mromprefix] Use PCI length field to obtain length of individual images

mromprefix.S currently uses the initialisation length field (single
byte at offset 0x02) to determine the length of a ROM image within a
multi-image ROM BAR.  For PCI ROM images with a code type other than
0, the initialisation length field may not be present.

Fix by using the PCI header's image length field instead.

Inspired-by: Swift Geek <swiftgeek@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[mromprefix] Allow for .mrom images larger than 128kB

The .mrom payload has a code type of 0xff and so the initialisation
length field (single byte at offset 0x02) does not need to be
present.  Use only the PCI header's image length field, which allows
the .mrom payload to be up to 32MB in size.

Inspired-by: Swift Geek <swiftgeek@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Show details of intercepted LoadImage() calls

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Make our virtual file system case insensitive

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Wrap any images loaded by our wrapped image

Propagate our modified EFI system table to any images loaded by the
image that we wrap, thereby allowing us to observe boot services calls
made by all subsequent EFI images.

Also show details of intercepted ExitBootServices() calls.  When
wrapping is used, exiting boot services will almost certainly fail,
but this at least allows us to see when it happens.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Use the SNP protocol instance to match the SNP chainloading device

Some systems will install a child of the SNP device and use this as
our loaded image's device handle, duplicating the installation of the
underlying SNP protocol onto the child device handle.  On such
systems, we want to end up driving the parent device (and
disconnecting any other drivers, such as MNP, which may be attached to
the parent device).

Fix by recording the SNP protocol instance at initialisation time, and
using this to match against device handles (rather than simply
comparing the handles themselves).

Reported-by: Jarrod Johnson <jarrod.b.johnson@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Avoid returning uninitialised data from PCI configuration space reads

Under UEFI, reads from PCI configuration space may fail.  If this
happens, we should return all-ones (which will mimic the behaviour of
an absent PCI device).

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Make EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL optional

Some UEFI systems (observed with a Hyper-V virtual machine) do not
provide EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.  Make this an optional
protocol (and fail any attempts to access PCI configuration space via
the root bridge if the protocol is missing).

Reported-by: Colin Blacker <Colin.Blacker@computerplanet.co.uk>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Allow for non-PCI snpnet devices

We currently require information about the underlying PCI device to
populate the snpnet device's name and description.  If the underlying
device is not a PCI device, this will fail and prevent the device from
being registered.

Fix by falling back to populating the device description with
information based on the EFI handle, if no PCI device information is
available.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Clean up all binary directories on "make [very]clean"

Allow a straightforward "make clean" or "make veryclean" to apply to
all binary directories (using the shell pattern "bin{,-*}").
Individual binary directories can be cleaned using e.g.

  make bin clean
  make bin-x86_64-efi clean

Reported-by: Robin Smidsrød <robin@smidsrod.no>
Signed-off-by: Michael Brown <mcb30@ipxe.org>