aboutsummaryrefslogtreecommitdiffstats
path: root/src/drivers
Commit message (Collapse)AuthorAgeFilesLines
* [ena] Change reported operating system type to "iPXE"enaMichael Brown2024-09-052-8/+14
| | | | | | | | | | | | | | | | | | | | | | | | | As described in commit 3b81a4e ("[ena] Provide a host information page"), we currently report an operating system type of "Linux" in order to work around broken versions of the ENA firmware that will fail to create a completion queue if we report the correct operating system type. As of September 2024, the ENA team at AWS assures us that the entire AWS fleet has been upgraded to fix this bug, and that we are now safe to report the correct operating system type value in the "type" field of struct ena_host_info. The ENA team has also clarified that at least some deployed versions of the ENA firmware still have the defect that requires us to report an operating system version number of 2 (regardless of operating system type), and so we continue to report ENA_HOST_INFO_VERSION_WTF in the "version" field of struct ena_host_info. Add an explicit warning on the previous known failure path, in case some deployed versions of the ENA firmware turn out to not have been upgraded as expected. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [aqc1xx] Add support for Marvell AQtion Ethernet controlleraqc1xxAnimesh Bhatt2024-09-026-0/+1614
| | | | | | | | | This patch adds support for the AQtion Ethernet controller, enabling iPXE to recognize and utilize the specific models (AQC114, AQC113, and AQC107). Tested-by: Animesh Bhatt <animeshb@marvell.com> Signed-off-by: Animesh Bhatt <animeshb@marvell.com>
* [etherfabric] Fix use of uninitialised variable in falcon_xaui_link_ok()Michael Brown2024-09-021-6/+9
| | | | | | | | | | | | | | The link status check in falcon_xaui_link_ok() reads from the FCN_XX_CORE_STAT_REG_MAC register only on production hardware (where the FPGA version reads as zero), but modifies the value and writes back to this register unconditionally. This triggers an uninitialised variable warning on newer versions of gcc. Fix by assuming that the register exists only on production hardware, and so moving the "modify-write" portion of the "read-modify-write" operation to also be covered by the same conditional check. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Remove the concept of a public-key algorithm reusable contextMichael Brown2024-08-211-14/+4
| | | | | | | | | | | | | | | | | | | | | | | Instances of cipher and digest algorithms tend to get called repeatedly to process substantial amounts of data. This is not true for public-key algorithms, which tend to get called only once or twice for a given key. Simplify the public-key algorithm API so that there is no reusable algorithm context. In particular, this allows callers to omit the error handling currently required to handle memory allocation (or key parsing) errors from pubkey_init(), and to omit the cleanup calls to pubkey_final(). This change does remove the ability for a caller to distinguish between a verification failure due to a memory allocation failure and a verification failure due to a bad signature. This difference is not material in practice: in both cases, for whatever reason, the caller was unable to verify the signature and so cannot proceed further, and the cause of the error will be visible to the user via the return status code. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [gve] Add missing error codes in EUNIQ() list of potential errorsMichael Brown2024-08-201-4/+5
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Pass asymmetric keys as ASN.1 cursorsMichael Brown2024-08-181-2/+1
| | | | | | | | | | | Asymmetric keys are invariably encountered within ASN.1 structures such as X.509 certificates, and the various large integers within an RSA key are themselves encoded using ASN.1. Simplify all code handling asymmetric keys by passing keys as a single ASN.1 cursor, rather than separate data and length pointers. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Separate permission to probe buses from bus:dev.fn range discoveryMichael Brown2024-08-152-0/+5
| | | | | | | | | | | | | | | | | The UEFI device model requires us to not probe the PCI bus directly, but instead to wait to be offered the opportunity to drive devices via our driver service binding handle. We currently inhibit PCI bus probing by having pci_discover() return an empty range when using the EFI PCI I/O API. This has the unwanted side effect that scanning the bus manually using the "pciscan" command will also fail to discover any devices. Separate out the concept of being allowed to probe PCI buses from the mechanism for discovering PCI bus:dev.fn address ranges, so that this limitation may be removed. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [gve] Increase number of receive buffers to reduce packet lossMichael Brown2024-07-252-5/+13
| | | | | | | | | | | Experiments suggest that using fewer than 64 receive buffers leads to excessive packet drop rates on some instance types (observed with a c3-standard-4 instance in europe-west4-a). Fix by increasing the number of receive data buffers (and adjusting the length of the registrable queue page address list to match). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [gve] Add driver for Google Virtual Ethernet NICMichael Brown2024-07-242-0/+2309
| | | | | | | | The Google Virtual Ethernet NIC (GVE or gVNIC) is found only in Google Cloud instances. There is essentially zero documentation available beyond the mostly uncommented source code in the Linux kernel. 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>
* [golan] Use ETH_HLEN for inline header sizeRabia Manaa2024-03-171-1/+1
| | | | | | | | | | | | The driver does not correctly handle very short transmitted packets such as EAPoL-Start where the entire DMA content lies within the current send work queue entry inline header length of 18 bytes. Fix by reducing the inline header length to the Ethernet frame header length of 14 bytes. Modified-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [snp] Allocate additional padding for receive buffersMichael Brown2024-03-161-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>
* [drivers] Sort PCI_ROM() entries numericallyGeert Stappers2024-02-2221-137/+136
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Done with the help of this Perl script: $MARKER = 'PCI_ROM'; # a regex $AB = 1; # At Begin @HEAD = (); @ITEMS = (); @TAIL = (); foreach $fn (@ARGV) { open(IN, $fn) or die "Can't open file '$fn': $!\n"; while (<IN>) { if (/$MARKER/) { push @ITEMS, $_; $AB = 0; # not anymore at begin } else { if ($AB) { push @HEAD, $_; } else { push @TAIL, $_; } } } } continue { close IN; open(OUT, ">$fn") or die "Can't open file '$fn' for output: $!\n"; print OUT @HEAD; print OUT sort @ITEMS; print OUT @TAIL; close OUT; # For a next file $AB = 1; @HEAD = (); @ITEMS = (); @TAIL = (); } Executed that script while src/drivers/ as current working directory, provided '$(grep -rl PCI_ROM)' as argument. Signed-off-by: Geert Stappers <stappers@stappers.it>
* [bnxt] Add support for BCM957608Joseph Wong2024-02-084-101/+720
| | | | | | | Add support for BCM957608 device. Add support for additional link speeds supported by BCM957608. Signed-off-by: Joseph Wong <joseph.wong@broadcom.com>
* [bnxt] Add support for additional chip IDsJoseph Wong2024-01-192-2/+6
| | | | | | | Add additional chip IDs that can be recognized as part of the thor family. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [libc] Replace linker_assert() with build_assert()Michael Brown2024-01-162-4/+4
| | | | | | | | | | | | | | | | | | | | | | | We currently implement build-time assertions via a mechanism that generates a call to an undefined external function that will cause the link to fail unless the compiler can prove that the asserted condition is true (and thereby eliminate the undefined function call). This assertion mechanism can be used for conditions that are not amenable to the use of static_assert(), since static_assert() will not allow for proofs via dead code elimination. Add __attribute__((error(...))) to the undefined external function, so that the error is raised at compile time rather than at link time. This allows us to provide a more meaningful error message (which will include the file name and line number, as with any other compile-time error), and avoids the need for the caller to specify a unique symbol name for the external function. Change the name from linker_assert() to build_assert(), since the assertion now takes place at compile time rather than at link time. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [libc] Make static_assert() available via assert.hassertMichael Brown2024-01-162-4/+4
| | | | | | | Expose static_assert() via assert.h and migrate link-time assertions to build-time assertions where possible. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [intel] Add PCI ID for I219-LM (23)Christian Helmuth2023-12-211-0/+1
| | | | | | Successfully tested on FUJITSU LIFEBOOK U7413. Signed-off-by: Christian Helmuth <christian.helmuth@genode-labs.com>
* [pci] Check that ECAM configuration space is within reachable memoryMichael Brown2023-11-021-0/+9
| | | | | | | | | | | | | | | | | Some machines (observed with an AWS EC2 m7a.large instance) will place the ECAM configuration space window above 4GB, thereby making it unreachable from non-paged 32-bit code. This problem is currently ignored by iPXE, since the address is silently truncated in the call to ioremap(). (Note that other uses of ioremap() are not affected since the PCI core will already have checked for unreachable 64-bit BARs when retrieving the physical address to be mapped.) Fix by adding an explicit check that the region to be mapped starts within the reachable memory address space. (Assume that no machines will be sufficiently peverse to provide a region that straddles the 4GB boundary.) Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Cache ECAM mapping errorsMichael Brown2023-11-021-2/+4
| | | | | | | | | When an error occurs during ECAM configuration space mapping, preserve the error within the existing cached mapping (instead of invalidating the cached mapping) in order to avoid flooding the debug log with repeated identical mapping errors. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Handle non-zero starting bus in ECAM allocationsMichael Brown2023-11-021-0/+1
| | | | | | | | | | | | | The base address provided in the PCI ECAM allocation within the ACPI MCFG table is the base address for the segment as a whole, not for the starting bus within that allocation. On machines that provide ECAM allocations with a non-zero starting bus number (observed with an AWS EC2 m7a.large instance), this will result in iPXE accessing the wrong memory addresses within the ECAM region. Fix by adding the appropriate starting bus offset to the base address. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Force completion of ECAM configuration space writesMichael Brown2023-11-011-1/+10
| | | | | | | | | | | | | | | | | | | | | The PCIe specification requires that "processor and host bridge implementations must ensure that a method exists for the software to determine when the write using the ECAM is completed by the completer" but does not specify any particular method to be used. Some platforms might treat writes to the ECAM region as non-posted, others might require reading back from a dedicated (and implementation-specific) completion register to determine when the configuration space write has completed. Since PCI configuration space writes will never be used for any performance-critical datapath operations (on any sane hardware), a simple and platform-independent solution is to always read back from the written register in order to guarantee that the write must have completed. This is safe to do, since the PCIe specification defines a limited set of configuration register types, none of which have read side effects. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [iphone] Add missing va_start()/va_end() around reused argument listMichael Brown2023-10-241-0/+2
| | | | | | | | | | | | | | The ipair_tx() function uses a va_list twice (first to calculate the formatted string length before allocation, then to construct the string in the allocated buffer) but is missing the va_start() and va_end() around the second usage. This is undefined behaviour that happens to work on some build platforms. Fix by adding the missing va_start() and va_end() around the second usage of the variadic argument list. Reported-by: Andreas Hammarskjöld <andreas@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [netdevice] Allocate private data for each network upper-layer driverMichael Brown2023-09-131-1/+3
| | | | | | | | | | | | | | | | | Allow network upper-layer drivers (such as LLDP, which attaches to each network device in order to provide a corresponding LLDP settings block) to specify a size for private data, which will be allocated as part of the network device structure (as with the existing private data allocated for the underlying device driver). This will allow network upper-layer drivers to be simplified by omitting memory allocation and freeing code. If the upper-layer driver requires a reference counter (e.g. for interface initialisation), then it may use the network device's existing reference counter, since this is now the reference counter for the containing block of memory. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [netdevice] Remove netdev_priv() helper functionMichael Brown2023-09-1322-182/+182
| | | | | | | | | | 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>
* [virtio] Fix implementation of vpm_ioread32()Alexander Eichner2023-08-221-2/+2
| | | | | | | | | | | The current implementation of vpm_ioread32() erroneously reads only 16 bits of data, which fails when used with the (stricter) virtio device emulation in VirtualBox. Fix by using the correct readl()/inl() I/O wrappers. Reworded-by: Michael Brown <mcb30@ipxe.org> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [linux] Set a default MAC address for tap devicesMichael Brown2023-07-051-0/+5
| | | | | | | | Avoid the need to always specify a local MAC address on the command line by setting a default hardware MAC address (using the same default address as for slirp devices). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [linux] Fix error control flow in af_packet_nic_probe()Michael Brown2023-07-051-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [linux] Fix error control flow in tap_probe()Michael Brown2023-07-051-1/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [console] Avoid overlap between special keys and Unicode charactersMichael Brown2023-07-041-2/+2
| | | | | | | | | | | | | | The special key range (from KEY_MIN upwards) currently overlaps with the valid range for Unicode characters, and therefore prohibits the use of Unicode key values outside the ASCII range. Create space for Unicode key values by moving the special keys to the range immediately above the maximum valid Unicode character. This allows the existing encoding of special keys as an efficiently packed representation of the equivalent ANSI escape sequence to be maintained almost as-is. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Always poll for TX completionsdell3440bMichael 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>
* [intel] Add workaround for I210 reset hardware bugsMatt Parrella2023-03-142-2/+24
| | | | | | | | | | | | | | | | | | The Intel I210's packet buffer size registers reset only on power up, not when a reset signal is asserted. This can lead to the inability to pass traffic in the event that the DMA TX Maximum Packet Size (which does reset to its default value on reset) is bigger than the TX Packet Buffer Size. For example, an operating system may be using the time sensitive networking features of the I210 and the registers may be programmed correctly, but then a reset signal is asserted and iPXE on the next boot will be unable to use the I210. Mimic what Linux does and forcibly set the registers to their default values. Signed-off-by: Matt Parrella <parrella.matthew@gmail.com>
* [intelx] Add PCI IDs for Intel 82599 10GBASE-T NICForest Crossman2023-03-051-0/+1
| | | | Signed-off-by: Forest Crossman <cyrozap@gmail.com>
* [iscsi] Limit maximum transfer size to MaxBurstLengthiscsicapMichael Brown2023-02-161-0/+4
| | | | | | | | | | | | | | | | | We currently specify only the iSCSI default value for MaxBurstLength and ignore any negotiated value, since our internal block device API allows only for receiving directly into caller-allocated buffers and so we have no intrinsic limit on burst length. A conscientious target may however refuse to attempt a transfer that we request for a number of blocks that would exceed the negotiated maximum burst length. Fix by recording the negotiated maximum burst length and using it to limit the maximum number of blocks per transfer as reported by the SCSI layer. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [eisa] Check for system board presence before probing for slotseisaMichael Brown2023-02-101-0/+8
| | | | | | | | | | | | | | | EISA expansion slot I/O port addresses overlap space that may be assigned to PCI devices, which can lead to register reads and writes with unwanted side effects during EISA probing. Reduce the chances of performing EISA probing on PCI devices by probing EISA slot vendor and product ID registers only if the EISA system board vendor ID register indicates that the motherboard supports EISA. Debugged-by: Václav Ovsík <vaclav.ovsik@gmail.com> Tested-by: Václav Ovsík <vaclav.ovsik@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Do not attempt to drive PCI bridge devicesefibridgeMichael Brown2023-02-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | The "bridge" driver introduced in 3aa6b79 ("[pci] Add minimal PCI bridge driver") is required only for BIOS builds using the ENA driver, where experimentation shows that we cannot rely on the BIOS to fully assign MMIO addresses. Since the driver is a valid PCI driver, it will end up binding to all PCI bridge devices even on a UEFI platform, where the firmware is likely to have completed MMIO address assignment correctly. This has no impact on most systems since there is generally no UEFI driver for PCI bridges: the enumeration of the whole PCI bus is handled by the PciBusDxe driver bound to the root bridge. Experimentation shows that at least one laptop will freeze at the point that iPXE attempts to bind to the bridge device. No deeper investigation has been carried out to find the root cause. Fix by causing efipci_supported() to return an error unless the configuration space header type indicates a non-bridge device. Reported-by: Marcel Petersen <mp@sbe.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [realtek] Explicitly disable VLAN offloadMichael Brown2023-02-012-2/+7
| | | | | | | | | | | | Some cards seem to have the receive VLAN tag stripping feature enabled by default, which causes received VLAN packets to be misinterpreted as being received by the trunk device. Fix by disabling VLAN tag stripping in the C+ Command Register. Debugged-by: Xinming Lai <yiyihu@gmail.com> Tested-by: Xinming Lai <yiyihu@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [golan] Add new PCI ID for NVIDIA BlueField-3 network deviceMohammed Taha2023-01-231-0/+1
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [efi] Bind to only the topmost instance of the SNP or NII protocolssnploopMichael 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>
* [ena] Allocate an unused Asynchronous Event Notification Queue (AENQ)aenqAlexander Graf2023-01-182-0/+139
| | | | | | | | | | | | | | We currently don't allocate an Asynchronous Event Notification Queue (AENQ) because we don't actually care about any of the events that may come in. The ENA firmware found on Graviton instances requires the AENQ to exist, otherwise all admin queue commands will fail. Fix by allocating an AENQ and disabling all events (so that we do not need to include code to acknowledge any events that may arrive). Signed-off-by: Alexander Graf <graf@amazon.com>
* [netdevice] Allow duplicate MAC addressesMichael Brown2023-01-153-3/+56
| | | | | | | | | | | | | | | | | | | | | | | | Many laptops now include the ability to specify a "system-specific MAC address" (also known as "pass-through MAC"), which is supposed to be used for both the onboard NIC and for any attached docking station or other USB NIC. This is intended to simplify interoperability with software or hardware that relies on a MAC address to recognise an individual machine: for example, a deployment server may associate the MAC address with a particular operating system image to be deployed. This therefore creates legitimate situations in which duplicate MAC addresses may exist within the same system. As described in commit 98d09a1 ("[netdevice] Avoid registering duplicate network devices"), the Xen netfront driver relies on the rejection of duplicate MAC addresses in order to inhibit registration of the emulated PCI devices that a Xen PV-HVM guest will create to shadow each of the paravirtual network devices. Move the code that rejects duplicate MAC addresses from the network device core to the Xen netfront driver, to allow for the existence of duplicate MAC addresses in non-Xen setups. 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>
* [intel] Add PCI ID for I219-V and -LM 16,17Christian I. Nilsson2022-11-151-0/+4
| | | | | Signed-off-by: Christian I. Nilsson <nikize@gmail.com> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Backup and restore standard config space across PCIe FLRMichael Brown2022-11-131-2/+7
| | | | | | | | | | | | | | The behaviour of PCI devices across a function-level reset seems to be inconsistent in practice: some devices will preserve PCI BARs, some will not. Fix the behaviour of FLR on devices that do not preserve PCI BARs by backing up and restoring PCI configuration space across the reset. Preserve only the standard portion of the configuration space, since there may be registers with unexpected side effects in the remaining non-standardised space. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [pci] Allow PCI config space backup to be limited by maximum offsetMichael Brown2022-11-134-10/+13
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
generated by cgit (git 2.34.1) at 2025-02-24 05:16:19 +0000