summaryrefslogtreecommitdiffstats
path: root/src/drivers/net/efi
Commit message (Collapse)AuthorAgeFilesLines
* [build] Mark core files as permitted for UEFI Secure BootMichael Brown2026-01-146-0/+6
| | | | | | | | | | | | Mark all files used in a standard build of bin-x86_64-efi/snponly.efi as permitted for UEFI Secure Boot. These files represent the core functionality of iPXE that is guaranteed to have been included in every binary that was previously subject to a security review and signed by Microsoft. It is therefore legitimate to assume that at least these files have already been reviewed to the required standard multiple times. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Drag in MNP driver whenever SNP driver is presentMichael Brown2025-08-271-0/+4
| | | | | | | | | | | | | | | | | | | | | The chainloaded-device-only "snponly" driver already drags in support for driving SNP, NII, and MNP devices, on the basis that the user generally doesn't care which UEFI API is used and just wants to boot from the same network device that was used to load iPXE. The multi-device "snp" driver already drags in support for driving SNP and NII devices, but does not drag in support for MNP devices. There is essentially zero code size overhead to dragging in support for MNP devices, since this support is always present in any iPXE application build anyway (as part of the code to download "autoexec.ipxe" prior to installing our own drivers). Minimise surprise by dragging in support for MNP devices whenever using the "snp" driver, following the same reasoning used for the "snponly" driver. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [init] Show initialisation function names in debug messagesMichael Brown2025-07-151-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Assume that vendor wireless drivers are unusable via SNPMichael Brown2025-07-155-7/+36
| | | | | | | | | | | | | | | | | | | | | The UEFI model for wireless network boot cannot sensibly be described without cursing. Commit 758a504 ("[efi] Inhibit calls to Shutdown() for wireless SNP devices") attempts to work around some of the known issues. Experimentation shows that on at least some platforms (observed with a Lenovo ThinkPad T14s Gen 5) the vendor SNP driver is broken to the point of being unusable in anything other than the single use case envisioned by the firwmare authors. Doing almost anything directly via the SNP protocol interface has a greater than 50% chance of locking up the system. Assume, in the absence of any evidence to the contrary so far, that vendor SNP drivers for wireless network devices are so badly written as to be unusable. Refuse to even attempt to interact with these drivers via the SNP or NII protocol interfaces. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [uaccess] Remove trivial uses of userptr_tMichael Brown2025-04-241-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Inhibit calls to Shutdown() for wireless SNP devicesMichael Brown2025-04-171-11/+174
| | | | | | | | | | | | | | | | | | | | | | | | | | | The UEFI model for wireless network configuration is somewhat underdefined. At the time of writing, the EDK2 "UEFI WiFi Connection Manager" driver provides only one way to configure wireless network credentials, which is to enter them interactively via an HII form. Credentials are not stored (or exposed via any protocol interface), and so any temporary disconnection from the wireless network will inevitably leave the interface in an unusable state that cannot be recovered without user intervention. Experimentation shows that at least some wireless network drivers (observed with an HP Elitebook 840 G10) will disconnect from the wireless network when the SNP Shutdown() method is called, or if the device is not polled sufficiently frequently to maintain its association to the network. We therefore inhibit calls to Shutdown() and Stop() for any such SNP protocol interfaces, and mark our network device as insomniac so that it will be polled even when closed. Note that we need to inhibit not only our own calls to Shutdown() and Stop(), but also those that will be attempted by MnpDxe when we disconnect it from the SNP handle. We do this by patching the installed SNP protocol interface structure to modify the Shutdown() and Stop() method pointers, which is ugly but unavoidable. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow for custom methods for disconnecting existing driversMichael Brown2025-04-176-4/+46
| | | | | | | | Allow for greater control over the process used to disconnect existing drivers from a device handle, by converting the "exclude" field from a simple protocol GUID to a per-driver method. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Disconnect existing drivers on a per-protocol basisMichael Brown2025-03-292-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | UEFI does not provide a direct method to disconnect the existing driver of a specific protocol from a handle. We currently use DisconnectController() to remove all drivers from a handle that we want to drive ourselves, and then rely on recursion in the call to ConnectController() to reconnect any drivers that did not need to be disconnected in the first place. Experience shows that OEMs tend not to ever test the disconnection code paths in their UEFI drivers, and it is common to find drivers that refuse to disconnect, fail to close opened handles, fail to function correctly after reconnection, or lock up the entire system. Implement a more selective form of disconnection, in which we use OpenProtocolInformation() to identify the driver associated with a specific protocol, and then disconnect only that driver. Perform disconnections in reverse order of attachment priority, since this is the order likely to minimise the number of cascaded implicit disconnections. This allows our MNP driver to avoid performing any disconnections at all, since it does not require exclusive access to the MNP protocol. It also avoids performing unnecessary disconnections and reconnections of unrelated drivers such as the "UEFI WiFi Connection Manager" that attaches to wireless network interfaces in order to manage wireless network associations. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Define an attachment priority order for EFI driversMichael Brown2025-03-293-6/+6
| | | | | | | | Define an ordering for internal EFI drivers on the basis of how close the driver is to the hardware, and attempt to start drivers in this order. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow use of typed pointers for efi_open() et alMichael Brown2025-03-243-17/+5Star
| | | | | | | | | Provide wrapper macros to allow efi_open() and related functions to accept a pointer to any pointer type as the "interface" argument, in order to allow a substantial amount of type adjustment boilerplate to be removed. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Use efi_open() for all ephemeral protocol opensMichael Brown2025-03-242-32/+9Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Use efi_open_unsafe() for all explicitly unsafe protocol opensMichael Brown2025-03-241-11/+10Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Use efi_open_by_driver() for all by-driver protocol opensMichael Brown2025-03-243-37/+16Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [cachedhcp] Allow cached DHCPACK to apply to temporary network devicesMichael Brown2024-04-021-0/+4
| | | | | | | | | Retain a reference to the cached DHCPACK until the late startup phase, and allow it to be recycled for reuse. This allows the cached DHCPACK to be used for a temporary MNP network device and then subsequently reused for the corresponding real network device. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add the ability to create a temporary MNP network deviceMichael Brown2024-03-294-20/+58
| | | | | | | | | | An MNP network device may be temporarily and non-destructively installed on top of an existing UEFI network stack without having to disconnect existing drivers. Add the ability to create such a temporary network device. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add support for driving EFI_MANAGED_NETWORK_PROTOCOL devicesMichael Brown2024-03-257-52/+654
| | | | | | | | | | | | | | | | | We want exclusive access to the network device, both for performance reasons and because we perform operations such as EAPoL that affect the entire link. We currently drive the network card via either a native hardware driver or via the SNP or NII/UNDI interfaces, both of which grant us this exclusive access. Add an alternative driver that drives the network card non-exclusively via the EFI_MANAGED_NETWORK_PROTOCOL interface. This can function as a fallback for situations where neither SNP nor NII/UNDI interfaces are functional, and also opens up the possibility of non-destructively installing a temporary network device over which to download the autoexec.ipxe script. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Match chainloaded device by uppermost matching handleMichael Brown2024-03-251-42/+70
| | | | | | | | | | | | | | | | | | Commit 4c5b794 ("[efi] Use the SNP protocol instance to match the SNP chainloading device") switched the chainloaded device matching logic to use a target protocol instance rather than the loaded image's device handle, on the basis that we want to bind to the parent SNP device rather than to a duplicate SNP protocol instance installed onto an IPv4 or IPv6 child device handle. It is possible that our calls to DisconnectController() and ConnectController() will cause the target protocol instance to be uninstalled and reinstalled, which may change the value of the protocol instance pointer. Allow for this by identifying and matching against the uppermost handle that initially has this target protocol instance installed. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Pad transmit buffer length to work around vendor driver bugsMichael Brown2024-03-182-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Mellanox/Nvidia UEFI driver is built from the same codebase as the iPXE driver, and appears to contain the bug that was fixed in commit c11734e ("[golan] Use ETH_HLEN for inline header size"). This results in identical failures when using the SNP or NII interface (via e.g. snponly.efi) to drive a Mellanox card while EAPoL is enabled. Work around the underlying UEFI driver bug by padding transmit I/O buffers to the minimum Ethernet frame length before passing them to the underlying driver's transmit function. This padding is not technically necessary, since almost all modern hardware will insert transmit padding as necessary (and where the hardware does not support doing so, the underlying UEFI driver is responsible for adding any necessary padding). However, it is guaranteed to be harmless (other than a miniscule performance impact): the Ethernet specification requires zero padding up to the minimum frame length for packets that are transmitted onto the wire, and so the receiver will see the same packet whether or not we manually insert this padding in software. The additional padding causes the underlying Mellanox driver to avoid its faulty code path, since it will never be asked to transmit a very short packet. Tested-by: Eric Hagberg <ehagberg@janestreet.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [snp] Allocate additional padding for receive buffersMichael Brown2024-03-171-1/+14
| | | | | | | | | | | | | | Some SNP implementations (observed with a wifi adapter in a Dell Latitude 3440 laptop) seem to require additional space in the allocated receive buffers, otherwise full-length packets will be silently dropped. The EDK2 MnpDxe driver happens to allocate an additional 8 bytes of padding (4 for a VLAN tag, 4 for the Ethernet frame checksum). Match this behaviour since drivers are very likely to have been tested against MnpDxe. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [netdevice] Remove netdev_priv() helper functionMichael Brown2023-09-131-3/+3
| | | | | | | | | | Some network device drivers use the trivial netdev_priv() helper function while others use the netdev->priv pointer directly. Standardise on direct use of netdev->priv, in order to free up the function name netdev_priv() for reuse. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Always poll for TX completionsMichael Brown2023-06-211-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Polling for TX completions is arguably redundant when there are no transmissions currently in progress. Commit c6c7e78 ("[efi] Poll for TX completions only when there is an outstanding TX buffer") switched to setting the PXE_OPFLAGS_GET_TRANSMITTED_BUFFERS flag only when there is an in-progress transmission awaiting completion, in order to reduce reported TX errors and debug message noise from buggy NII implementations that report spurious TX completions whenever the transmit queue is empty. Some other NII implementations (observed with the Realtek driver in a Dell Latitude 3440) seem to have a bug in the transmit datapath handling which results in the transmit ring freezing after sending a few hundred packets under heavy load. The symptoms are that the TPPoll register's NPQ bit remains set and the 256-entry transmit ring contains a large number of uncompleted descriptors (with the OWN bit set), the first two of which have identical data buffer addresses. Though iPXE will submit at most one in-progress transmission via NII, the Dell/Realtek driver seems to make a page-aligned copy of each transmit data buffer and to report TX completions immediately without waiting for the packet to actually be transmitted. These synthetic TX completions continue even after the hardware transmit ring freezes. Setting PXE_OPFLAGS_GET_TRANSMITTED_BUFFERS on every poll reduces the probability of this Dell/Realtek driver bug being triggered by a factor of around 500, which brings the failure rate down to the point that it can sensibly be managed by external logic such as the "--timeout" option for image downloads. Closing and reopening the interface (via "ifclose"/"ifopen") will clear the error condition and allow transmissions to resume. Revert to setting PXE_OPFLAGS_GET_TRANSMITTED_BUFFERS on every poll, and silently ignore situations in which the hardware reports a completion when no transmission is in progress. This approximately matches the behaviour of the SnpDxe driver, which will also generally set PXE_OPFLAGS_GET_TRANSMITTED_BUFFERS on every poll. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Bind to only the topmost instance of the SNP or NII protocolsMichael Brown2023-01-231-30/+36
| | | | | | | | | | | | | | UEFI has the mildly annoying habit of installing copies of the EFI_SIMPLE_NETWORK_PROTOCOL instance on the IPv4 and IPv6 child device handles. This can cause iPXE's SNP driver to attempt to bind to a copy of the EFI_SIMPLE_NETWORK_PROTOCOL that iPXE itself provided on a different handle. Fix by refusing to bind to an SNP (or NII) handle if there exists another instance of the same protocol further up the device path (on the basis that we always want to bind to the highest possible device). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Extend efi_locate_device() to allow searching up the device pathMichael Brown2023-01-232-2/+2
| | | | | | | | Extend the functionality of efi_locate_device() to allow callers to find instances of the protocol that may exist further up the device path. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Disable receive filters to work around buggy UNDI driversMichael Brown2023-01-111-10/+47
| | | | | | | | | | | | | Some UNDI drivers (such as the AMI UsbNetworkPkg currently in the process of being upstreamed into EDK2) have a bug that will prevent any packets from being received unless at least one attempt has been made to disable some receive filters. Work around these buggy drivers by attempting to disable receive filters before enabling them. Ignore any errors, since we genuinely do not care whether or not the disabling succeeds. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Run ExitBootServices shutdown hook at TPL_NOTIFYMichael Brown2021-11-232-5/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On some systems (observed with the Thunderbolt ports on a ThinkPad X1 Extreme Gen3 and a ThinkPad P53), if the IOMMU is enabled then the system firmware will install an ExitBootServices notification event that disables bus mastering on the Thunderbolt xHCI controller and all PCI bridges, and destroys any extant IOMMU mappings. This leaves the xHCI controller unable to perform any DMA operations. As described in commit 236299b ("[xhci] Avoid DMA during shutdown if firmware has disabled bus mastering"), any subsequent DMA operation attempted by the xHCI controller will end up completing after the operating system kernel has reenabled bus mastering, resulting in a DMA operation to an area of memory that the hardware is no longer permitted to access and, on Windows with the Driver Verifier enabled, a STOP 0xE6 (DRIVER_VERIFIER_DMA_VIOLATION). That commit avoids triggering any DMA attempts during the shutdown of the xHCI controller itself. However, this is not a complete solution since any attached and opened USB device (e.g. a USB NIC) may asynchronously trigger DMA attempts that happen to occur after bus mastering has been disabled but before we reset the xHCI controller. Avoid this problem by installing our own ExitBootServices notification event at TPL_NOTIFY, thereby causing it to be invoked before the firmware's own ExitBootServices notification event that disables bus mastering. This unsurprisingly causes the shutdown hook itself to be invoked at TPL_NOTIFY, which causes a fatal error when later code attempts to raise the TPL to TPL_CALLBACK (which is a lower TPL). Work around this problem by redefining the "internal" iPXE TPL to be variable, and set this internal TPL to TPL_NOTIFY when the shutdown hook is invoked. Avoid calling into an underlying SNP protocol instance from within our shutdown hook at TPL_NOTIFY, since the underlying SNP driver may attempt to raise the TPL to TPL_CALLBACK (which would cause a fatal error). Failing to shut down the underlying SNP device is safe to do since the underlying device must, in any case, have installed its own ExitBootServices hook if any shutdown actions are required. 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] Use casts rather than virt_to_bus() for UNDI buffer addressesMichael Brown2020-11-161-2/+2
| | | | | | | | | | For a software UNDI, the addresses in PXE_CPB_TRANSMIT.FrameAddr and PXE_CPB_RECEIVE.BufferAddr are host addresses, not bus addresses. Remove the spurious (and no-op) use of virt_to_bus() and replace with a cast via intptr_t. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Do not populate media header length in PXE transmit CPBMichael Brown2020-11-161-1/+0Star
| | | | | | | | | | | | | | | | | | The UEFI specification defines PXE_CPB_TRANSMIT.DataLen as excluding the length of the media header. iPXE currently fills in DataLen as the whole frame length (including the media header), along with placing the media header length separately in MediaheaderLen. On some UNDI implementations (observed using a VMware ESXi 7.0b virtual machine), this causes transmitted packets to include 14 bytes of trailing garbage. Match the behaviour of the EDK2 SnpDxe driver, which fills in DataLen as the whole frame length (including the media header) and leaves MediaheaderLen as zero. This behaviour also violates the UEFI specification, but is likely to work in practice since EDK2 is the reference implementation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Attempt NII initialisation both with and without cable detectionMichael Brown2020-08-171-9/+28
| | | | | | | | | | | | | | | | | | We currently use a heuristic to determine whether or not to request cable detection in PXE_OPCODE_INITIALIZE, based on the need to work around a known Emulex driver bug (see commit c0b61ba "[efi] Work around bugs in Emulex NII driver") and the need to accommodate links that are legitimately slow to come up (see commit 6324227 "[efi] Skip cable detection at initialisation where possible"). This heuristic appears to fail with newer Emulex drivers. Attempt to support all known drivers (past and present) by first attempting initialisation with cable detection, then falling back to attempting initialisation without cable detection. Reported-by: Kwang Woo Lee <kwleeyh@gmail.com> Tested-by: Kwang Woo Lee <kwleeyh@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [snp] Retry initialisation if link is reported as downMichael Brown2020-06-191-7/+49
| | | | | | | | | | | | | | | Some devices (observed with a Getac RX10 tablet and docking station containing an embedded AX88179 USB NIC) seem to be capable of detecting link state only during the call to Initialize(), and will occasionally erroneously report that the link is down for the first few such calls. Work around these devices by retrying the Initialize() call multiple times, terminating early if a link is detected. The eventual absence of a link is treated as a non-fatal error, since it is entirely possible that the link really is down. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [snp] Set EFI_SIMPLE_NETWORK_RECEIVE_MULTICAST bit as per UEFI specIgnat Korchagin2019-12-161-1/+2
| | | | | | | | | | According to UEFI specification 2.8 p 24.1 we must set the EFI_SIMPLE_NETWORK_RECEIVE_MULTICAST bit in the "Disable" mask, when "ResetMCastFilter" is TRUE. Signed-off-by: Ignat Korchagin <ignat@cloudflare.com> Split-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [snp] Try promiscuous multicast receive filter if the regular one failsIgnat Korchagin2019-12-161-0/+3
| | | | | | | | | | | | | | | Currently, if the SNP driver for whatever reason fails to enable receive filters for multicast frames, it falls back to enabling just unicast and broadcast filters. This breaks some IPv6 functionality as the network card does not respond to neighbour solicitation requests. Some cards refuse to enable EFI_SIMPLE_NETWORK_RECEIVE_MULTICAST, but do support enabling EFI_SIMPLE_NETWORK_RECEIVE_PROMISCUOUS_MULTICAST, so try it before falling back to just unicast+broadcast. Signed-off-by: Ignat Korchagin <ignat@cloudflare.com> Split-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide Map_Mem() and associated UNDI callbacksMichael Brown2018-03-201-0/+163
| | | | | | | | | | | | | | | | | | | Some drivers are known to call the optional Map_Mem() callback without first checking that the callback exists. Provide a usable basic implementation of Map_Mem() along with the other callbacks that become mandatory if Map_Mem() is provided. Note that in theory the PCI I/O protocol is allowed to require multiple calls to Map(), with each call handling only a subset of the overall mapped range. However, the reference implementation in EDK2 assumes that a single Map() will always suffice, so we can probably make the same simplifying assumption here. Tested with the Intel E3522X2.EFI driver (which, incidentally, fails to cleanly remove one of its mappings). Originally-implemented-by: Maor Dickman <maord@mellanox.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Raise TPL when calling UNDI entry pointMichael Brown2017-09-051-0/+8
| | | | | | | | | The SnpDxe driver raises the task priority level to TPL_CALLBACK when calling the UNDI entry point. This does not appear to be a documented requirement, but we should probably match the behaviour of SnpDxe to minimise surprises to third party code. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Enumerate PCI BARs in same order as SnpDxeMichael Brown2017-07-211-2/+2
| | | | | | | | | | | | | | | | | | | The UEFI specification has an implicit and demonstrably incorrect requirement (in the Mem_IO() calling convention) that any UNDI network device has at most one memory BAR and one I/O BAR. Some UEFI platforms have been observed to report the existence of non-existent additional I/O BARs, causing iPXE to select the wrong BAR. This problem does not affect the SnpDxe driver, since that driver will always choose the lowest numbered existent BAR of each type. Adjust iPXE's behaviour to match that of SnpDxe, i.e. to always select the lowest numbered BAR(s). Debugged-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Debugged-by: Adklei <adklei@realtek.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Skip cable detection at initialisation where possibleMichael Brown2017-03-191-23/+19Star
| | | | | | | | | | | | | | | | | | We currently request cable detection in PXE_OPCODE_INITIALIZE to work around buggy Emulex drivers (see commit c0b61ba ("[efi] Work around bugs in Emulex NII driver")). This causes problems with some other NII drivers (e.g. Mellanox), which may time out if the underlying link is intrinsically slow to come up. Attempt to work around both problems simultaneously by requesting cable detection only if the underlying NII driver does not support link status reporting via PXE_OPCODE_GET_STATUS. (This is based on a potentially incorrect assumption that the buggy Emulex drivers do not claim to report link status via PXE_OPCODE_GET_STATUS.) Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Guard against GetStatus() failing to return a NULL TX bufferMichael Brown2016-05-121-0/+1
| | | | | | | | | | | | | | | The UEFI specification requires the EFI_SIMPLE_NETWORK_PROTOCOL GetStatus() method to set TxBuf to NULL if there are no transmit buffers to recycle. Some implementations (observed with Lan9118Dxe in EDK2) fill in TxBuf only when there is a transmit buffer to recycle, which leads to large numbers of "spurious TX completion" errors. Work around this problem by initialising TxBuf to NULL before calling the GetStatus() method. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Remove raw EFI_HANDLE values from debug messagesMichael Brown2015-08-274-43/+41Star
| | | | | | | | | The raw EFI_HANDLE value is almost never useful to know, and simply adds noise to the already verbose debug messages. Improve the legibility of debug messages by using only the name generated by efi_handle_name(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Work around bugs in Emulex NII driverFabrice Bacchella2015-08-171-15/+71
| | | | | Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Improve NII driver loggingFabrice Bacchella2015-08-171-10/+21
| | | | | Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Poll for TX completions only when there is an outstanding TX bufferMichael Brown2015-04-141-8/+4Star
| | | | | | | | | At least one NII implementation (in a Microsoft Surface tablet) seems to fail to report the absence (sic) of TX completions properly. Work around this by checking for TX completions only when we expect to see one. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Poll media status only if advertised as supportedMichael Brown2015-04-141-2/+14
| | | | | | | | Some NII implementations will fail the GET_STATUS operation if we request the media status. Fix by doing so only if GET_INIT_INFO reported that media status is supported. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide a dummy data block in nii_initialise()Michael Brown2015-04-141-1/+6
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [legal] Relicense files under GPL2_OR_LATER_OR_UBDLMichael Brown2015-03-024-4/+16
| | | | | | | Relicense files for which I am the sole author (as identified by util/relicense.pl). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Include NII driver within "snp" and "snponly" build targetsMichael Brown2014-10-174-106/+195
| | | | | | | | | End users almost certainly don't care whether the underlying interface is SNP or NII/UNDI. Try to minimise surprise and unnecessary documentation by including the NII driver whenever the SNP driver is requested. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Check for presence of UNDI in NII protocolMichael Brown2014-10-171-0/+6
| | | | | | | | iPXE itself exposes a dummy NII protocol with no UNDI. Avoid potentially dereferencing a NULL pointer by checking for a non-zero UNDI address. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add NII / UNDI driverMichael Brown2014-10-161-0/+1134
| | | | | | | | | | | | | | | | | | | | | | | Some UEFI network drivers provide a software UNDI interface which is exposed via the Network Interface Identifier Protocol (NII), rather than providing a Simple Network Protocol (SNP). The UEFI platform firmware will usually include the SnpDxe driver, which attaches to NII and provides an SNP interface. The SNP interface is usually provided on the same handle as the underlying NII device. This causes problems for our EFI driver model: when efi_driver_connect() detaches existing drivers from the handle it will cause the SNP interface to be uninstalled, and so our SNP driver will not be able to attach to the handle. The platform firmware will eventually reattach the SnpDxe driver and may attach us to the SNP handle, but we have no way to prevent other drivers from attaching first. Fix by providing a driver which can attach directly to the NII protocol, using the software UNDI interface to drive the network device. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Generalise snpnet_dev_info() to efi_device_info()Michael Brown2014-10-161-60/+1Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Free transmit ring entry before calling netdev_tx_complete()Michael Brown2014-10-161-1/+3
| | | | | | | | The snpnet driver uses netdev_tx_defer() and so must ensure that space in the (single-entry) transmit descriptor ring is freed up before calling netdev_tx_complete(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow for non-PCI snpnet devicesMichael Brown2014-09-041-7/+8
| | | | | | | | | | | | | 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>
* [efi] Use the SNP protocol instance to match the SNP chainloading deviceMichael Brown2014-09-041-8/+89
| | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-03-04 22:32:43 +0100