summaryrefslogtreecommitdiffstats
path: root/src/drivers/net/intel.c
Commit message (Collapse)AuthorAgeFilesLines
* [intel] Allow for the use of advanced TX descriptorsMichael Brown2015-05-161-17/+75
| | | | | | | | | | | | | | | | Intel virtual function NICs almost work with the use of "legacy" transmit and receive descriptors (which are backwards compatible right back to the original Intel Gigabit NICs). Unfortunately the "TX switching" feature (which allows for VM<->VM traffic to be looped back within the NIC itself) does not work when a legacy TX descriptor is used: the packet is instead sent onto the wire. Fix by allowing for the use of an "advanced" TX descriptor (containing exactly the same information as is found in the "legacy" descriptor). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Expose intel_diag() for use by other Intel NIC driversMichael Brown2015-05-151-26/+0Star
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add PCI device IDs for Intel I218-LM and I218-VChristian Hesse2015-04-221-1/+6
| | | | | | | | I218-LM (rev 3) is found in Lenovo Thinkpad X250. The remaining device IDs are from linux/drivers/net/ethernet/intel/e1000e/hw.h Signed-off-by: Christian Hesse <mail@eworm.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Force RX polling on VMware emulated 82545emMichael Brown2015-04-211-1/+9
| | | | | | | | | | | | The emulated Intel 82545em in some versions of VMware (observed with ESXi v5.1) seems to sometimes fail to set the RXT0 bit in the interrupt cause register (ICR), causing iPXE to stop receiving packets. Work around this problem (for the 82545em only) by always polling the receive queue regardless of the state of the ICR. Reported-by: Slava Bendersky <volga629@networklab.ca> Tested-by: Slava Bendersky <volga629@networklab.ca> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Report any unexpected interrupt causesMichael Brown2015-04-211-0/+8
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add PCI ID for I218-LMThomas Miletich2015-03-091-0/+1
| | | | | Signed-off-by: Thomas Miletich <thomas.miletich@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [legal] Relicense files under GPL2_OR_LATER_OR_UBDLMichael Brown2015-03-021-1/+5
| | | | | | | Relicense files for which I am the sole author (as identified by util/relicense.pl). 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>
* [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>
* [intel] Apply PBS/PBA errata workaround only to ICH8 PCI device IDsMichael Brown2014-08-211-13/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* [intel] Check for ioremap() failuresMichael Brown2014-07-161-0/+5
| | | | | Debugged-by: Anton D. Kachalov <mouse@yandex-team.ru> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Exclude time spent in hypervisor from profilingMichael Brown2014-05-061-0/+3
| | | | | | | | When profiling, exclude any time spent inside the hypervisor responding to our MMIO accesses. This substantially reduces the variance accumulated on many other profilers. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Push new RX descriptors in batchesMichael Brown2014-04-281-8/+13
| | | | | | | | | | | | Inside a virtual machine, writing the RX ring tail pointer may incur a substantial overhead of processing inside the hypervisor. Minimise this overhead by writing the tail pointer once per batch of descriptors, rather than once per descriptor. Profiling under qemu-kvm (version 1.6.2) shows that this reduces the amount of time taken to refill the RX descriptor ring by around 90%. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Profile common virtual machine operationsMichael Brown2014-04-281-0/+19
| | | | | | | | | Operations which are negligible on physical hardware (such as issuing a posted write to the transmit ring tail register) may involve substantial amounts of processing within the hypervisor if running in a virtual machine. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Avoid completely filling the TX descriptor ringMichael Brown2014-04-221-1/+1
| | | | | | | | | | | | | It is unclear from the datasheets whether or not the TX ring can be completely filled (i.e. whether writing the tail value as equal to the current head value will cause the ring to be treated as completely full or completely empty). It is very plausible that this edge case could differ in behaviour between real hardware and the many implementations of an emulated Intel NIC found in various virtual machines. Err on the side of caution and always leave at least one ring entry empty. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add Intel I217 Gigabit Ethernet PCI IDlolipop2013-10-231-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Incorporate ring producer and consumer counters in diagnosticsMichael Brown2013-07-141-1/+6
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Expose functionality to be shared with intelx driverMichael Brown2013-04-191-15/+22
| | | | | | | | The Intel 10 Gigabit NICs have a datapath that is almost register-compatible with the Intel 1 Gigabit NICs. Expose common functionality to avoid duplication of code in the new "intelx" driver. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Remove hardcoded offsets for descriptor ring registersMichael Brown2013-04-191-6/+6
| | | | | | | | | | | | | | The Intel 10 Gigabit NICs use the same simplified (aka "legacy") descriptor format and the same layout for descriptor register blocks as the Intel 1 Gigabit NICs. The offsets of the descriptor register blocks are not the same. Simplify reuse of the existing code by removing all hardcoded offsets for registers within descriptor register blocks, and ensuring that all offsets are calculated using the descriptor register block base address provided via intel_init_ring(). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add Intel I210 Gigabit Ethernet PCI IDJens Rottmann2013-02-201-0/+1
| | | | | Signed-off-by: Jens Rottmann <JRottmann@LiPPERTembedded.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Poll RX queue if hardware reports RX overflowMichael Brown2012-10-281-1/+1
| | | | | | | | | | | | | | | The Intel NIC emulation in some versions of VMware seems to suffer from a flaw whereby the Interrupt Cause Register (ICR) fails to assert the usual "packet received" bit (ICR.RXT0) if a receive overflow (ICR.RXO) has also occurred. Work around this flaw by polling for completed descriptors whenever either ICR.RXT0 or ICR.RXO is asserted. Reported-by: Miroslav Halas <miroslav.halas@bankofamerica.com> Debugged-by: Miroslav Halas <miroslav.halas@bankofamerica.com> Tested-by: Miroslav Halas <miroslav.halas@bankofamerica.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Report receive overruns via network device errorsMichael Brown2012-10-241-1/+5
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add missing iounmap()Michael Brown2012-07-191-0/+2
| | | | | Reported-by: Thomas Miletich <thomas.miletich@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Explicitly enable descriptor queuesMichael Brown2012-07-101-0/+6
| | | | | | | | | | | | | On i350 the datasheet contradicts itself in stating that the default value of RXDCTL.ENABLE for queue zero is both set (according to the "Receive Initialization" section) and unset (according to the "Receive Descriptor Control - RXDCTL" section). Empirical evidence suggests that the default value is unset. Explicitly enable both transmit and receive queues to avoid any ambiguity. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Refill receive ring only after enabling receiverMichael Brown2012-07-101-3/+3
| | | | | | | | | | | | | | On 82576 (and probably others), the datasheet states that "the tail register of the queue (RDT[n]) should not be bumped until the queue is enabled". There is some confusion over exactly what constitutes "enabled": the initialisation blurb says that we should "poll the RXDCTL register until the ENABLE bit is set", while the description for the RXDCTL register says that the ENABLE bit is set by default (for queue zero). Empirical evidence suggests that the ENABLE bit reads as set immediately after writing to RCTL.EN, and so polling is not necessary. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Replace driver for Intel Gigabit NICsMichael Brown2012-04-241-0/+946
Tested-by: Robin Smidsrød <robin@smidsrod.no> Tested-by: Thomas Miletich <thomas.miletich@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-09 12:25:33 +0100