aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* [realtek] Update driver to use DMA APIMichael Brown2020-11-052-95/+127
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide DMA operations for EFI PCI devicesMichael Brown2020-11-053-0/+242
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [dma] Define a DMA API to allow for non-flat device address spacesMichael Brown2020-11-056-0/+517
| | | | | | | | | | | | | | | | | | | iPXE currently assumes that DMA-capable devices can directly address physical memory using host addresses. This assumption fails when using an IOMMU. Define an internal DMA API with two implementations: a "flat" implementation for use in legacy BIOS or other environments in which flat physical addressing is guaranteed to be used and all allocated physical addresses are guaranteed to be within a 32-bit address space, and an "operations-based" implementation for use in UEFI or other environments in which DMA mapping may require bus-specific handling. The purpose of the fully inlined "flat" implementation is to allow the trivial identity DMA mappings to be optimised out at build time, thereby avoiding an increase in code size for legacy BIOS builds. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [malloc] Rename malloc_dma() to malloc_phys()Michael Brown2020-11-0548-350/+350
| | | | | | | | | | | | The malloc_dma() function allocates memory with specified physical alignment, and is typically (though not exclusively) used to allocate memory for DMA. Rename to malloc_phys() to more closely match the functionality, and to create name space for functions that specifically allocate and map DMA-capable buffers. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Retain a long-lived reference to the EFI_PCI_IO_PROTOCOL instanceMichael Brown2020-11-044-49/+60
| | | | | | | | | | | | | | | Provide opened EFI PCI devices with access to the underlying EFI_PCI_IO_PROTOCOL instance, in order to facilitate the future use of the DMA mapping methods within the fast data path. Do not require the use of this stored EFI_PCI_IO_PROTOCOL instance for memory-mapped I/O (since the entire point of memory-mapped I/O as a concept is to avoid this kind of unnecessary complexity) or for slow-path PCI configuration space accesses (since these may be required for access to PCI bus:dev.fn addresses that do not correspond to a device bound via our driver binding protocol instance). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [realtek] Reset NIC when closing interface if using legacy modeMichael Brown2020-11-041-0/+4
| | | | | | | | | | | | | | The legacy transmit descriptor index is not reset by anything short of a full device reset. This can cause the legacy transmit ring to stall after closing and reopening the device, since the hardware and software indices will be out of sync. Fix by performing a reset after closing the interface. Do this only if operating in legacy mode, since in C+ mode the reset is not required and would undesirably clear additional state (such as the C+ command register itself). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Fall back to assuming identity mapping of MMIO address spaceMichael Brown2020-10-301-4/+2
| | | | | | | | | | | | | | Some UEFI systems (observed with a Supermicro X11SPG-TF motherboard) seem to fail to provide a valid ACPI address space descriptor for the MMIO address space associated with a PCI root bridge. If no valid descriptor can be found, fall back to assuming that the MMIO address space is identity mapped, thereby matching the behaviour prior to commit 27e886c ("[efi] Use address offset as reported by EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL"). Debugged-by: Tore Anderson <tore@fud.no> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Avoid dragging in USB subsystem via efi_usb_path()Michael Brown2020-10-302-18/+17
| | | | | | | | | | | | Commit 87e39a9c9 ("[efi] Split efi_usb_path() out to a separate function") unintentionally introduced an undefined symbol reference from efi_path.o to usb_depth(), causing the USB subsystem to become a dependency of all EFI builds. Fix by converting usb_depth() to a static inline function. Reported-by: Pico Mitchell <pico@randomapplications.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Fix memory copy length used in efi_nullify_name2()Michael Brown2020-10-271-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Nullify interfaces and leak memory on uninstallation failureMichael Brown2020-10-267-50/+737
| | | | | | | | | | | | | | | The UEFI specification allows uninstallation of a protocol interface to fail. There is no sensible way for code to react to this, since uninstallation is likely to be taking place on a code path that cannot itself fail (e.g. a code path that is itself a failure path). Where the protocol structure exists within a dynamically allocated block of memory, this leads to possible use-after-free bugs. Work around this unfortunate design choice by nullifying the protocol (i.e. overwriting the method pointers with no-ops) and leaking the memory containing the protocol structure. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow block devices to provide their own EFI device pathsMichael Brown2020-10-231-63/+25
| | | | | | | Use the device path constructed via efi_describe() for the installed EFI_BLOCK_IO_PROTOCOL device handle. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [infiniband] Allow SRP device to be described using an EFI device pathMichael Brown2020-10-234-33/+95
| | | | | | | | | The UEFI specification provides a partial definition of an Infiniband device path structure. Use this structure to construct what may be a plausible path containing at least some of the information required to identify an SRP target device. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [fcp] Allow Fibre Channel device to be described using an EFI device pathMichael Brown2020-10-224-8/+61
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [iscsi] Allow iSCSI device to be described using an EFI device pathMichael Brown2020-10-203-0/+75
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Show block device ACPI table contents only at DBGLVL_EXTRAMichael Brown2020-10-201-3/+3
| | | | | | | The ACPI table contents are typically large and are likely to cause any preceding error messages to scroll off-screen. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [aoe] Allow AoE device to be described using an EFI device pathMichael Brown2020-10-194-29/+82
| | | | | | | | | | | | | There is no standard defined for AoE device paths in the UEFI specification, and it seems unlikely that any standard will be adopted in future. Choose to construct an AoE device path using a concatenation of the network device path and a SATA device path, treating the AoE major and minor numbers as the HBA port number and port multiplier port number respectively. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide utility function to concatenate device pathsMichael Brown2020-10-192-0/+54
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Split efi_netdev_path() out to a separate functionMichael Brown2020-10-193-37/+71
| | | | | | | Provide efi_netdev_path() as a standalone function, to allow for reuse when constructing child device paths. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [http] Allow HTTP connection to be described using an EFI device pathMichael Brown2020-10-191-0/+15
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide efi_uri_path() to construct a URI device pathMichael Brown2020-10-192-0/+45
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usbblk] Allow USB block device to be described using an EFI device pathMichael Brown2020-10-161-0/+15
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Split efi_usb_path() out to a separate functionMichael Brown2020-10-164-54/+89
| | | | | | | Provide efi_usb_path() as a standalone function, to allow for reuse by the USB mass storage driver. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Define an interface operation to describe using an EFI device pathMichael Brown2020-10-162-0/+31
| | | | | | | Allow arbitrary objects to support describing themselves using an EFI device path. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Split device path functions out to efi_path.cMichael Brown2020-10-1614-54/+99
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide EFI_INTF_OP for EFI-only interface operationsMichael Brown2020-10-161-0/+7
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [interface] Allow for the definition of an unused interface operationMichael Brown2020-10-161-0/+15
| | | | | | | | | | | | | | Allow an interface operation to be declared as unused. This will perform full type-checking and compilation of the implementing method, without including any code in the resulting object (other than a NULL entry in the interface operations table). The intention is to provide a relatively clean way for interface operation methods to be omitted in builds for which the operation is not required (such as an operation to describe an object using an EFI device path, which would not be required in a non-EFI build). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [build] Provide a testable platform macro alongside -DPLATFORMMichael Brown2020-10-161-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ipv6] Reduce time spent waiting for router discoveryMichael Brown2020-10-141-0/+9
| | | | | | | | | | | Now that IPv6 is enabled by default for UEFI builds, it is important that iPXE does not delay unnecessarily in the (still relatively common) case of a network that lacks IPv6 routers. Apply the timeout values used for neighbour discovery to the router discovery process. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Enable NET_PROTO_IPV6 by defaultTore Anderson2020-10-142-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | IPv6 PXE was included in the UEFI specification over eight years ago, specifically in version 2.3 (Errata D). http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_3_D.pdf When iPXE is being chainloaded from a UEFI firmware performing a PXE boot in an IPv6 network, it is essential that iPXE supports IPv6 as well. I understand that the reason for NET_PROTO_IPV6 being disabled by default (in src/config/general.h) is that it would cause certain space-constrained build targets to become too large. However, this should not be an issue for EFI builds. It is also worth noting that RFC 6540 makes a clear recommendation that IPv6 support should not be considered optional. https://tools.ietf.org/html/rfc6540 Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Tore Anderson <tore@fud.no> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [lacp] Ignore (and do not echo) trailing padding on received packetsMichael Brown2020-10-141-0/+3
| | | | | | | | | | | | | The LACP responder reuses the received I/O buffer to construct the response LACP (or marker) packet. Any received padding will therefore be unintentionally included within the response. Truncate the received I/O buffer to the expected length (which is already defined in a way to allow for future protocol expansion) before reusing it to construct the response. Reported-by: Tore Anderson <tore@fud.no> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [lacp] Detect and ignore erroneously looped back LACP packetsMichael Brown2020-10-141-0/+8
| | | | | | | | | | | | | | | Some external drivers (observed with the UEFI NII driver provided by an HPE-branded Mellanox ConnectX-3 Pro) seem to cause LACP packets transmitted by iPXE to be looped back as received packets. Since iPXE's trivial LACP responder will send one response per received packet, this results in an immediate LACP packet storm. Detect looped back LACP packets (based on the received LACP actor MAC address), and refuse to respond to such packets. Reported-by: Tore Anderson <tore@fud.no> Tested-by: Tore Anderson <tore@fud.no> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Defer local download process until file has been openedMichael Brown2020-10-131-2/+5
| | | | | | | | | | | | | | | When iPXE is downloading a file from an EFI_FILE_PROTOCOL instance backed by an EFI_BLOCK_IO_PROTOCOL instance provided by the same iPXE binary (e.g. via a hooked SAN device), then it is possible for step() to be invoked as a result of the calls into the EFI_BLOCK_IO_PROTOCOL methods. This can potentially result in efi_local_step() being run prematurely, before the file has been opened and before the parent interface has been attached. Fix by deferring starting the download process until immediately prior to returning from efi_local_open(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usbblk] Add support for USB mass storage devicesMichael Brown2020-10-137-0/+1025
| | | | | | | | | | | | | | | | | | | | | | | | Some UEFI BIOSes (observed with at least the Insyde UEFI BIOS on a Microsoft Surface Go) provide a very broken version of the UsbMassStorageDxe driver that is incapable of binding to the standard EFI_USB_IO_PROTOCOL instances and instead relies on an undocumented proprietary protocol (with GUID c965c76a-d71e-4e66-ab06-c6230d528425) installed by the platform's custom version of UsbCoreDxe. The upshot is that USB mass storage devices become inaccessible once iPXE's native USB host controller drivers are loaded. One possible workaround is to load a known working version of UsbMassStorageDxe (e.g. from the EDK2 tree): this driver will correctly bind to the standard EFI_USB_IO_PROTOCOL instances exposed by iPXE. This workaround is ugly in practice, since it involves embedding UsbMassStorageDxe.efi into the iPXE binary and including an embedded script to perform the required "chain UsbMassStorageDxe.efi". Provide a native USB mass storage driver for iPXE, allowing USB mass storage devices to be exposed as iPXE SAN devices. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Move usbio driver to end of USB driver listMichael Brown2020-10-132-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | iPXE will often have multiple drivers available for a USB device. For example: some USB network devices will support both RNDIS and CDC-ECM, and any device may be consumed by the fallback "usbio" driver under UEFI in order to expose an EFI_USB_IO_PROTOCOL instance. The driver scoring mechanism is used to select a device configuration based on the availability of drivers for the interfaces exposed in each configuration. For the case of RNDIS versus CDC-ECM, this mechanism will always produce the correct result since RNDIS and CDC-ECM will not exist within the same configuration and so each configuration will receive a score based on the relevant driver. This guarantee does not hold for the "usbio" driver, which will match against any device. It is a surprising coincidence that the "usbio" driver seems to usually end up at the tail end of the USB drivers list, thereby resulting in the expected behaviour. Guarantee the expected behaviour by explicitly placing the "usbio" driver at the end of the USB drivers list. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Allow endpoints to be refilled to a specified upper limitMichael Brown2020-10-122-3/+17
| | | | | | | | | | | | For USB mass storage devices, we do not want to submit more bulk IN packets than are required for the inbound data, since this will waste memory. Allow an upper limit to be specified on each refill attempt. The endpoint will be refilled to the lower of this limit or the limit specified by usb_refill_init(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Allow device halt to be cleared independently of host controllerMichael Brown2020-10-122-14/+32
| | | | | | | | | | | | | | | | | | Closing and reopening a USB endpoint will clear any halt status recorded by the host controller, but may leave the endpoint halted at the device. This will cause the first packet submitted to the reopened endpoint to be lost, before the automatic stall recovery mechanism detects the halt and resets the endpoint. This is relatively harmless for USB network or HID devices, since the wire protocols will recover gracefully from dropped packets. Some protocols (e.g. for USB mass storage devices) assume zero packet loss and so would be adversely affected. Fix by allowing any device endpoint halt status to be cleared on a freshly opened endpoint. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Always enable recursion when calling ConnectController()Michael Brown2020-10-022-3/+3
| | | | | | | | There appears to be no reason for avoiding recursion when calling ConnectController(), and recursion provides the least surprising behaviour. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Connect controllers after loading an EFI driverMichael Brown2020-10-021-0/+11
| | | | | | | | | | | | iPXE is already capable of loading EFI drivers on demand (via e.g. "chain UsbMassStorageDxe.efi") but there is currently no way to trigger connection of the driver to any preexisting handles. Add an explicit call to (re)connect all drivers after successfully loading an image with a code type that indicates a boot services driver. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ncm] Treat a zero divisor as indicating no alignment requirementsMichael Brown2020-10-021-5/+8
| | | | | | | | | | | A zero divisor will currently lead to a 16-bit integer overflow when calculating the transmit padding, and a potential division by zero if assertions are enabled. Avoid these problems by treating a divisor value of zero as equivalent to a divisor value of one (i.e. no alignment requirements). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Fix reporting of USB supported languages arrayMichael Brown2020-10-012-11/+18
| | | | | | | The length as returned by UsbGetSupportedLanguages() should not include the length of the descriptor header itself. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Avoid integer underflow on malformed USB string descriptorsMichael Brown2020-10-011-0/+7
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Avoid integer underflow on malformed string descriptorsMichael Brown2020-10-011-1/+8
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow DEBUG=efi_wrap to be used independently of a loaded imageMichael Brown2020-10-012-25/+35
| | | | | | | | | | Allow temporary debugging code to call efi_wrap_systab() to obtain a pointer to the wrapper EFI system table. This can then be used to e.g. forcibly overwrite the boot services table pointer used by an already loaded and running UEFI driver, in order to trace calls made by that driver. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Disconnect controllers before uninstalling EFI_USB_IO_PROTOCOLMichael Brown2020-09-291-0/+6
| | | | | | | | | | | | | | | | | | | | The call to UninstallMultipleProtocolInterfaces() will implicitly disconnect any relevant controllers, and there is no specified requirement to explicitly call DisconnectController() prior to callling UninstallMultipleProtocolInterfaces(). However, some UEFI implementations (observed with the USB keyboard driver on a Microsoft Surface Go) will fail to implicitly disconnect the controller and will consequently fail to uninstall the protocols. The net effect is that unplugging and replugging a USB keyboard may leave the keyboard in a non-functional state. Work around these broken UEFI implementations by including an unnecessary call to DisconnectController() before the call to UninstallMultipleProtocolInterfaces(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Show debug message on device removalMichael Brown2020-09-291-0/+5
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Report any USB errors as EFI_USB_ERR_SYSTEMMichael Brown2020-09-291-3/+2
| | | | | | | | | | | | | | | | | | Some UEFI USB drivers (e.g. the UsbKbDxe driver in EDK2) will react to a reported EFI_USB_ERR_STALL by attempting to clear the endpoint halt. This is redundant with iPXE's EFI_USB_IO_PROTOCOL implementation, since endpoint stalls are cleared automatically by the USB core as needed. The UEFI USB driver's attempt to clear the endpoint halt can introduce an unwanted 5 second delay per endpoint if the USB error was the result of a device being physically removed, since the control transfer will always time out. Fix by reporting all USB errors as EFI_USB_ERR_SYSTEM instead of EFI_USB_ERR_STALL. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Leave USB endpoint descriptors in existence until device is removedMichael Brown2020-09-291-28/+80
| | | | | | | | | | | | | | | | | | | Some UEFI USB drivers (observed with the keyboard driver on a Microsoft Surface Go) will react to an asynchronous USB transfer failure by terminating the transfer from within the completion handler. This closes the USB endpoint and, in the current implementation, frees the containing structure. This can lead to use-after-free bugs after the UEFI USB driver's completion handler returns, since the calling code in iPXE expects that a completion handler will not perform a control-flow action such as terminating the transfer. Fix by leaving the USB endpoint structure allocated until the device is finally removed, as is already done (as an optimisation) for control and bulk transfers. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Reset control endpoints immediately after failureMichael Brown2020-09-291-0/+1
| | | | | | | | | | | | | | | The current error handling mechanism defers the endpoint reset until the next use of the endpoint, on the basis that errors are detected during completions and completion handling should not recursively call usb_poll(). In the case of usb_control(), we are already at the level that calls usb_poll() and can therefore safely perform the endpoint reset immediately. This has no impact on functionality, but does make debugging traces easier to read since the reset will appear immediately after the causative error. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Use address offset as reported by EFI_PCI_ROOT_BRIDGE_IO_PROTOCOLMichael Brown2020-09-253-14/+206
| | | | | | | | | Retrieve the address windows and translation offsets for the appropriate PCI root bridge and use them to adjust the PCI BAR address prior to calling ioremap(). Originally-implemented-by: Pankaj Bansal <pankaj.bansal@nxp.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Update drivers to use pci_ioremap()Michael Brown2020-09-2547-71/+85
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit (git 2.34.1) at 2025-02-23 08:37:50 +0000