posting here my journey and experiences while flashing these cards, following the guide in the OP and some other people doing it on Dell cards, and adapting it to current day firmware and some quirks I encountered
I bought dell-branded cards so they had dell firmware on them.
this is the firmware version I started with:
ethtool -i enp3s0f0np0
driver: i40e
version: 6.14.6-2-default
firmware-version: 9.00 0x8000cfed 21.5.9
expansion-rom-version:
bus-info: 0000:03:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes
my current firmware version causes errors in the nvmupdate tool and prints
The configuration file could not be opened/read or a syntax error was discovered in the file
the firmware version must be updated first, update card to version
22.5.7
22.5.7, A00
01 dic 2023
https://www.dell.com/support/home/it-it/drivers/driversdetails?driverid=1R0W0
executing the linux bin in the terminal fails to find updates.
extract it to a folder and runn the nvmupdate64e tool from it.
this works and updates the card to the firmware version in the dell update package
sudo ./Network_Firmware_9NPPG_LN_22.0.9_A00.BIN --extract ./firmware
cd firmware
sudo ./nvmupdate64e
reboot the system
check what code your card is again (use right interface name, check with “ip a”)
ethtool -i enp3s0f0np0
driver: i40e
version: 6.14.6-2-default
firmware-version: 9.40 0x8000e9c2 21.5.9
expansion-rom-version:
bus-info: 0000:03:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes
Now it is time to crossflash the card to original Intel firmware.
Since I downloaded the Release__30.1.0.1 of the Intel Ethernet Adapter Complete Driver Pack, this is my nvmupdate.cfg
The name of the NVMimage and EEPID is changed, check the nvmupdate.cfg with all adapters
CURRENT FAMILY: 1.0.0
CONFIG VERSION: 1.14.0
BEGIN DEVICE
DEVICENAME: XL710
VENDOR: 8086
DEVICE: 1572
NVM IMAGE: X710DA2_9p54_CFGID7p2_J51959_Retail_8M.bin
EEPID: 8000FB65
REPLACES: 8000E9C2
OROM IMAGE: BootIMG.FLB
RESET TYPE: REBOOT
END DEVICE
I used the same nvmupdate64e tool from the Dell software package (it is version 1.39.68.2), copied over in the folder with EFI tools (as I was originally trying to do this with EFI tools) I didn’t need to compile and install any drivers (OpenSUSE Tumbleweed), but also the person that wrote part of this guide ran the tool on debian 11 and also he did not need to compile anything.
./nvmupdate64e -rd
and after that is done and a reboot, I can see the firmware is changed and the sr-iov is now available. (I don’t really need it at the moment but I might as well have all I paid for)
Bonus information: one of the two cards I bought came pre-borked (shows up as “Intel(R) Ethernet Controller XL710 N/A(N/A) 154B 00:001” as others online noticed these cards show up when borked), and I managed to resuscitate it by copying the firmware from the good card with a SPI flasher tool (a device that can read and write the flash chip) and then I used a DOS tool called eeupdate.exe (you can find it on github together with the readme that shows the options) to change the MAC addresses of the two ports so it is using its original MAC address again. In theory there is also eeupdate64e and lanconf64e for linux from some firmware update packages floating around
Bonus information 2: the Intel X710 has a feature called LLDP agent, where the card’s controller will intercept and handle independently the LLDP packets sent from the switch, not allowing them to reach the OS level. This will confuse Linux’s LACP bonding. So LACP bonding on Linux will be unstable if this feature is active. It must be disabled from the UEFI setup of the adapter in NIC Configuration menu (or in its bios setup menu maybe, I don’t test this). I don’t know if this is also an issue for Windows or other operating systems. It also may be possible to disable it in the card from inside the Linux system by sending the following command (also not tested). The command does not save the setting and must be sent on every system reboot.
sudo ethtool --set-priv-flags <interface name> disable-fw-lldp on
it can be automated with a udev rule
/etc/udev/rules.d/10-disable-fw-lldp.rules
ACTION=="add", SUBSYSTEM=="net", ENV{INTERFACE}=="*", DRIVERS=="i40e", PROGRAM="/usr/sbin/ethtool --set-priv-flags $name disable-fw-lldp on"
you can verify the settings are set with
ethtool --show-priv-flags enp1s0f0
and it will print all flags and the “disable-fw-lldp” flag will be “on” as it must be
From my tests, the UEFI setting is remembered on reboot, so it’s the preferred way.
Bonus Information 3: The card’s boot ROM (the UEFI/PXE boot and card settings menu under UEFI/BIOS) does not work on my Asrock a520M-HDV and Asrock B550 Pro4 boards if the “Above 4G decoding” option is enabled in the UEFI settings. This does not happen if I have another card in a pcie slot (either a GPU or a network card Asrock B550 Pro4. Seems others had similar issues see Cannot PXEboot with Intel X710 NIC (pxe structure was not found in UNDI driver code segment) - Intel Community
Thankfully I only need to use the boot ROM for disabling the LLDP agent. This is is done once and then I can enable “Above 4G decoding” again.
Bonus information 4: I have replaced the old thermal paste with a Thermal Grizzly Minus Pad 8 thermal pad, as this is a relatively low power device (i.e. not a CPU/GPU). The pad is more rugged and will last longer than paste without needing maintenance.
