summaryrefslogtreecommitdiffstats
path: root/src/drivers
Commit message (Collapse)AuthorAgeFilesLines
* [xhci] Abort commands on timeoutMichael Brown2015-02-182-15/+82
| | | | | | | | | | | | When a command times out, abort it (via the Command Abort bit in the Command Ring Control Register) so that subsequent commands may execute as expected. This improves robustness when a device fails to respond to the Set Address command, since the subsequent Disable Slot command will now succeed. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xhci] Leak memory if controller fails to disable slotMichael Brown2015-02-181-3/+18
| | | | | | | | | | | | | | | | If the Disable Slot command fails then the hardware may continue to write to the slot context. Leak the memory used by the slot context to avoid future memory corruption. This situation has been observed in practice when a Set Address command fails, causing the command ring to become temporarily unresponsive. Note that there is no need to similarly leak memory on the failure path in xhci_device_open(), since in the event of a failure the hardware is never informed of the slot context address. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ncm] Use generic USB network device frameworkMichael Brown2015-02-172-235/+58Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ecm] Use generic USB network device frameworkMichael Brown2015-02-172-211/+35Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Add generic USB network device frameworkMichael Brown2015-02-171-0/+280
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ncm] Use generic refill framework for bulk IN and interrupt endpointsMichael Brown2015-02-162-252/+92Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ecm] Use generic refill framework for bulk IN and interrupt endpointsMichael Brown2015-02-132-133/+40Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Use generic refill framework for USB hub interrupt endpointsMichael Brown2015-02-132-51/+7Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Provide generic framework for refilling receive endpointsMichael Brown2015-02-131-0/+128
| | | | | | | Provide a generic framework for allocating, refilling, and optionally recycling I/O buffers used by bulk IN and interrupt endpoints. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Handle port status changes received after failing to find a driverMichael Brown2015-02-121-5/+13
| | | | | | | | | | | | | | | | | | | | | Commit a60f2dd ("[usb] Try multiple USB device configurations") changed the behaviour of register_usb() such that if no drivers are found then the device will be closed and the memory used will be freed. If a port status change subsequently occurs while the device is still physically attached, then usb_hotplug() will see this as a new device having been attached, since there is no device recorded as being currently attached to the port. This can lead to spurious hotplug events (or even endless loops of hotplug events, if the process of opening and closing the device happens to generate a port status change). Fix by using a separate flag to indicate that a device is physically attached (even if we have no corresponding struct usb_device). Reported-by: Dan Ellis <Dan.Ellis@displaylink.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xhci] Delay after (possibly) forcing port link state to RxDetectMichael Brown2015-02-112-0/+8
| | | | | | | | | | | | Some xHCI controllers (observed with a Renesas Electronics PCIe USB3 card) seem to require a delay after forcing the link state of USB3 ports to RxDetect. Omitting this delay causes strange behaviour including system lockups. Add an unconditional 20ms delay after writing the port link states. This seems to be sufficient to avoid the problem. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ecm] Add support for CDC-ECM USB Ethernet devicesMichael Brown2015-02-102-1/+750
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Allow usb_stream() to enforce a terminating short packetMichael Brown2015-02-104-11/+23
| | | | | | | | | | Some USB endpoints require that a short packet be used to terminate transfers, since they have no other way to determine message boundaries. If the message length happens to be an exact multiple of the USB packet size, then this requires the use of an additional zero-length packet. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Parse endpoint descriptor bInterval fieldMichael Brown2015-02-103-4/+38
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Handle CDC union functional descriptorsMichael Brown2015-02-092-3/+83
| | | | | | | USB Communications Device Class devices may use a union functional descriptor to group several interfaces into a function. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Try multiple USB device configurationsMichael Brown2015-02-091-69/+134
| | | | | | | Iterate over a USB device's available configurations until we find one for which we have working drivers. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ncm] Reserve headroom in received packetsMichael Brown2015-02-061-1/+11
| | | | | | | | | Some protocols (such as ARP) may modify the received packet and re-use the same I/O buffer for transmission of a reply. To allow this, reserve sufficient headroom at the start of each received packet buffer for our transmit datapath headers. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ncm] Use large multi-packet buffers by defaultMichael Brown2015-02-062-165/+301
| | | | | | | | | | | | | | | | | | | | | | | | Some devices have a very small number of internal buffers, and rely on being able to pack multiple packets into each buffer. Using 2048-byte buffers on such devices produces throughput of around 100Mbps. Using a small number of much larger buffers (e.g. 32kB) increases the throughput to around 780Mbps. (The full 1Gbps is not reached because the high RTT induced by the use of multi-packet buffers causes us to saturate our 256kB TCP window.) Since allocation of large buffers is very likely to fail, allocate the buffer set only once when the device is opened and recycle buffers immediately after use. Received data is now always copied to per-packet buffers. If allocation of large buffers fails, fall back to allocating a larger number of smaller buffers. This will give reduced performance, but the device will at least still be functional. Share code between the interrupt and bulk IN endpoint handlers, since the buffer handling is now very similar. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Report xHCI host controller eventsMichael Brown2015-02-052-0/+41
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ncm] Add support for CDC-NCM USB Ethernet devicesMichael Brown2015-02-034-0/+1158
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Add support for xHCI host controllersMichael Brown2015-02-032-0/+4075
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Add basic support for USB hubsMichael Brown2015-02-033-0/+803
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [usb] Add basic support for USB devicesMichael Brown2015-02-031-0/+1648
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Allow drivers to specify a PCI classMichael Brown2015-02-021-3/+6
| | | | | | | | Allow drivers to specify a supported PCI class code. To save space in the final binary, make this an attribute of the driver rather than an attribute of a PCI device ID list entry. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [hyperv] Assume that VMBus xfer page ranges correspond to RNDIS messagesMichael Brown2014-12-201-6/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The (undocumented) VMBus protocol seems to allow for transfer page-based packets where the data payload is split into an arbitrary set of ranges within the transfer page set. The RNDIS protocol includes a length field within the header of each message, and it is known from observation that multiple RNDIS messages can be concatenated into a single VMBus message. iPXE currently assumes that the transfer page range boundaries are entirely arbitrary, and uses the RNDIS header length to determine the RNDIS message boundaries. Windows Server 2012 R2 generates an RNDIS_INDICATE_STATUS_MSG for an undocumented and unknown status code (0x40020006) with a malformed RNDIS header length: the length does not cover the StatusBuffer portion of the message. This causes iPXE to report a malformed RNDIS message and to discard any further RNDIS messages within the same VMBus message. The Linux Hyper-V driver assumes that the transfer page range boundaries correspond to RNDIS message boundaries, and so does not notice the malformed length field in the RNDIS header. Match the behaviour of the Linux Hyper-V driver: assume that the transfer page range boundaries correspond to the RNDIS message boundaries and ignore the RNDIS header length. This avoids triggering the "malformed packet" error and also avoids unnecessary data copying: since we now have one I/O buffer per RNDIS message, there is no longer any need to use iob_split(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [hyperv] Increase TX ring sizeMichael Brown2014-12-201-1/+1
| | | | | | | | Empirical observation suggests that 32 is a sensible size to minimise the number of deferred packet transmissions without overflowing the VMBus transmit ring buffer. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [hyperv] Receive all VMBus messages in a pollMichael Brown2014-12-201-1/+3
| | | | | | | Allow for elision of transmitted TCP ACKs by handling all received VMBus messages in each network device poll operation. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [hyperv] Tear down NetVSC RX buffer GPADL after closing VMBus deviceMichael Brown2014-12-201-24/+20Star
| | | | | | | | | | | | | On Windows Server 2012 R2, the receive buffer teardown completion message seems to occasionally be deferred until after the VMBus channel has been closed. This happens even if there are no packets currently in the receive buffer. Work around this problem by separating the revocation and teardown of the receive buffer, and deferring the teardown until after the VMBus channel has been closed. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [hyperv] Add support for NetVSC paravirtual network devicesMichael Brown2014-12-182-0/+1203
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [vmxnet3] Add profiling code to exclude time spent in the hypervisorMichael Brown2014-12-121-1/+33
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Use autoloaded MAC address instead of EEPROM MAC addressMichael Brown2014-10-311-4/+4
| | | | | | | | | | | | | | | | | | | The i350 (and possibly other Intel NICs) have a non-trivial correspondence between the PCI function number and the external physical port number. For example, the i350 has a "LAN Function Sel" bit within the EEPROM which can invert the mapping so that function 0 becomes port 3, function 1 becomes port 2, etc. Unfortunately the MAC addresses within the EEPROM are indexed by physical port number rather than PCI function number. The end result is that when anything other than the default mapping is used, iPXE will use the wrong address as the base MAC address. Fix by using the autoloaded MAC address if it is valid, and falling back to reading the MAC address directly from the EEPROM only if no autoloaded address is available. 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>
* [intel] Add 8086:1557 card (Intel 82599 10G ethernet mezz)Anton D. Kachalov2014-10-031-0/+1
| | | | | Signed-off-by: Anton D. Kachalov <mouse@yandex-team.ru> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add I217-LM PCI IDJan Kiszka2014-09-161-1/+2
| | | | | | | Add the ID for the LM variant and differentiate it from the I217-V. Signed-off-by: Jan Kiszka <jan.kiszka@web.de> 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>
* [intel] Apply PBS/PBA errata workaround only to ICH8 PCI device IDsMichael Brown2014-08-212-13/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ICH8 devices have an errata which requires us to reconfigure the packet buffer size (PBS) register, and correspondingly adjust the packet buffer allocation (PBA) register. The "Intel I/O Controller Hub ICH8/9/10 and 82566/82567/82562V Software Developer's Manual" notes for the PBS register that: 10.4.20 Packet Buffer Size - PBS (01008h; R/W) Note: The default setting of this register is 20 KB and is incorrect. This register must be programmed to 16 KB. Initial value: 0014h 0018h (ICH9/ICH10) It is unclear from this comment precisely which devices require the workaround to be applied. We currently attempt to err on the side of caution: if we detect an initial value of either 0x14 or 0x18 then the workaround will be applied. If the workaround is applied unnecessarily, then the effect should be just that we use less than the full amount of the available packet buffer memory. Unfortunately this approach does not play nicely with other device drivers. For example, the Linux e1000e driver will rewrite PBA while assuming that PBS still contains the default value, which can result in inconsistent values between the two registers, and a corresponding inability to transmit or receive packets. Even more unfortunately, the contents of PBS and PBA are not reset by anything less than a power cycle, meaning that this error condition will survive a hardware reset. The Linux driver (written and maintained by Intel) applies the PBS/PBA errata workaround only for devices in the ICH8 family, identified via the PCI device ID. Adopt a similar approach, using the PCI_ROM() driver data field to indicate when the workaround is required. Reported-by: Donald Bindner <dbindner@truman.edu> Debugged-by: Donald Bindner <dbindner@truman.edu> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Display before and after values for both PBS and PBAMichael Brown2014-08-211-2/+7
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Display PBS value when applying ICH errata workaroundMichael Brown2014-08-201-2/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [smc9000] Avoid using CONFIG as a preprocessor macroMichael Brown2014-08-192-6/+6
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xen] Cope with unexpected initial backend statesMichael Brown2014-08-141-10/+64
| | | | | | | | | | | | | | | | | | | | | | | | | Under some circumstances (e.g. if iPXE itself is booted via iSCSI, or after an unclean reboot), the backend may not be in the expected InitWait state when iPXE starts up. There is no generic reset mechanism for Xenbus devices. Recent versions of xen-netback will gracefully perform all of the required steps if the frontend sets its state to Initialising. Older versions (such as that found in XenServer 6.2.0) require the frontend to transition through Closed before reaching Initialising. Add a reset mechanism for netfront devices which does the following: - read current backend state - if backend state is anything other than InitWait, then set the frontend state to Closed and wait for the backend to also reach Closed - set the frontend state to Initialising and wait for the backend to reach InitWait. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [xen] Use version 1 grant tables by defaultMichael Brown2014-08-131-28/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using version 1 grant tables limits guests to using 16TB of grantable RAM, and prevents the use of subpage grants. Some versions of the Xen hypervisor refuse to allow the grant table version to be set after the first grant references have been created, so the loaded operating system may be stuck with whatever choice we make here. We therefore currently use version 2 grant tables, since they give the most flexibility to the loaded OS. Current versions (7.2.0) of the Windows PV drivers have no support for version 2 grant tables, and will merrily create version 1 entries in what the hypervisor believes to be a version 2 table. This causes some confusion. Avoid this problem by attempting to use version 1 tables, since otherwise we may render Windows unable to boot. Play nicely with other potential bootloaders by accepting either version 1 or version 2 grant tables (if we are unable to set our requested version). Note that the use of version 1 tables on a 64-bit system introduces a possible failure path in which a frame number cannot fit into the 32-bit field within the v1 structure. This in turn introduces additional failure paths into netfront_transmit() and netfront_refill_rx(). 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>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2026-02-27 19:34:08 +0100