david/ipxe
david
/
ipxe
Archived
1
0
Fork 0
Commit Graph

10 Commits

Author SHA1 Message Date
Michael Brown b6ee89ffb5 [legal] Relicense files under GPL2_OR_LATER_OR_UBDL
Relicense files for which I am the sole author (as identified by
util/relicense.pl).

Signed-off-by: Michael Brown <mcb30@ipxe.org>
2015-03-02 14:17:31 +00:00
Michael Brown 2cb95c9028 [efi] Make our virtual file system case insensitive
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-27 03:13:43 +01:00
Michael Brown ec7c331ca3 [efi] Dump details of any calls to our dummy block and disk I/O protocols
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-22 14:57:15 +01:00
Michael Brown 3b42ed477f [efi] Provide centralised definitions of commonly-used GUIDs
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-08-05 23:08:32 +01:00
Michael Brown 16d99cc8ef [efi] Dump existing openers when we are unable to open a protocol
Dump the existing openers of a protocol whenever we are unable to open
a protocol using attributes of BY_DEVICE, EXCLUSIVE, or
BY_CHILD_CONTROLLER.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-07-31 12:50:14 +01:00
Michael Brown 4a480f1d15 [efi] Avoid unnecessarily passing pointers to EFI_HANDLEs
efi_file_install() and efi_download_install() are both used to install
onto existing handles.  There is therefore no need to allow for each
of their calls to InstallMultipleProtocolInterfaces() to create a new
handle.

By passing the handle directly (rather than a pointer to the handle),
we avoid potential confusion (and erroneous debug message colours).

Signed-off-by: Michael Brown <mcb30@ipxe.org>
2014-07-31 12:50:09 +01:00
Michael Brown 8a380987c1 [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>
2014-07-14 16:30:19 +01:00
Michael Brown 54409583e2 [efi] Perform meaningful error code conversions
Exploit the redefinition of iPXE error codes to include a "platform
error code" to allow for meaningful conversion of EFI_STATUS values to
iPXE errors and vice versa.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
2013-04-19 13:34:19 +01:00
Michael Brown 1920aa4376 [efi] Provide efi_guid_ntoa() for printing EFI GUIDs
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2013-03-20 15:25:16 +00:00
Michael Brown fc87adb46c [efi] Expose downloaded images via EFI_SIMPLE_FILE_SYSTEM_PROTOCOL
Expose iPXE's images as a UEFI file system, allowing the booted image
to access all images downloaded by iPXE.

This functionality is complementary to the custom iPXE download
protocol.  The iPXE download protocol allows a booted image to utilise
iPXE to download arbitrary URIs, but requires the booted image to
specifically support the custom iPXE download protocol.  The new
functionality limits the booted image to accessing only files that
were already downloaded by iPXE (e.g. as part of a script), but can
work with any generic UEFI image (e.g. the UEFI shell).  Both
protocols are provided simultaneously, and are attached to the SNP
device handle.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
2013-03-13 22:42:16 +00:00