summaryrefslogtreecommitdiffstats
path: root/src/drivers/net/intel.c
Commit message (Collapse)AuthorAgeFilesLines
* [intel] Add PCI ID for I219-V and -LM 6 to 9HEADmasterChristian Nilsson2019-03-181-0/+8
| | | | | Signed-off-by: Christian Nilsson <nikize@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add PCI_ROM entry for Intel i354 NICRob Taglang2018-03-151-0/+1
| | | | | Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Work around broken reset mechanism in i219 devicesMichael Brown2018-02-031-9/+22
| | | | | | | | | | | | | | | | | | | | The i219 appears to have a seriously broken reset mechanism. After any transmit or receive activity, resetting the card will break both the transmit and receive datapaths until the next PCI bus reset. The Linux and BSD drivers include a convoluted workaround authored by Intel which involves setting a bit in the undocumented FEXTNVM11 register, then transmitting a dummy 512-byte packet containing garbage data, then reconfiguring the receive descriptor prefetch thresholds and temporarily reenabling the receive datapath. The comments in the Intel fix do not even remotely match what the code actually does, and the code accidentally leaves the transmitter enabled after use. Experimentation suggests that an equivalent fix is to simply set the undocumented bit in FEXTNVM11 before enabling the transmit or receive descriptor rings. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add various PCI device IDsRichard Moore2017-08-221-0/+4
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add support for I219-V in 7th Gen Intel NUCJerone Young2017-07-051-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add INTEL_NO_PHY_RST for I219-VMika Tiainen2017-06-141-1/+1
| | | | | | Fix booting on HP EliteBook 820 G3. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Do not enable ASDE on i350 backplane NICMichael Brown2017-04-161-2/+4
| | | | | | | | | | | | | | | | | | | | | On most Intel NICs, Auto-Speed Detection Enable (ASDE) can be used to automatically detect the correct link speed by sampling the link using the internal PHY. This feature is automatically inhibited when not appropriate for the physical link (e.g. when using internal SerDes mode on the 8254x). On the i350 datasheet ASDE is a reserved bit, but the relevant auto-speed detection hardware appears still to be present. However, enabling ASDE on the i350 1000BASE-KX backplane NIC seems to cause an immediate link failure. It is possible that the auto-speed detection hardware is still present, is not connected to a physical link, and is not inhibited from being applied in this mode. Work around this problem by adding an INTEL_NO_ASDE flag bit (analogous to INTEL_NO_PHY_RST), and applying this for the i350 backplane NIC. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Show original CTRL and STATUS values in debugging outputMichael Brown2017-04-141-4/+12
| | | | | | | | In situations where iPXE fails to reach link-up as expected, it is useful to know the original values of the CTRL and STATUS registers prior to our reset attempt. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Reset all virtual function settingsVishvananda Ishaya2017-03-091-6/+57
| | | | | | | | | | | Some VF data is not cleared with reset, so make sure to return all the settings to default before configuring the VF. This fixes an issue where network packets would fail to be received if the VF was previously used by the linux ixgbevf driver. Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add INTEL_NO_PHY_RST for I219-LM (2)Christian Nilsson2017-01-261-1/+1
| | | | | | | | Originally-implemented-by: Malte zu Klampen <malte@pclab.ifg.uni-kiel.de> Originally-implemented-by: Richard Moore <rich@richud.com> Tested-by: Esben Storgaard Nielsen <esn@solar.dk> Signed-off-by: Christian Nilsson <nikize@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add PCI device ID for I219-V/LMLukas Grossar2016-07-121-0/+2
| | | | | Signed-off-by: Lukas Grossar <lukas.grossar@adfinis-sygroup.ch> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add PCI device ID for another I219-LMChristian Nilsson2016-06-161-0/+1
| | | | | Tested-by: Kuniyasu Suzaki <k.suzaki@aist.go.jp> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add PCI device ID for another I219-VChristian Nilsson2016-03-291-0/+1
| | | | | Signed-off-by: Christian Nilsson <nikize@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add INTEL_NO_PHY_RST for another I218-LM variantMika Tiainen2016-02-121-1/+1
| | | | | | Fixed booting on HP EliteBook 820 G2 laptop. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add INTEL_NO_PHY_RST for I218-LMHummel Frank2016-01-271-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add INTEL_NO_PHY_RST for I217-LMTorgeir Wulfsberg2015-12-071-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Forcibly skip PHY reset on some modelsMichael Brown2015-11-221-8/+17
| | | | | | | | | | | | | | | | | | On some models (notably ICH), the PHY reset mechanism appears to be broken. In particular, the PHY_CTRL register will be correctly loaded from NVM but the values will not be propagated to the "OEM bits" PHY register. This typically has the effect of dropping the link speed to 10Mbps. Since the original version of this driver in commit 945e428 ("[intel] Replace driver for Intel Gigabit NICs"), we have always worked around this problem by skipping the PHY reset if the link is already up. Enhance this workaround by explicitly checking for known-broken PCI IDs. Reported-by: Robin Smidsrød <robin@smidsrod.no> Tested-by: Robin Smidsrød <robin@smidsrod.no> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add PCI IDs for i210/i211 flashless operationKyösti Mälkki2015-11-041-0/+2
| | | | | Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [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 2024-05-23 07:36:52 +0200