summaryrefslogtreecommitdiffstats
path: root/src/interface
Commit message (Collapse)AuthorAgeFilesLines
* [vmbus] Do not expect version in version_responseRoman Kagan2018-07-081-8/+2Star
| | | | | | | | | | | | | | | | | | The definition of version_response channel message in Linux doesn't include version field, so the upcoming VMBus implementation in QEMU doesn't set it either. Neither Windows nor Linux had any problem with this. The check against this field is redundant because the message is the response to initiate_contact message containing the specific version requested, so the response with version_supported=true is unambiguous. Drop this check and don't rely on the field to be present in the message. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Exclude link-layer header length from MaxPacketSizeRob Taglang2018-07-071-1/+1
| | | | | Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Do not raise TPL within EFI_DRIVER_BINDING_PROTOCOL.Supported()Michael Brown2018-03-261-7/+0Star
| | | | | | | | | | | | When booting some versions of the UEFI shell, our driver binding protocol's Supported() entry point is called at TPL_NOTIFY for no discernible reason. Attempting to raise to TPL_CALLBACK triggers an immediate assertion failure in the firmware. Since our Supported() method can run at any TPL, fix by simply not attempting to raise the TPL within this method. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Release SNP devices before starting SAN boot imageMichael Brown2018-03-261-0/+4
| | | | | | | | Release SNP devices to allow the SAN booted image to use our EFI_SIMPLE_NETWORK_PROTOCOL instance, and to ensure that the image is started at TPL_APPLICATION. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Raise TPL within EFI_DRIVER_BINDING_PROTOCOL entry pointsMichael Brown2018-03-151-0/+19
| | | | | Debugged-by: Rob Taglang <rob@privatemachines.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Drop to TPL_APPLICATION when gathering entropyMichael Brown2018-03-121-0/+6
| | | | | | | | | | | | | | | Commit c89a446 ("[efi] Run at TPL_CALLBACK to protect against UEFI timers") introduced a regression in the EFI entropy gathering code. When the EFI_RNG_PROTOCOL is not present, we fall back to using timer interrupts (as for the BIOS build). Since timer interrupts are disabled at TPL_CALLBACK, WaitForEvent() fails and no entropy can be gathered. Fix by dropping to TPL_APPLICATION while entropy gathering is enabled. Reported-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Tested-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Raise TPL within EFI_USB_IO_PROTOCOL entry pointsMichael Brown2018-02-201-6/+41
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Raise TPL within EFI_SIMPLE_NETWORK_PROTOCOL entry pointsMichael Brown2018-02-201-12/+81
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Run at TPL_CALLBACK to protect against UEFI timersMichael Brown2018-02-203-52/+49Star
| | | | | | | | | | | | | | | | | | | As noted in the comments, UEFI manages to combines the all of the worst aspects of both a polling design (inefficiency and inability to sleep until something interesting happens) and of an interrupt-driven design (the complexity of code that could be preempted at any time, thanks to UEFI timers). This causes problems in particular for UEFI USB keyboards: the keyboard driver calls UsbAsyncInterruptTransfer() to set up a periodic timer which is used to poll the USB bus. This poll may interrupt a critical section within iPXE, typically resulting in list corruption and either a hang or reboot. Work around this problem by mirroring the BIOS design, in which we run with interrupts disabled almost all of the time. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xen] Skip probing of any unsupported device typesMichael Brown2017-12-281-18/+21
| | | | | | | | | | | | Xen 4.4 includes the device "device/suspend/event-channel" which does not have a "backend" key. This currently causes the entire XenBus device tree probe to fail. Fix by skipping probe attempts for device types for which there is no iPXE driver. Debugged-by: Eytan Heidingsfeld <eytanh@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Inhibit our driver Start() method during disconnection attemptsMichael Brown2017-09-221-0/+16
| | | | | | | | | | | | | | | | | | Some HP BIOSes (observed with a Z840) seem to attempt to connect our drivers in the middle of our call to DisconnectController(). The precise chain of events is unclear, but the symptom is that we see several calls to our Supported() and Start() methods, followed by a system lock-up. Work around this dubious BIOS behaviour by explicitly failing calls to our Start() method while we are in the middle of attempting to disconnect drivers. Reported-by: Jordan Wright <jordan.m.wright@disney.com> Debugged-by: Adrian Lucrèce Céleste <adrianlucrececeleste@airmail.cc> Debugged-by: Christian Nilsson <nikize@gmail.com> Tested-by: Jordan Wright <jordan.m.wright@disney.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Continue to connect remaining handles after connection errorsMichael Brown2017-09-131-3/+5
| | | | | | | | | | | | Some UEFI BIOSes will deliberately break the implementation of ConnectController() to return errors for devices that have been "disabled" via the BIOS setup screen. (As an added bonus, such BIOSes may return garbage EFI_STATUS values such as 0xff.) Work around these broken UEFI BIOSes by ignoring failures and continuing to attempt to connect any remaining handles. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Match behaviour of SnpDxe for truncated received packetsMichael Brown2017-09-071-13/+9Star
| | | | | | | | | | | | | The UEFI specification does not state whether or not a return value of EFI_BUFFER_TOO_SMALL from the SNP Receive() method should follow the usual EFI API behaviour of allowing the caller to retry the request with an increased buffer size. Examination of the SnpDxe driver in EDK2 suggests that Receive() will just return the truncated packet (complete with any requested link-layer header fields), so match this behaviour. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Check buffer length for packets retrieved via our SNP protocolMichael Brown2017-09-071-3/+14
| | | | | | | | | | | | We do not currently check the length of the caller's buffer for received packets. This creates a potential buffer overrun when iPXE is being used via the SNP or UNDI protocols. Fix by checking the buffer length and correctly returning the required length and an EFI_BUFFER_TOO_SMALL error. Reported-by: Paul McMillan <paul.mcmillan@oracle.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide access to ACPI tablesMichael Brown2017-05-231-0/+56
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Prevent EFI code from being linked in to non-EFI buildsMichael Brown2017-05-191-2/+8
| | | | | | | | Ensure that efi_systab is an undefined symbol in non-EFI builds. In particular, this prevents users from incorrectly enabling IMAGE_EFI in a BIOS build of iPXE. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Standardise PCI debug messagesMichael Brown2017-05-011-29/+31
| | | | | | | | | | | | Use the PCI bus:dev.fn address in debug messages, falling back to the EFI handle name only if we do not yet have enough information to determine the bus:dev.fn address. Include the vendor and device IDs in debug messages when no suitable driver is found, to match the diagnostics available in a BIOS environment. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [hyperv] Cope with Windows Server 2016 enlightenmentsMichael Brown2017-04-281-4/+129
| | | | | | | | | | | | | | | | | | | | | | | An "enlightened" external bootloader (such as Windows Server 2016's winload.exe) may take ownership of the Hyper-V connection before all INT 13 operations have been completed. When this happens, all VMBus devices are implicitly closed and we are left with a non-functional network connection. Detect when our Hyper-V connection has been lost (by checking the SynIC message page MSR). Reclaim ownership of the Hyper-V connection and reestablish any VMBus devices, without disrupting any existing iPXE state (such as IPv4 settings attached to the network device). Windows Server 2016 will not cleanly take ownership of an active Hyper-V connection. Experimentation shows that we can quiesce by resetting only the SynIC message page MSR; this results in a successful SAN boot (on a Windows 2012 R2 physical host). Choose to quiesce by resetting (almost) all MSRs, in the hope that this will be more robust against corner cases such as a stray synthetic interrupt occurring during the handover. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [block] Provide sandev_read() and sandev_write() as global symbolsMichael Brown2017-04-261-9/+8Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [block] Allow use of a non-default EFI SAN boot filenameMichael Brown2017-04-121-6/+16
| | | | | | | | | | | | | | | | | | | | | | | Some older operating systems (e.g. RHEL6) use a non-default filename on the root disk and rely on setting an EFI variable to point to the bootloader. This does not work when performing a SAN boot on a machine where the EFI variable is not present. Fix by allowing a non-default filename to be specified via the "sanboot --filename" option or the "san-filename" setting. For example: sanboot --filename \efi\redhat\grub.efi \ iscsi:192.168.0.1::::iqn.2010-04.org.ipxe.demo:rhel6 or option ipxe.san-filename code 188 = string; option ipxe.san-filename "\\efi\\redhat\\grub.efi"; option root-path "iscsi:192.168.0.1::::iqn.2010-04.org.ipxe.demo:rhel6"; Originally-implemented-by: Vishvananda Ishaya Abrams <vish.ishaya@oracle.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Fix typo in efi_acpi_table_protocol_guidMichael Brown2017-04-101-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [block] Describe all SAN devices via ACPI tablesMichael Brown2017-03-281-64/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Describe all SAN devices via ACPI tables such as the iBFT. For tables that can describe only a single device (i.e. the aBFT and sBFT), one table is installed per device. For multi-device tables (i.e. the iBFT), all devices are described in a single table. An underlying SAN device connection may be closed at the time that we need to construct an ACPI table. We therefore introduce the concept of an "ACPI descriptor" which enables the SAN boot code to maintain an opaque pointer to the underlying object, and an "ACPI model" which can build tables from a list of such descriptors. This separates the lifecycles of ACPI descriptions from the lifecycles of the block device interfaces, and allows for construction of the ACPI tables even if the block device interface has been closed. For a multipath SAN device, iPXE will wait until sufficient information is available to describe all devices but will not wait for all paths to connect successfully. For example: with a multipath iSCSI boot iPXE will wait until at least one path has become available and name resolution has completed on all other paths. We do this since the iBFT has to include IP addresses rather than DNS names. We will commence booting without waiting for the inactive paths to either become available or close; this avoids unnecessary boot delays. Note that the Linux kernel will refuse to accept an iBFT with more than two NIC or target structures. We therefore describe only the NICs that are actually required in order to reach the described targets. Any iBFT with at most two targets is therefore guaranteed to describe at most two NICs. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [block] Add basic multipath supportMichael Brown2017-03-261-6/+19
| | | | | | | | | | | Add basic support for multipath block devices. The "sanboot" and "sanhook" commands now accept a list of SAN URIs. We open all URIs concurrently. The first connection to become available for issuing block device commands is marked as the active path and used for all subsequent commands; all other connections are then closed. Whenever the active path fails, we reopen all URIs and repeat the process. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xen] Use standard calling pattern for asprintf()Michael Brown2017-03-221-2/+1Star
| | | | | | | | Our asprintf() implementation guarantees that strp will be NULL on allocation failure, but this is not standard behaviour. Detect errors by checking for a negative return value instead of a NULL pointer. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [hyperv] Fix resource leaks on error pathMichael Brown2017-03-211-5/+11
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide ACPI table description for SAN devicesMichael Brown2017-03-131-0/+69
| | | | | | | | | Provide a basic proof of concept ACPI table description (e.g. iBFT for iSCSI) for SAN devices in a UEFI environment, using a control flow that is functionally identical to that used in a BIOS environment. Originally-implemented-by: Vishvananda Ishaya Abrams <vish.ishaya@oracle.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add EFI_ACPI_TABLE_PROTOCOL header and GUID definitionMichael Brown2017-03-102-0/+7
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Refactor to use centralised SAN device abstractionMichael Brown2017-03-071-650/+161Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [block] Centralise "san-drive" settingMichael Brown2017-03-071-1/+0Star
| | | | | | | | | | | | The concept of the SAN drive number is meaningful only in a BIOS environment, where it represents the INT13 drive number (0x80 for the first hard disk). We retain this concept in a UEFI environment to allow for a simple way for iPXE commands to refer to SAN drives. Centralise the concept of the default drive number, since it is shared between all supported environments. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [time] Allow timer to be selected at runtimeMichael Brown2017-01-262-22/+26
| | | | | | | | | | | | | | | | | | | | | | Allow the active timer (providing udelay() and currticks()) to be selected at runtime based on probing during the INIT_EARLY stage of initialisation. TICKS_PER_SEC is now a fixed compile-time constant for all builds, and is independent of the underlying clock tick rate. We choose the value 1024 to allow multiplications and divisions on seconds to be converted to bit shifts. TICKS_PER_MS is defined as 1, allowing multiplications and divisions on milliseconds to be omitted entirely. The 2% inaccuracy in this definition is negligible when using the standard BIOS timer (running at around 18.2Hz). TIMER_RDTSC now checks for a constant TSC before claiming to be a usable timer. (This timer can be tested in KVM via the command-line option "-cpu host,+invtsc".) Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [hyperv] Ignore unsolicited VMBus messagesMichael Brown2017-01-241-39/+43
| | | | | | | | | | | In some high-end Azure instances (e.g. NC6) we may receive an unsolicited VMBUS_OFFER_CHANNEL message for a PCIe pass-through device some time after completing the bus enumeration. This currently causes apparently random failures due to unexpected VMBus message types. Fix by ignoring any unsolicited VMBus messages. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Work around temporal anomaly encountered during ExitBootServices()Michael Brown2016-12-072-0/+35
| | | | | | | | | | | | | | | | | | | | | | | | EFI provides no clean way for device drivers to shut down in preparation for handover to a booted operating system. The platform firmware simply doesn't bother to call the drivers' Stop() methods. Instead, drivers must register an EVT_SIGNAL_EXIT_BOOT_SERVICES event to be signalled when ExitBootServices() is called, and clean up without any reference to the EFI driver model. Unfortunately, all timers silently stop working when ExitBootServices() is called. Even more unfortunately, and for no discernible reason, this happens before any EVT_SIGNAL_EXIT_BOOT_SERVICES events are signalled. The net effect of this entertaining design choice is that any timeout loops on the shutdown path (e.g. for gracefully closing outstanding TCP connections) may wait indefinitely. There is no way to report failure from currticks(), since the API lazily assumes that the host system continues to travel through time in the usual direction. Work around EFI's violation of this assumption by falling back to a simple free-running monotonic counter. Debugged-by: Maor Dickman <maord@mellanox.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add basic EFI SAN booting capabilityMichael Brown2016-11-171-0/+1062
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add EFI_BLOCK_IO2_PROTOCOL header and GUID definitionMichael Brown2016-10-172-0/+7
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [hyperv] Use instance UUID in device nameMichael Brown2016-07-261-1/+5
| | | | | | | | | | The Windows drivers for VMBus devices are enumerated using the instance UUID rather than the channel number. Include the instance UUID within the iPXE device name to allow an iPXE network device to be more easily associated with the corresponding Windows network device when debugging. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Install the HII config access protocol on a child of the SNP handleLaszlo Ersek2016-07-081-4/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In edk2, there are several drivers that associate HII forms (and corresponding config access protocol instances) with each individual network device. (In this context, "network device" means the EFI handle on which the SNP protocol is installed, and on which the device path ending with the MAC() node is installed also.) Such edk2 drivers are, for example: Ip4Dxe, HttpBootDxe, VlanConfigDxe. In UEFI, any given handle can carry at most one instance of a specific protocol (see e.g. the specification of the InstallProtocolInterface() boot service). This implies that the class of drivers mentioned above can't install their EFI_HII_CONFIG_ACCESS_PROTOCOL instances on the SNP handle directly -- they would conflict with each other. Accordingly, each of those edk2 drivers creates a "private" child handle under the SNP handle, and installs its config access protocol (and corresponding HII package list) on its child handle. The device path for the child handle is traditionally derived by appending a Hardware Vendor Device Path node after the MAC() node. The VenHw() nodes in question consist of a GUID (by definition), and no trailing data (by choice). The purpose of these VenHw() nodes is only that all the child nodes can be uniquely identified by device path. At the moment iPXE does not follow this pattern. It doesn't run into a conflict when it installs its EFI_HII_CONFIG_ACCESS_PROTOCOL directly on the SNP handle, but that's only because iPXE is the sole driver not following the pattern. This behavior seems risky (one might call it a "latent bug"); better align iPXE with the edk2 custom. Cc: Michael Brown <mcb30@ipxe.org> Cc: Gary Lin <glin@suse.com> Cc: Ladi Prosek <lprosek@redhat.com> Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/13494/focus=13532 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ladi Prosek <lprosek@redhat.com> Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Fix uninitialised data in HII IFR structuresMichael Brown2016-06-291-0/+1
| | | | | | | | | | | | | | The HII IFR structures are allocated via realloc() rather than zalloc(), and so are not automatically zeroed. This results in the presence of uninitialised and invalid data, causing crashes elsewhere in the UEFI firmware. Fix by explicitly zeroing the newly allocated portion of any IFR structure in efi_ifr_op(). Debugged-by: Laszlo Ersek <lersek@redhat.com> Debugged-by: Gary Lin <glin@suse.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Do not copy garbage bytes into SNP device path MAC addressMichael Brown2016-06-221-1/+1
| | | | | | | | | | | | | | | | | | | | The SNP device path includes the network device's MAC address within the MAC_ADDR_DEVICE_PATH.MacAddress field. We check that the link-layer address will fit within this field, and then perform the copy using the length of the destination buffer. At 32 bytes, the MacAddress field is actually larger than the current maximum iPXE link-layer address. The copy therefore overflows the source buffer, resulting in trailing garbage bytes being appended to the device path's MacAddress. This is invisible in debug messages, since the DevicePathToText protocol will render only the length implied by the interface type. Fix by copying only the actual length of the link-layer address (which we have already verified will not overflow the destination buffer). Debugged-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Report failures to stop the EFI timer tick eventMichael Brown2016-06-201-2/+16
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Include VLAN in SNP device path if applicableMichael Brown2016-06-181-2/+15
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Support systems with multiple PCI root bridgesMichael Brown2016-06-092-20/+121
| | | | | | | | | Extend the 16-bit PCI bus:dev.fn address to a 32-bit seg:bus:dev.fn address, assuming a segment value of zero in contexts where multiple segments are unsupported by the underlying data structures (e.g. in the iBFT or BOFM tables). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Expose DHCP packets via the Apple NetBoot protocolMichael Brown2016-05-293-3/+98
| | | | | | | | Mac OS X uses non-standard EFI protocols to obtain the DHCP packets from the UEFI firmware. Originally-implemented-by: Michael Kuron <m.kuron@gmx.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Generalise EFI entropy generation to non-x86 CPUsMichael Brown2016-05-041-0/+223
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Use a timer event to generate the currticks() timerMichael Brown2016-05-041-50/+68
| | | | | | | | | | | | | | We currently use the EFI_CPU_ARCH_PROTOCOL's GetTimerValue() method to generate the currticks() timer, calibrated against a 1ms delay from the boot services Stall() method. This does not work on ARM platforms, where GetTimerValue() is an empty stub which just returns EFI_UNSUPPORTED. Fix by instead creating a periodic timer event, and using this event to increment a current tick counter. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Work around broken EFI HII specificationMichael Brown2016-04-121-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The EFI_HII_CONFIG_ACCESS_PROTOCOL's ExtractConfig() method is passed a request string which includes the parameters being queried plus an apparently meaningless blob of information (the ConfigHdr), and is expected to include this same meaningless blob of information in the results string. Neither the specification nor the existing EDK2 code (including the nominal reference implementation in the DriverSampleDxe driver) provide any reason for the existence of this meaningless blob of information. It appears to be consumed in its entirety by the EFI_HII_CONFIG_ROUTING_PROTOCOL, and to contain zero bits of information by the time it reaches an EFI_HII_CONFIG_ACCESS_PROTOCOL instance. It would potentially allow for multiple configuration data sets to be handled by a single EFI_HII_CONFIG_ACCESS_PROTOCOL instance, in a style alien to the rest of the UEFI specification (which implicitly assumes that the instance pointer is always sufficient to uniquely identify the instance). iPXE currently handles this by simply copying the ConfigHdr from the request string to the results string, and otherwise ignoring it. This approach is also used by some code in EDK2, such as OVMF's PlatformDxe driver. As of EDK2 commit 8a45f80 ("MdeModulePkg: Make HII configuration settings available to OS runtime"), this causes an assertion failure inside EDK2. The failure arises when iPXE is handled a NULL request string, and responds (as per the specification) with a results string including all settings. Since there is no meaningless blob to copy from the request string, there is no corresponding meaningless blob in the results string. This now causes an assertion failure in HiiDatabaseDxe's HiiConfigRoutingExportConfig(). The same failure does not affect the OVMF PlatformDxe driver, which simply passes the request string to the HII BlockToConfig() utility function. The BlockToConfig() function returns EFI_INVALID_PARAMETER when passed a null request string, and PlatformDxe propagates this error directly to the caller. Fix by matching the behaviour of OVMF's PlatformDxe driver: explicitly return EFI_INVALID_PARAMETER if the request string is NULL or empty. This violates the specification (insofar as it is feasible to determine what the specification actually requires), but causes correct behaviour with the EDK2 codebase. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Move architecture-independent EFI prefixes to interface/efiMichael Brown2016-03-172-0/+182
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [hyperv] Use generic set_bit() functionMichael Brown2016-03-161-2/+3
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide access to files stored on EFI filesystemsMichael Brown2016-03-141-0/+573
| | | | | | | | | | | | | | | | | | | | | | | | | | Provide access to local files via the "file://" URI scheme. There are three syntaxes: - An opaque URI with a relative path (e.g. "file:script.ipxe"). This will be interpreted as a path relative to the iPXE binary. - A hierarchical URI with a non-network absolute path (e.g. "file:/boot/script.ipxe"). This will be interpreted as a path relative to the root of the filesystem from which the iPXE binary was loaded. - A hierarchical URI with a network path in which the authority is a volume label (e.g. "file://bootdisk/script.ipxe"). This will be interpreted as a path relative to the root of the filesystem with the specified volume label. Note that the potentially desirable shell mappings (e.g. "fs0:" and "blk0:") are concepts internal to the UEFI shell binary, and do not seem to be exposed in any way to external executables. The old EFI_SHELL_PROTOCOL (which did provide access to these mappings) is no longer installed by current versions of the UEFI shell. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Work around broken GetFontInfo() implementationsMichael Brown2016-03-101-16/+38
| | | | | | | | | | Several UEFI platforms are known to return EFI_NOT_FOUND when asked to retrieve the system default font information via GetFontInfo(). Work around these broken platforms by iterating over the glyphs to find the maximum height used by a printable character. Originally-fixed-by: Jonathan Dieter <jdieter@lesbg.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add missing definitions for function key scancodesMichael Brown2016-02-121-0/+8
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-12-04 19:46:09 +0100