I would try it without the live system. Live Kernels have, to my knowledge, a lot more stuff enabled then the kernel you normally install. It might be that something is interfering with the intel driver.
1 Like
That was good thinking. You made me dig for an external USB drive where I could install full distro. And it worked. Flashing was successful. Thank you.
For a moment it gave me a scare. While card was recognized after reboot no link could be established. Flash removed unlock for non-Intel SFP+ transceivers. Applying unlock again solved that issue.
2 Likes
Hi there,
Thanks a million for the guidance on how to flash, it’s super helpful. In fact I’m facing the same problem: I bought a 10Getek X550-T1 NIC and I didn’t succeed to far in flashing the nvm. Current NVM is v2.10, it’s very old whereas Intel proposes the v3.60.
For the context I already spent days in trying to find a solution, withtout success. The only thing that worked is the ROM flashing via BootUtil tool. Note that I do my nvm/ROM flashing attempts under UEFI Shell via USB stick to avoid drivers/incompatibility issues under my Win11. So I used the Bootutil.efi to update the ROM. I tried the same with nvmupdate64e.efi but still facing the same “Update not available” message again and again.
I tried to customize my nvmupdate.cfg with the template you propose but still the same problem.
Questions:
-
As my NIC is a X550-T1, I looked at the PBA ref on Intel site and it’s “H92506”. So in the latest nvmupdate package for the X550, the v29, the only .bin file mentioning “H92506” is “Retail_SagePond_B0_AT_SP_noMNG_H92506_3p60.bin”, but as there are other .bins in the package I’m not 100% sure. These other .bins don’t metion at all “X550” or “H92506”. This to say that I’m not sure that I’m calling the right .bin in my .cfg file.
-
If I use the “-f” command with “nvmupdate64e.efi -f”, it forces the flash successfully BUT it only flashes the ROM, not the NVM! And it’s the only wait to get a “Update available”.
-
As I already flashed the ROM with the most up to date version, does it really make sense to have in my .cfg the “OROM IMAGE: BootIMG.FLB” line?
-
As I said my PBA is supposed to be “H92506” BUT when I do a nvmupdate64e.efi -i -l to have the full details of the card, the PBA appears as “000000-000” in the recap which isn’t expected at all. So is that a source of mismatch when nvmupdate tries to compare NIC ref vs nvm version vs proposed .bin?
-
Should the “Retail_SagePond_B0_AT_SP_noMNG_H92506_3p60” .bin title include the real name of my card which is “Intel(R) Ethernet Controller X550-T1”? Or should I replace in the title “H92506” by “000000-000”?
-
My ETrackID is 80000A63, no problem with that.
-
Below is my .cfg based on your model:
CURRENT FAMILY: 1.0.0
CONFIG VERSION: 1.14.0
BEGIN DEVICE
DEVICENAME: Intel(R) Ethernet Controller X550-T1
VENDOR: 8086
DEVICE: 15D1
NVM IMAGE: Retail_SagePond_B0_AT_SP_noMNG_H92506_3p60.bin
OROM IMAGE: BootIMG.FLB
EEPID: 8000172B
REPLACES: 80000A63
RESET TYPE: POWER
END DEVICE
I’m pretty sure that the problem comes for my custom .cfg, but from what exactly? I’m just about to give up, I spent so much time on that 
. Thanks in advance!
Hmm that is weird, I would have thought that you should be able to just run the normal update process since your ETrackID is in the intel config. Have you tried a normal update like:
nvmupdate64e -u -l -o results.xml -b -c nvmupdate.cfg
Before using ./bootutil64e ?
I would try to get the card in recovery mode and start again with a regular update:
https://cdrdv2-public.intel.com/606286/606286_RecoveryMode_AppNote_Rev1.2.pdf
I never used EFI Image, if recovery does not work, can you install Linux on a external drive and follow the instructions from above an post the output? And don’t use a live Linux System 
Edit: I case you did a dump using a SPI-Flasher, then of course revert to your dump instead of using recovery
@mietzen > Thanks for your reply! I already tested nvmupdate64e -u -l -o results.xml -b -c nvmupdate.cfg indeed with no success. Regarding the recovery mode the problem is that you can’t activate it manually…
Regarding Linux, I’m a pure newbie on that domain so it will be a nightmare to use it.
BTW, making progress on investigations: when running full inventory via nvmupdate64e.efi -u -l -o results.xml -b -c nvmupdate.cfg I obtain the following:
[00:007:00:00]: Intel(R) Ethernet Controller X550-T1
Flash inventory started.
Shadow RAM inventory started.
Shadow RAM inventory finished.
Flash inventory finished.
OROM inventory started.
OROM inventory finished.
Update
[00:007:00:00]: Intel(R) Ethernet Controller X550-T1
Flash: The device is running in non-secure mode - skipping update. Update security revisions
[00:007:00:00]: Intel(R) Ethernet Controller X550-T1
Skipping update minimum security revisions.
Update VPD with VPD template
[00:007:00:00]: Intel(R) Ethernet Controller X550-T1
Skipping VPD update with VPD template.
Checking update availability for next tool run.
Post update inventory
[00:007:00:00]: Intel(R) Ethernet Controller X550-T1
No Flash update taken - skipping inventory.
No OROM update taken - skipping inventory.
Question: is above “Flash: The device is running in non-secure mode - skipping update. Update security revisions” the source of the problem? Sounds to be! Do you confirm?
From Intel doc “Minimum Security Revision Control for Intel® Ethernet Products”:
-
Firmware updates for Intel Ethernet devices have a Security Revision number (SRev). The SRev might be updated as part this NVM release…
-
…The NVM update process blocks the update if the supplied NVM has a lower SRev than the MinSRev value of the NVM currently loaded on the device…"
-
…Once the MinSRev is increased, this is irreversible. NVM downgrades attempting to install a lower SRev than the current MinSRev will be rejected by the device. Although not recommended, leaving the MinSRev field unmodified allows firmware downgrades from any version to any version.
Instructions from same Intel doc:
Download and extract the NVM Update Package for your device. Use the command line to update your device’s MinSRev. On Windows:
nvmupdatew64e -u -optinminsrev -l update.log -o update.xml -c nvmupdate.cfg
So in order to not lock my NVM to a too high MinSRev number, I guess I should use an old nvmupdate package to have flexibility in case of NVM restore, right? In any case looks like my X550 has no MinSRev specified yet today, that’s why it looks to be in « non-secure mode ». Is that correct understanding?
Sounds like a good idea. The oldest version seems to be NVM v2.20. Let us know how it went.
Yep, as my current NVM is v2.10, the idea would be to activate the MinSrev with v2.20 indeed. Will try this evening.
Unfortunately it didn’t work, still facing this " The device is running in non-secure mode" message. The command to set a MinSRev has no effect. Just don’t know how to move from “non-secure” to “secure” mode. I searched the web with no success. I’m so pissed off and tired with that
Unfortunately, my Dell XL710 fails to update. Everything worked smoothly until the ./nvmupdate64e -rd, which ended with:
02) Intel(R) Ethernet Converged N/A(N/A) 1572 00:001 Update failed
Network Adapter X710
Tool execution completed with the following status: An error occurred when updating a firmware module.
After rebooting, I was getting failure errors in dmesg and in ./nvmupdate64e -I. Interestingly, though, after powering off and switching the system back on, dmesg is healthy again, and I can do an ./nvmupdate64e -rd again, although it fails again. Any ideas?
Intel(R) Ethernet NVM Update Tool
NVMUpdate version 1.40.5.5
Copyright(C) 2013 - 2023 Intel Corporation.
Config file will not be read.
Unsupported device found - DeviceId: 1A1C.
Inventory
[00:001:00:00]: Intel(R) Ethernet Converged Network Adapter X710
Flash inventory started.
Shadow RAM inventory started.
Shadow RAM inventory finished.
Flash inventory finished.
OROM inventory started.
OROM inventory finished.
[00:001:00:01]: Intel(R) Ethernet Converged Network Adapter X710
Device already inventoried.
[00:001:00:00]: Intel(R) Ethernet Converged Network Adapter X710
Vendor : 8086
Device : 1572
Subvendor : 8086
Subdevice : 0006
Revision : 2
LAN MAC : F8xxxxxxxxxx
Alt MAC : 000000000000
SAN MAC : FFFFFFFFFFFF
ETrackId : 8000D95B
SerialNumber : B0DAxxxxxxxxxxxx
NVM Version : 9.32(9.20)
PBA : K10958-001
VPD status : Valid
VPD size : 307
NVM update : No config file entry
checksum : Valid
OROM update : No config file entry
CIVD : 1.3429.0
PXE : 1.1.44, checksum Valid
EFI : 4.9.70, checksum None
[00:001:00:01]: Intel(R) Ethernet Converged Network Adapter X710
Vendor : 8086
Device : 1572
Subvendor : 8086
Subdevice : 0000
Revision : 2
LAN MAC : F8xxxxxxxxxx
Alt MAC : 000000000000
SAN MAC : FFFFFFFFFFFF
ETrackId : 8000D95B
SerialNumber : B0xxxxxxxxxxxxxx
NVM Version : 9.32(9.20)
PBA : K10958-001
VPD status : Valid
VPD size : 307
NVM update : No config file entry
checksum : Valid
OROM update : No config file entry
CIVD : 1.3429.0
PXE : 1.1.44, checksum Valid
EFI : 4.9.70, checksum None
root@proxmox:~/drivers/NVMUpdatePackage/700_Series/700Series/Linux_x64# ./bootutil64e
Intel(R) Ethernet Flash Firmware Utility
BootUtil version 1.40.05.0
Copyright (C) 2003-2023 Intel Corporation
Type BootUtil -? for help
Port Network Address Location Series WOL Flash Firmware Version
==== =============== ======== ======= === ============================= =======
1 0025xxxxxxxxx 0:31.6 Gigabit N/A FLASH Not Present
2 F8F2xxxxxxxxx 1:00.0 40GbE NO UEFI,PXE Enabled 1.1.44
3 F8F2xxxxxxxxx 1:00.1 40GbE N/A UEFI,PXE Enabled 1.1.44
ethtool -i ens1f0np0
driver: i40e
version: 6.8.4-2-pve
firmware-version: 9.20 0x8000d95b 1.3429.0
expansion-rom-version:
bus-info: 0000:01:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes
EDIT:
I am looking into Dell’s own package and have narrowed this card down to this entry in their nvmupdate.cfg:
CURRENT FAMILY: 22.5.7
CONFIG VERSION: 1.14.0
;////////////////////////////////////////////
; Fortville
; Eagle Fountain DP
BEGIN DEVICE
DEVICENAME: Intel(R) Ethernet Converged Network Adapter X710 (2P)
VENDOR: 8086
DEVICE: 1572
SUBVENDOR: 8086
SUBDEVICE: 0006
;REVISION: 0001
PXE: 1.1.44
EFI: 4.9.83
OROM DOWNGRADE: TRUE
OROM IMAGE: BootIMG.FLB
IMAGE DOWNGRADE: TRUE
;NVM IMAGE: h54188.bin
NVM IMAGE: BootIMG.FLB
;EEPID: 800017C0
EEPROM MAP: Y5M7N.txt
RESET TYPE: REBOOT
END DEVICE
What’s odd here is the commented-out NVM bin image (file is not even in the package) and BootIMG.FLB is used instead in both NVM and OROM. OROM stands for Option ROM, my understanding is that it is responsible for the options that Dell comes pre-configured with (like SR-IOV disabled) and the EEPROM map accompanies it so a single binary file can be used for both Option ROM and NVM. Although I am just guessing.
EDIT: I cannot update that card with Dell firmware as well. Their nvmupdate64e detects the card as Dell’s own and suggests an update, but it ends up with same exact error. Not sure if this is due to the Flash that had been manually updated with bootutil64e — I tried restoring it using backup it saved during the update, but that actually put the card into Recovery mode and subsequently bootutil64e could not initialize the device anymore. Luckily I was able to bring it back using the original complete FLB that I backed up with nvmupdate64e — although this one was saved after I had already updated the flash, so I am effectively stuck now. The card works, but cannot update it with any version.
EDIT: I was able to downgrade Flash using the Dell firmware package that matched the version currently installed. However, trying to update to most recent Dell firmware still fails with “OROM: One of the module updates failed - skipping update.”
Sorted it out. Had to use EFI nvmupdate version.
I’d update your GitHub instructions: EFI method is system & Intel driver independent, doesn’t require additional DKMS steps and is way faster, like at least 10 times and in not exaggerating.
Thanks! I was also having lots of issues with a Dell X710-DA2 Y5M7N, nvmupdate hung for an hour leaving it in recovery mode but I’d taken flash backups so used a hardware flasher to get back to a known state.
In EFI it worked in mere minutes and it’s now on the currently latest 29.1 release.
edit: just to add for my X710-DA2 even though it has an 8MB chip, only half is used *_Retail_8M.bin left one port identifying as OCP 3.0.
As of release 29.1 I’ve used X710DA2_9p50_CFGID7p2_OEMGEN_K97470.bin (8000F13D) and both ports identify as expected, waiting on some modules to verify both are working, but don’t be afraid to use 4MB images on 8MB chips.
edit2: as an earlier reply I needed HPI_EagleFountain_*_000.bin and now both ports are working (needed a cold boot)
I was actually going to use the 4MB Eagle Fountain as well, considering that Dells firmware nvmupdate.cfg has a comment saying “Eagle Fountain” for this particular card, and that the HPI model is basically HP’s equivalent of our Dell card. Except for the NVRAM size, that is. Still, my backed up firmware also was only 4MB, rest was zeroes, so it should ve a good match.
Problem is that HPI firmware has “40GbE” in the card name inside the bin file. I compared a lot of them and while differences are minuscule, they still exist.
I also removed the heatsink and we have x710-BM2 chip, which is a slightly newer version. We also have a 2 pin header, which adds extra serial pair functionality, which Intel added sometime 2015: https://cdrdv2-public.intel.com/800008/PCN113493-00.pdf . The retail H58362 PBA was later replaced again in 2018 with J11367, with only difference being a firmware upgrade: https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://cdrdv2-public.intel.com/804495/PCN115808-02.pdf&ved=2ahUKEwiMidWT5IeGAxXUIBAIHdPKDu4QFnoECBEQAQ&usg=AOvVaw2FH2fYHTifie9Uddn3FMUb
So we should be looking for X710DA2BLK or X710DA2 firmware with J11367 PBA. The PBA is provided in the firmware file, except it’s in Little-endian, so we’re searching for 1J3176 and the firmware for it is X710DA2_9p50_CFGID7p2_OEMGEN.bin and I believe this is the correct one to use in OEM cards like ours.
I flashed X710DA2_9p50_CFGID7p2_OEMGEN.bin and both ports were working, I just used the supplied 29.1 nvmupdate.cfg section, replacing the REPLACES line as required, so I also used EEPROM MAP: PF_Alloc_WOL_DIS.txt I figured there is a reason Intel include it.
However the firmware identifies as “XL710 40GbE Controller” when it’s a X710 with SPF+ ports, looking at X710DA2_9p50_CFGID7p2_OEMGEN_OO.bin it has 7H89500-00 = H79805 which is also on the links you’ve supplied, I’ve flashed that instead so the product name is as expected and both ports are working.
Ideally I’d like to be able to figure out why one port (furthest from motherboard) stays active when powered off but other than that it seems to be working as expected.
That’s probably because your WoL is enabled? You could see your BIOS settings if there’s something there.
I recently got one of these cards (Dell Intel X710-DA2 off ebay) and wanted to update it, and then unlock the modules.
Here is my nvmupdate.cfg
CURRENT FAMILY: 1.0.0
CONFIG VERSION: 1.14.0
;Release 19.3/19.4 to Release 20.0
BEGIN DEVICE
DEVICENAME: X710-DA2
VENDOR: 8086
DEVICE: 1572
NVM IMAGE: X710DA2_9p50_CFGID7p2_OEMGEN_K97470.bin
OROM IMAGE: BootIMG.FLB
EEPID: 8000F13D
REPLACES: 80003A2A
RESET TYPE: POWER
END DEVICE
trying to flash it using fd0:\EFI\TOOLS\nvmipdate64e.efi -rd -c nvmupdate.cfg I keep getting “The configuration file could not be opened/read, or a syntax error was discovered in the file.”
That was my initial thought which is why I kept “EEPROM MAP: PF_Alloc_WOL_DIS.txt” and as far as I can tell WOL is disabled; I see no option for it in Windows advanced device properties and UEFI/BIOS shows “WOL: NA”. I only need one port on the machine it matters on anyway so I can just use the other one.
If you aren’t already I’d suggest changing to the directory with the nvmupdate64e.efi, it could be that it’s looking the wrong place for nvmupdate.cfg
Don’t forget the BOOTUTIL64E.EFI step first but generally do something like:
fs0:
cd EFI\TOOLS
Then if required you can get your EEPID from nvmupdate64e.efi -i -l and amend it in the config file with edit nvmupdate.cfg
Finally flash with nvmupdate64e.efi -rd and cold boot the system with reset -c
The config I’ve used for Dell X710-DA2 Y5M7N as of release 29.1 (you’ll need to adjust the “REPLACES” line).
CURRENT FAMILY: 1.0.0
CONFIG VERSION: 1.14.0
;OO
BEGIN DEVICE
DEVICENAME: XL710
VENDOR: 8086
DEVICE: 1572
NVM IMAGE: X710DA2_9p50_CFGID7p2_OEMGEN_OO.bin
OROM IMAGE: BootIMG.FLB
EEPID: 8000F180
REPLACES: 8000F127
EEPROM MAP: PF_Alloc_WOL_DIS.txt
RESET TYPE: REBOOT
END DEVICE