summaryrefslogtreecommitdiffstats
path: root/src/drivers/net/efi
Commit message (Collapse)AuthorAgeFilesLines
* [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>
* [efi] Generalise snpnet_pci_info() to efi_locate_device()Michael Brown2014-08-061-34/+9Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Try various possible SNP receive filtersCurtis Larsen2014-08-061-11/+37
| | | | | | | | | | | | | | | | | | | | | | | | | The behavior observed in the Apple EFI (1.10) RecieveFilters() call is: - failure if any of the PROMISCUOUS or MULTICAST filters are included - success if only UNICAST is included, however the result is UNICAST|BROADCAST - success if only UNICAST and BROADCAST are included - if UNICAST, or UNICAST|BROADCAST are used, but the previous call tried (and failed) to set UNICAST|BROADCAST|MULTICAST, then the result is UNICAST|BROADCAST|MULTICAST Work around this apparently broken SNP implementation by trying RecieveFilterMask, then falling back to UNICAST|BROADCAST|MULTICAST, then UNICAST|BROADCAST, and finally UNICAST. Modified-by: Michael Brown <mcb30@ipxe.org> Tested-by: Curtis Larsen <larsen@dixie.edu> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Open device path protocol only at point of useMichael Brown2014-08-061-4/+27
| | | | | | | | | | | | Some EFI 1.10 systems (observed on an Apple iMac) do not allow us to open the device path protocol with an attribute of EFI_OPEN_PROTOCOL_BY_DRIVER and so we cannot maintain a safe, long-lived pointer to the device path. Work around this by instead opening the device path protocol with an attribute of EFI_OPEN_PROTOCOL_GET_PROTOCOL whenever we need to use it. Debugged-by: Curtis Larsen <larsen@dixie.edu> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Provide centralised definitions of commonly-used GUIDsMichael Brown2014-08-062-13/+0Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Reset multicast filter list when setting SNP receive filtersMichael Brown2014-08-051-1/+1
| | | | | | | | According to the UEFI specification, the MCastFilter parameter (which we currently pass as NULL, along with a zero MCastFilterCnt) is optional only if ResetMCastFilter is true. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add ability to dump SNP device mode informationMichael Brown2014-08-051-0/+64
| | | | | Originally-implemented-by: Curtis Larsen <larsen@dixie.edu> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Dump existing openers when we are unable to open a protocolMichael Brown2014-07-311-0/+2
| | | | | | | | 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>
* [efi] Use efi_handle_name() instead of efi_devpath_text() where applicableMichael Brown2014-07-311-24/+23Star
| | | | | | | | | | Using efi_devpath_text() is marginally more efficient if we already have the device path protocol available, but the mild increase in efficiency is not worth compromising the clarity of the pattern: DBGC ( device, "THING %p %s ...", device, efi_handle_name ( device ) ); Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Use efi_handle_name() instead of efi_handle_devpath_text()Michael Brown2014-07-312-4/+4
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Rewrite SNP NIC driverMichael Brown2014-07-085-510/+418Star
| | | | | | | | | Rewrite the SNP NIC driver to use non-blocking and deferrable transmissions, to provide link status detection, to provide information about the underlying (PCI) hardware device, and to avoid unnecessary I/O buffer allocations during receive polling. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Allow network devices to be created on top of arbitrary SNP devicesMichael Brown2014-07-032-8/+226
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Perform meaningful error code conversionsMichael Brown2013-04-191-38/+45
| | | | | | | | 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>
* [snpnet] Give up entirely on the transmit queueJarrod Johnson2012-02-121-32/+13Star
| | | | | | | | Practically speaking, it seems the convention is to only have one packet pending and not rely upon any mechanism to associate returned txbuf with txqueue. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [init] Remove concept of "shutdown exit flags"Michael Brown2011-01-271-3/+3
| | | | | | | | Remove the concept of shutdown exit flags, and replace it with a counter used to keep track of exposed interfaces that require devices to remain active. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [netdevice] Call netdev_link_[up|down|err]() only while registeredMichael Brown2010-09-051-3/+3
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Add the "snpnet" driverGeoff Lywood2010-06-024-0/+575
Add a new network driver that consumes the EFI Simple Network Protocol. Also add a bus driver that can find the Simple Network Protocol that iPXE was loaded from; the resulting behavior is similar to the "undionly" driver for BIOS systems. Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-02-28 03:29:51 +0100