Posts 1-38 and 40+ are informational. See post #39 for the good stuff.
If you have the i226-V nic controller, check the firmware version you have.
dmesg | grep igc
Mine is v2.17, a rev or so behind whatever the latest is.
Some bin versions here
https://github.com/BillyCurtis/Intel-i226-V-NVM-Firmware/blob/main/README.md
I see some users posting issues about i210 with igb driver from freeBSD. Not sure about issues with i226, but many of the mini chinese pc's (N100 N150, etc) seem to be flashed with old firmware.
Well this message is timely.
2 days ago I swapped my usual Protectli box with a Lenovo M700 tiny to which I had added an m.2 i226 based ethernet port. Just checked firmware as per your message and mine has v2.17 firmware as well (see below).
[1] igc0: <Intel(R) Ethernet Controller I226-V> mem 0xdf100000-0xdf1fffff,0xdf200000-0xdf203fff irq 18 at device 0.0 on pci1
[1] igc0: EEPROM V2.17-0 eTrack 0x80000303
As it's working fine, I'm kinda reluctant to roll the dice on flashing new firmware.
Quote from: CGrisamore on August 31, 2025, 08:22:54 PMAs it's working fine, I'm kinda reluctant to roll the dice on flashing new firmware.
Exactly my thoughts when I researched this:
I have v2.13 and no problems whatsoever. As a matter of fact, Intel offers no firmware updates on their Intel Network Driver disk for these adapters. I have not seen a proper tool to actually flash I226 NICs. Apart from that: Which one should I use? 1 MByte or2 MByte?
And BTW: There are different chip types, like I226-V and I226-LM and also, different hardware revisions (early one are said to cause problems).
So, there might be a reason why Intel delegates those updates to the manufacturers, who should know which firmware is appropriate for their build-in specimens.
DELETED, double post...
In the context of post #1, if your 226-V is posing issues, like others have ran into with i210.
If it working ok now then leave it.
When might it become an issue? Who knows, maybe after an OS update, or you use a specific feature you never used before.
Release notes with the bin files would be helpful.
I looked at a bin in HxD, the 1MB v2.32 bin on that site is mostly padding, the bottom 2/3's is just FF.
The bundle below, for i210, are all 2MB bin files. I suspect 210 226 etc are all 2MB EEPROM.<-- was proven to be mixed bag.
More info:
Intel has a latest release bundle, it's dated Aug 21 2025, i226 and i210 are in it. Edit: they mention 226 in the notes (link), but the bundle does not appear to have 226 in it. Wow, Intel going down the tubes.
https://downloadmirror.intel.com/863589/readme.txt
https://www.intel.com/content/www/us/en/content-details/778690/intel-ethernet-controller-products-release-notes.html?DocID=778690
https://www.intel.com/content/www/us/en/download/15084/intel-ethernet-adapter-complete-driver-pack.html
hi, i checked and i have i226-V with 2.17-0 firmware. OPNsense 25.7-amd64. FreeBSD 14.3-RELEASE-p1
i am having issues with dhcp in i226-v ports exactly like this thread:
https://forum.opnsense.org/index.php?topic=47151.msg237219#msg237219
do you think going with other drivers could solve it?
thanks.
EDIT: I am sorry, the hardware is actually working fine, i tried the connection with a laptop with ubuntu and DHCP set an ip immediately. It seems it's my macbook pro which don't want to work...
This is an interesting post. How would you go about upgrading the drivers (for i226-v) using the .bin file?
Quote from: tn881023 on September 04, 2025, 11:54:39 AMThis is an interesting post. How would you go about upgrading the drivers (for i226-v) using the .bin file?
NMV bin is code loaded into device EEPROM, it's not the driver.
IGC is compiled into the bsd 14.3 kernel. I have no idea where that org got the code for IGC. Probably an ave to look into.
Since the controller is bound to IGC driver from kernel, one could unbind that driver and then do a dynamic load (kldload) of an Intel .ko driver to see if things get better.
Quote from: BrandyWine on September 04, 2025, 10:27:35 PM[...]
I have no idea where that org got the code for IGC. [...]
Most (if not all) drivers for Intel devices are provided by Intel. FreeBSD devs make few (if any) changes, so FreeBSD ends up with a lot of issues in common with Windows. The Linux drivers tend to get more third-party attention - there was a similar issue with the 82574/82579 (discrete/integrated Ethernet) years ago (~2011) that was fixed in Linux but persisted in Windows and FreeBSD.
Quote from: pfry on September 05, 2025, 02:00:39 AMQuote from: BrandyWine on September 04, 2025, 10:27:35 PM[...]
I have no idea where that org got the code for IGC. [...]
Most (if not all) drivers for Intel devices are provided by Intel. FreeBSD devs make few (if any) changes, so FreeBSD ends up with a lot of issues in common with Windows. The Linux drivers tend to get more third-party attention - there was a similar issue with the 82574/82579 (discrete/integrated Ethernet) years ago (~2011) that was fixed in Linux but persisted in Windows and FreeBSD.
Possibly so, but we need to prove the theory, compare Intel src code to the src code used by freeBSD org.
In the freeBSD 14.3 release notes it mentions a driver "fix", but I not finding the same from Intel site. Could just be lost in translation, but we need to validate it.
There's a lot of "NO" items for the 226-V
https://www.intel.com/content/www/us/en/support/articles/000096004/ethernet-products/gigabit-ethernet-controllers-up-to-2-5gbe.html
Has anyone actually done vlan tagging (802.1q) with a 226-V ?
Yes, of course I have.
Quote from: BrandyWine on September 05, 2025, 08:49:03 PMHas anyone actually done vlan tagging (802.1q) with a 226-V ?
My fanless Proxmox server got 4 i226-V (rev 04) NICs and it does do VLANs. Or are you referring to VLAN offloading (if that is a thing)?
Teh chart says
Perhaps word salad that makes no sense.
Teaming1* & VLAN2* Support = NO
Where vlan2* is
"Ethernet VLANs are virtual LANs that separate and isolate a physical network at the data link layer (OSI layer 2). 3rd party software is required."
So that says the 226v controller itself does not support .1q, but you can get .1q using 3rd party software? What's the software, is that the igc driver?
Quote from: patient0 on September 05, 2025, 09:13:59 PM[...] Or are you referring to VLAN offloading (if that is a thing)?
It's a thing, but what the chart refers to, who knows? The DPDK NIC feature overview (https://doc.dpdk.org/guides/nics/overview.html) makes no distinction between i225/i226 variations. Heck, it barely mentions the i226. (By the way, that's a good place to look for hardware features that are not effectively supported by... well, much of anything besides DPDK.)
The Intel feature chart seems to be irrelevant, at least where FreeBSD/OPNsense is concerned.
I am not 100% certain, but it seems the 226V/LM/IT are same controller with different firmware.
Almost all (if not all) of the low-end stuff that has 226 will have 226V. LM IT seems to be reserved for integrators that are registered with Intel at a certain level, more of an enterprise outfit.
Which rev 226 do you have "lspci"
I have rev4
Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
Some more tidbit info.
Find your 226 eeprom version "dmesg | grep igc"
Mine is 2.17-0
But looking for 226 info I come across a page where a Intel support person says "Upon checking, the latest NVM version for I226 is 2.25 and for I225 is 1.94."
That's from 2-13-2024
Reference: https://community.intel.com/t5/Ethernet-Products/I225-226-series-network-card-and-a-strange-mofcomp-or-reinstall/m-p/1572142
We need to find the latest for 226-V.
This is a 2nd online post I have seen where someone says the 226-V faults when under high load, note the version.
QuoteI have an Asus rugged board nuc (NUC13BRK) with two onboard Intel I226-V NICs with firmware version 2.17 that are getting random disconnects under load, and that are not working as I'd expect from quality Intel NICs under latest FreeBSD 14.2
So, every time I go and try and find updates for 226, I find recent Intel packages like this one below that covers lots of controllers, but never anything for 226 ?
I might be suspecting silicon issues with 226 and because of that Intel is not making updates.
Reference: https://www.intel.com/content/www/us/en/download/15755/intel-ethernet-connections-boot-utility-preboot-images-and-efi-drivers.html?product=1140
Quote from: BrandyWine on September 06, 2025, 11:48:49 PMBut looking for 226 info I come across a page where a Intel support person says "Upon checking, the latest NVM version for I226 is 2.25 and for I225 is 1.94."
That's from 2-13-2024
Reference: https://community.intel.com/t5/Ethernet-Products/I225-226-series-network-card-and-a-strange-mofcomp-or-reinstall/m-p/1572142
We need to find the latest for 226-V.
[...]
What tree are you actually barking at?
I just got a brand new system with:
igc0: <Intel(R) Ethernet Controller I226-V> mem 0x80800000-0x808fffff,0x80900000-0x80903fff at device 0.0 on pci1
igc0: EEPROM V2.25-0 eTrack 0x800003ad
So if that is the latest firmware it is the latest firmware.
I run it with FreeBSD 14.3, LACP across 2 ports, VLANs on top of that - absolutely no problem whatsoever.
So what really is the issue?
Kind regards,
Patrick
Ok, where can I get a NVM v2.25 ?
There wouldn't be anything past my 2.17 unless there was some fixing or some features added.
Your v2.25 is at least 19mo old, possibly older. My 2.17, from a device I just got recently, is way old NVM. I don't know if Intel flashes them before batch packaging, makes sense they would so that the end user (integrator) just needs to install it w/o worry of having to flash every device they install. My mini pc I just got is using 226's that are probably years old. When we upgrade OPNsense, which sometimes comes with newer OS and many times updated drivers in that OS, having updated hardware makes sense.
There's a lot of complaints going around with 226 and fbsd 14.3. There was some updating to igc in 14.3, so probably not working well with older NVM when using specific features. My mini pc is running ok, but I am not using a lot of features nor pushing it hard on network side.
If I can find an actual Intel v2.25 nvm, I will flash that to the nic chips (I have three 226's)
I need to contact Billy Curtis and ask about his posted i226 bin files. He has posted v2.27 and v2.32, two revs past your v2.25.
https://github.com/BillyCurtis/Intel-i226-V-NVM-Firmware
EDIT: From another usre post here on OPNsense forums, the version you see from "dmesg | grep [driver]" is showing in hex. Hence, v2.25 is hex 2.25, or 2.37 in decimal. So the actual version is 37. No matter what base we count in, it's going up. My 2.17 is actual version 2.23(decimal).
Here's all the NVM's in one zip file from Billy Curtis git page
https://github.com/BillyCurtis/Intel-I226-V-NVM-Firmware/archive/refs/heads/main.zip
I am trying to find at least one NVM version sourced from Intel to see if MD5/SHA will match what B.C. has posted, as a way to see if his posting of bin's are the real deal.
If any readers here have Intel link to any of the 226 NVM's, please post it.
Ok, some more progress, seems I have found a legit NVM v2.25
I found v2.25 2MB bin from VERSA site (https://support.versa-networks.com/support/solutions/articles/23000028082-csg150-i226-nic-nvm-update)
It's name is "FXVL_125C_V_2MB_2.25.bin"
This same bin is in the Billy Curtis download, same name.
When I MD5 them, same hash !!
I am confident this v2.25 is legit.
You can do the same to verify my data. I just added VERSA and BC to the filename to make distinction.
PS C:\Users\RiceCake\Downloads\i226> Get-FileHash .\* -Algorithm MD5
Algorithm Hash Path
--------- ---- ----
MD5 8198F8062CD702C89FF42153B306886C C:\Users\RiceCake\Downloads\i226\FXVL_125C_V_2MB_2.25.BC.bin
MD5 8198F8062CD702C89FF42153B306886C C:\Users\RiceCake\Downloads\i226\FXVL_125C_V_2MB_2.25.VERSA.bin
SEE POST #39
Here's a file grab.
An i226 bundle as a zip (https://intel226bucket.s3.us-east-1.amazonaws.com/i226.zip)
You can download to Windows and look at it, you can "curl -O https://intel226bucket.s3.us-east-1.amazonaws.com/i226.zip" from opnsense fw to get it onto the fw.
You can also just go grab all these files on your own.
In zip you will find:
1) The full set of Billy Curtis 1MB and 2MB NVM bin files, I believe they are all legit Intel bins
2) The v2.25 2MB bin from VERSA (same MD5 as the Billy Curtis v2.25 2MB bin)
3) the nvmupdate64e util for freeBSD (obtained from Intel 34.0 bundle download)
4) "Foxpond_Map_File_v01.txt" taken from the Intel 34.0 bundle download, from the i225 NVM folder for freeBSD
5) "nvmupdate.cfg" taken from the Intel 34.0 bundle download, from the i225 NVM folder for freeBSD
6) "333909_NVMUpdateTool-FreeBSD_Rev1.4.pdf" is Intel's how-to-use the nvmupdate64e utility
7) and a "readme" file from the Intel bundle, just shows some info about using nvmupdate64e util
Would need to modify #4 and #5 for the i226, which I am looking into.
And as noted in the PDF, you can update devices individually, so since I have three 226's on my mini PC and I am only using two know, I will muck around with the 3rd one to update it's NVM, and then move my LAN or WAN to that 3rd nic. So we have room to play.
Quote from: Patrick M. Hausen on September 06, 2025, 11:59:51 PMigc0: EEPROM V2.25-0 eTrack 0x800003ad
TY Patrick. I needed the 2.25 eTrack ID for 226 cfg file.
Here's what I learned today. NVM v2.17 was confirmed as being a problem NVM, dropping connection stuff. I don't know if prior NVM's had same issue or not. I am running v2.17(hex), so I need to upgrade, will go v2.25 or newer.
Here's the start of cfg file, main section is still i225, but the eeprom up top if for i226
SEE POST #39
EEPROM V2.17-0 eTrack 0x80000308
EEPROM V2.25-0 eTrack 0x800003ad
CURRENT FAMILY: 1.0.0
CONFIG VERSION: 1.20.0
; NIC device
BEGIN DEVICE
There are at least these unknowns:
1. Which SUBDEVICE maps to which size version (for I225, we can see it is 2 = 1 MByte and 1 = 2 MByte, but I know that SUBDEVICE 0 exists for I226-V, see below).
2. The MAP file pointer offsets for I226.
3. Any older eTrack IDs for each of the 2.13, 2.14, 2.17, 2.22, 2.25, 2.27 and 2.32 versions that obviously exist.
I added 2.13, because I have that:
[1] igc0: EEPROM V2.13-0 eTrack 0x80000284
igc0@pci0:2:0:0: class=0x020000 rev=0x04 hdr=0x00 vendor=0x8086 device=0x125c subvendor=0x8086 subdevice=0x0000
vendor = 'Intel Corporation'
device = 'Ethernet Controller I226-V'
class = network
subclass = ethernet
On another machine, I saw this (also with subdevice 0):
[1] igc0: EEPROM V2.14-0 eTrack 0x80000290
On a side note, I225-V is not always DEVICE 15F2:
[1] igc0: EEPROM V1.57-0 eTrack 0x80000185
igc0@pci0:2:0:0: class=0x020000 rev=0x03 hdr=0x00 vendor=0x8086 device=0x15f3 subvendor=0x8086 subdevice=0x0000
vendor = 'Intel Corporation'
device = 'Ethernet Controller I225-V'
class = network
subclass = ethernet
Great info.
I am not 100% if 226V is 1MB or 2MB. Online docs say most 226's are 2MB versions but 1MB does exist. Will need to investigate subdevice number. Mine is the 00000. I will flash my igc2 that I am not usins with the 2MB bin and see what happens, if there's only 1MB prom then it's gonna complain, etc.
Edit: from some intel docs, the 2MB version of i226 has extra features, PXE being one of them. If your 226 has PXE then it has to be the 2MB version. 226-V is bottom barrel, 226-IT 226-LM are the "more advanced" chips, perhaps just because they support more features, which presumably means a 2MB prom.
Here's almost-done cfg file, need to investigate the map file, the one listed below is the 225 map file but it only has alt MAC entry.
Map file is optional.
I might take bin file into a better tool like Ghidra to investigate it further.
Here's a must read tutorial on using nvmupdate64e util (http://tmei-net.com/technology-sharing/how-do-use-intel-ethernet-nvm-update-tool.html)
To avoid any non-expected updating of all 3 of my 226's, I will use the MAC switch, and the same MAC must be in the cfg file, this limits what can be updated.
Also, the must read tutorial suggests cfg file not need etid as the took should pull etid from the bin file.
EEPROM Map file is not needed.
cfg starts at "CURRENT FAMILY", the stuff above that is just nic info. etid is that last two hex values.
EEPROM V1.57-0 eTrack 0x8000[b]0185[/b] for i225-V , post #23
EEPROM V2.13-0 eTrack 0x8000[b]0284[/b] i226V
EEPROM V2.14-0 eTrack 0x8000[b]0290[/b] i226V
EEPROM V2.17-0 eTrack 0x8000[b]0308[/b] i226V
EEPROM V2.25-0 eTrack 0x8000[b]03ad[/b] i226V
<Instance vendor="8086" device="125C" subdevice="0000" subvendor="8086" bus="2" dev="0" func="0" PBA="G23456-000" port_id="Port 1 of 1" display="Intel(R) Ethernet Controller I226-V">
<Module type="NVM" version="80000308" update="0">
CURRENT FAMILY: 1.0.0
CONFIG VERSION: 1.20.0
; NIC device
BEGIN DEVICE
DEVICENAME: Intel(R) Ethernet Controller I226-V
VENDOR: 8086
DEVICE: 125C
SUBVENDOR: 8086
SUBDEVICE: 0000
NVM IMAGE: FXVL_125C_V_2MB_2.25.VERSA.bin
EEPID: 800003ad
RESET TYPE: REBOOT
REPLACES: 80000308
END DEVICE
225 map file, looks like 11 values in the 0x37 block.
EEPROM MAP FILE VERSION: 1.0.0
BEGIN OVERWRITE
BEGIN POINTER
0x37 0x00 ;Alternate MAC Address value 0
0x37 0x01 ;Alternate MAC Address value 1
0x37 0x02 ;Alternate MAC Address value 2
0x37 0x03 ;Alternate MAC Address value 3
0x37 0x04 ;Alternate MAC Address value 4
0x37 0x05 ;Alternate MAC Address value 5
0x37 0x06 ;Alternate MAC Address value 6
0x37 0x07 ;Alternate MAC Address value 7
0x37 0x08 ;Alternate MAC Address value 8
0x37 0x09 ;Alternate MAC Address value 9
0x37 0x0A ;Alternate MAC Address value 10
0x37 0x0B ;Alternate MAC Address value 11
END POINTER
END OVERWRITE
I am all set up to flash in v2.25 bin onto my unused 226 nic. Will do it later tonight. If it flashes ok then I will setup another cfg to flash in v2.32 bin.
Quote from: Patrick M. Hausen on September 06, 2025, 11:59:51 PMSo if that is the latest firmware it is the latest firmware.
I run it with FreeBSD 14.3, LACP across 2 ports, VLANs on top of that - absolutely no problem whatsoever.
For the 225/226-V chips, I think these net features (including .1q) come from outside the NVM code. I could be wrong, but the datasheet for 225/226 has a lot of "no" for net features in -V chips.
Following. I think I have the same miniPC as you with the same nics
Quote from: raberrio on September 09, 2025, 07:30:59 PMFollowing. I think I have the same miniPC as you with the same nics
If your 226's are vendor="8086" device="125C" subdevice="0000", then yes, same devices (nics). Actual mini pc not of concern here, we are way too low level for that.
For these low budget china stuff there's a lot of "OEM to fill in" entries for various things, as seen by using dmidecode. IIRC, my 226's have missing serial numbers which I think is a field used by integrators to track their products for support reasons.
Quote from: meyergru on September 09, 2025, 11:24:45 AMOn a side note, I225-V is not always DEVICE 15F2
Well, 225-V for all rev's are supposed to be 15F3, never 15F2. 15F2 is the LM version.
(https://i.postimg.cc/rmfgNkzz/1cf1d526d429a7c9db2570ffe19283d21cb5d876-2-690x287.png)
Quote from: BrandyWine on September 10, 2025, 12:21:05 AMQuote from: meyergru on September 09, 2025, 11:24:45 AMOn a side note, I225-V is not always DEVICE 15F2
Well, 225-V for all rev's are supposed to be 15F3, never 15F2. 15F2 is the LM version.
I only noted that, because your nvmupdate.cfg listed only 15F2 for the I225-V.
Quote from: meyergru on September 10, 2025, 12:24:54 AMI only noted that, because your nvmupdate.cfg listed only 15F2 for the I225-V.
SEE POST #39
I see why.
I didn't note it was -V,
but neither did the NVM folder from where it came from., edit: my bad, the nvm folder from the 34.0 download bundle uses "15F2" in bin filenames, indicating the LM version.
It does get confusing.
I pulled that cfg file from the Intel 34.0 download bundle, from the 225 Linux gz, and no where in there does it say it's for -V or -LM )other than bin filenames have "15F2" in them and the 1MB file also has "_LM", etc.
It ID's 15F2, so I would suspect it's for the -LM 225.
Intel does docs kinda weird, it may be listed in the Release notes for 34.0 what 225's 34.0 has.
The actual Device Name in cfg is said to be just for admin reference only (from that tutorial). Is there really any nic device named "FoxPond1_I225_15F2_2MB_1p94_800003BB"? Likely not. I think the NVM util matches on vendor/device/subvendor/subdevice.
DEVICENAME: xxxx
[Optional] The branding string of the device. This is only used to make the file easier to read; it is not processed by the tool.
15F2 is I225-LM: https://devicehunt.com/view/type/pci/vendor/8086/device/15F2
15F3 is I225-V: https://devicehunt.com/view/type/pci/vendor/8086/device/15F3
0D9F is I225-IT: https://devicehunt.com/view/type/pci/vendor/8086/device/0D9F
125C is I226-V: https://devicehunt.com/view/type/pci/vendor/8086/device/125C
125D is I226-IT: https://devicehunt.com/view/type/pci/vendor/8086/device/125D
125B is I226-LM: https://devicehunt.com/view/type/pci/vendor/8086/device/125B
And the 225 LMvP 5502, not sure if there's a 226 LMvP
SEE POST #39
My update is failing, but the bkup bin is a 2MB bin
-r-------- 1 root wheel 2097152 Sep 10 03:53 00E0B468DCBC.bin
exit status 6
"An error occurred when updating a firmware module.", nice and meaningful. ;)
CURRENT FAMILY: 1.0.0
CONFIG VERSION: 1.20.0
; NIC device
BEGIN DEVICE
DEVICENAME: Intel(R) Ethernet Controller I226-V
VENDOR: 8086
DEVICE: 125C
SUBVENDOR: 8086
SUBDEVICE: 0000
NVM IMAGE: FXVL_125C_V_2MB_2.25.VERSA.bin
EEPID: 800003ad
RESET TYPE: REBOOT
REPLACES: 80000308
END DEVICE
./nvmupdate64e -b -l nvm.log -m 00E0B468DCBC -f -u -c nvm.cfglog file
Quote# more nvm.log
Intel(R) Ethernet NVM Update Tool
NVMUpdate version 1.43.20.0
Copyright(C) 2013 - 2025 Intel Corporation.
./nvmupdate64e -b -l nvm.log -m 00E0B468DCBC -f -u -c nvm.cfg
Config file read.
Inventory
[00:003:00:00]: Intel(R) Ethernet Controller I226-V
Alternate MAC address is not set.
Flash inventory started.
Shadow RAM inventory started.
Shadow RAM inventory finished.
Flash inventory finished.
Update
[00:003:00:00]: Intel(R) Ethernet Controller I226-V
Creating backup images in directory: 00E0B468DCBC.
Backup images created.
Flash update started.
Error: Flash update failed.
Device update failed.
Update security revisions
[00:003:00:00]: Intel(R) Ethernet Controller I226-V
Skipping update minimum security revisions.
Update VPD with VPD template
[00:003:00:00]: Intel(R) Ethernet Controller I226-V
Skipping VPD update with VPD template.
Quote from: BrandyWine on September 10, 2025, 06:05:40 AMMy update is failing, but the bkup bin is a 2MB bin
Your update is failing because it requires the 1MB BIN file. EtrackID 80000308 corresponds to a 1MB image, but you're attempting to flash a 2MB BIN file instead. Keep in mind that backups created with eeupdate64e/nvmupdate64e are always 2MB in size, even when the actual firmware is only 1MB.
I've also added the EtrackIDs for all BIN files to my GitHub README for reference.
Quote from: BillyCurtis on September 10, 2025, 06:42:42 AMQuote from: BrandyWine on September 10, 2025, 06:05:40 AMMy update is failing, but the bkup bin is a 2MB bin
Your update is failing because it requires the 1MB BIN file. EtrackID 80000308 corresponds to a 1MB image, but you're attempting to flash a 2MB BIN file instead. Keep in mind that backups created with eeupdate64e/nvmupdate64e are always 2MB in size, even when the actual firmware is only 1MB.
I've also added the EtrackIDs for all BIN files to my GitHub README for reference.
Thanks for joining, thanks for the update. I will now try and flash the 1MB bin.
Are there any release notes for the versions, and, silly tool only logs err as "error", and not an actual error like "image too large for eeprom".
Quote from: BrandyWine on September 10, 2025, 06:05:40 AMAre there any release notes for the versions, and, silly tool only logs err as "error", and not an actual error like "image too large for eeprom".
No i don't have any release notes. but if you was to use eeupdate64e instead of nvmupdate64e. when trying to flash a 2MB bin file onto a 1MB NIC it would give an error saying "Shared Flash image update FAILED! Flash index is bad or out of range"
Quote from: BillyCurtis on September 10, 2025, 07:09:24 AMQuote from: BrandyWine on September 10, 2025, 06:05:40 AMAre there any release notes for the versions, and, silly tool only logs err as "error", and not an actual error like "image too large for eeprom".
No i don't have any release notes. but if you was to use eeupdate64e instead of nvmupdate64e. when trying to flash a 2MB bin file onto a 1MB NIC it would give an error saying "Shared Flash image update FAILED! Flash index is bad or out of range"
Does eeupdate64e run on freeBSD 14.3?
The 2.32 1MB flash went good.
[1] igc2: <Intel(R) Ethernet Controller I226-V> mem 0x80000000-0x800fffff,0x80100000-0x80103fff at device 0.0 on pci3
[1] igc2: EEPROM V2.32-0 eTrack 0x80000425
Update
[00:003:00:00]: Intel(R) Ethernet Controller I226-V
Creating backup images in directory: 00E0B468DCBC.
Backup images created.
Flash update started.
NVM verification started.
Shadow RAM verification started.
Shadow RAM verification finished.
Flash verification started.
Flash verification finished.
NVM verification finished.
Flash update successful.
Device update successful.CURRENT FAMILY: 1.0.0
CONFIG VERSION: 1.20.0
; NIC device
BEGIN DEVICE
DEVICENAME: Intel(R) Ethernet Controller I226-V
VENDOR: 8086
DEVICE: 125C
SUBVENDOR: 8086
SUBDEVICE: 0000
NVM IMAGE: FXVL_125C_V_1MB_2.32.bin
EEPID: 80000425
RESET TYPE: REBOOT
REPLACES: 80000308
END DEVICE
./nvmupdate64e -b -l nvm.log -m 00E0B468DCBC -f -u -c nvm.cfg
Quote from: BrandyWine on September 10, 2025, 06:05:40 AMDoes eeupdate64e run on freeBSD 14.3?
I have no clue since I've never used freeBSD
Ahh, complete.
I226-V
Use 1MB bin file (It's Billy Curtis bin, not direct from Intel) Note: some 226-V's appear to show etid for 2MB bin, in that case try 2MB bin, and if that fails then try the 1MB bin. I am looking for a way to identify 1M vs 2M prom from cli.
Reference: https://github.com/BillyCurtis/Intel-i226-V-NVM-Firmware?tab=readme-ov-file#readme
Thanks to Billy Curtis for chiming in on OPNsense forum (https://forum.opnsense.org/index.php?topic=48695)
This README with the util and 1MB 2.32 bin can be obtained from:
https://intel226bucket.s3.us-east-1.amazonaws.com/i226.zip
1) This README file
2) Billy Curtis i226-V v2.32 1MB bin
3) Example nvm.cfg file
4) nvmupdate64e util from the Intel 34.0 download bundle
5) Intel doc on using nvmupdate64e
This section w/o the hashes is the nvm.cfg file, modify for your hardware.
This same cfg is included in the zip as "nvm.cfg" that you modify as needed.
#########################
CURRENT FAMILY: 1.0.0
CONFIG VERSION: 1.20.0
; NIC device
BEGIN DEVICE
DEVICENAME: Intel(R) Ethernet Controller I226-V
VENDOR: 8086
DEVICE: 125C
SUBVENDOR: 8086
SUBDEVICE: 0000
NVM IMAGE: FXVL_125C_V_1MB_2.32.bin
EEPID: 80000425
RESET TYPE: REBOOT
REPLACES: 80000308
END DEVICE
##########################
Util Reference: http://tmei-net.com/technology-sharing/how-do-use-intel-ethernet-nvm-update-tool.html
This util command targets a specific device by MAC address.
./nvmupdate64e -b -l nvm.log -m 00E0B468DCBC -f -u -c nvm.cfg
##########################
Edit:
Here's some more tidbit info, that I just found.
Besides the nvmupdate util, there's an "app" called EPCT (ethernet port configuration tool)
In the Intel download bundle look in "\APPS\EPCT\" folder, read the epct.txt
Check out the "Detailed Usage Examples" section !
##########################
Just as a reference point, I downloaded the Billy Curtis zip on Sep 10, 2025. These are the MD5's of those bin's on that date. Hopefully the MD5's don't change, so be sure to verify before use.
Algorithm Hash Path
--------- ---- ----
MD5 2B7BA366F38E93BDF4B10F6852B69AB3 FXVL_125C_V_1MB_2.14.bin
MD5 B4E529613E79B64E1BB6DBD16466AF1A FXVL_125C_V_1MB_2.17.bin
MD5 61C997CAFA20F02EACCEE966A6079583 FXVL_125C_V_1MB_2.32.bin
MD5 3814B2987903DA4B45637D6090068173 FXVL_125C_V_2MB_2.14.bin
MD5 A62AC27A6C193A06AD1E7A6C56B8C980 FXVL_125C_V_2MB_2.17.bin
MD5 36C89D0EECD8F9ED76346674B0DC4171 FXVL_125C_V_2MB_2.22.bin
MD5 8198F8062CD702C89FF42153B306886C FXVL_125C_V_2MB_2.25.bin
MD5 98B1A37CD31BD5E61C2BEEC52FC767F7 FXVL_125C_V_2MB_2.27.bin
MD5 D713238D7F7C5A3B3406260E217C837D FXVL_125C_V_2MB_2.32.bin
Three questions:
1. Did you successfully flash your I226-V (i.e.: does it still work and show the new version)?
2. Is it possible to flash back an old version?
3. Do you need to modify the "REPLACES" ETrackID in order to match the existing ID?
Quote from: meyergru on September 10, 2025, 09:30:44 AMThree questions:
1. Did you successfully flash your I226-V (i.e.: does it still work and show the new version)?
2. Is it possible to flash back an old version?
3. Do you need to modify the "REPLACES" ETrackID in order to match the existing ID?
Yes, mine flashed ok (post #37). I flashed to a unused nic, so now I need to move a cable and cfg OPNsense to move my LAN to the v2.32 nic, etc. I do that tonight.
You can downgrade, and the etid and Replaces in cfg is optional. Having etid Replaces in cfg limits what the tool will match. No etid and the tool pulls it from the bin file. That tutorial doc explains it. If you have a unused 226 it's best to start playing there, upgrade, downgrade, use different cfg options, etc.
Not working
How about specifying some parameters, like the ones Brandywine provided? And remember: this is bleeding-edge stuff, so caveat emptor.
You probably will fry your hardware if you just execute commands indiscriminately like that...
Quote from: yeraycito on September 10, 2025, 05:35:34 PMNot working
Not working is expected in your case, you need util parameters and a cfg file.
If the i226-V is a 1M prom and is currently running v2.17 nvm, then the download I provided should work as-is. If the hardware or versions are anything different then it's on you to modify the cfg file accordingly. This community forum can help.
Users should not attempt to flash anything w/o 1st reading the documentation provided.I also recommend to target an unused 226-V nic if possible.
Do you know how to use $? , need that right after the command fail, then lookup that err code in the tutorial
post #39.
Follow the steps in post #39, which are specific to 226-V 1M prom, but can also be used as template for the 200 series.
Configuration
nvm.cfg
Quote from: yeraycito on September 10, 2025, 06:25:51 PMnvm.cfg
The cfg looks ok for 226-V 1M prom
Use the util command I provided in post #39 but swap out MAC address for your igc0 MAC address.
You need 3 files minimum. util, bin, cfg
If the 1MB flash fails to install then modify the etid in cfg to be the 2MB bin, and then change bin name in cfg to the 2MB bin filename, then try flash again.
It's not apparent (yet) if the i226-V device is a 1M or 2M prom. Some users who have posted pciconf and dmesg info about their 226-V show nvm v2.25 with a 2MB etid, but there's no other identifying attributes (yet) that says it's a 2M prom. And, etid's do appear to be odd in some cases.
If your system has datasheet that says it supports PXE, then the nic is definitely 2M prom because PXE is not available in the 1M bin's.
Quote from: meyergru on September 10, 2025, 01:02:39 AM15F2 is I225-LM: https://devicehunt.com/view/type/pci/vendor/8086/device/15F2
15F3 is I225-V: https://devicehunt.com/view/type/pci/vendor/8086/device/15F3
0D9F is I225-IT: https://devicehunt.com/view/type/pci/vendor/8086/device/0D9F
125C is I226-V: https://devicehunt.com/view/type/pci/vendor/8086/device/125C
125D is I226-IT: https://devicehunt.com/view/type/pci/vendor/8086/device/125D
125B is I226-LM: https://devicehunt.com/view/type/pci/vendor/8086/device/125B
The more I look the more stuff is found.
There's even more deviceID's. Check out the 225/226 ID's in this patch file, there's even a -BLANK version.
From feba9e79c495096f2095a9e82c4d84f191b9a6fa Mon Sep 17 00:00:00 2001
From: Andy <andy@nowhere.com>
Date: Mon, 19 Feb 2024 13:38:35 -0500
Subject: [PATCH] Added i226 support. Assume it is the same as i225.
---
HelperFunctions.c | 15 +++++++++++++++
PciEeprom.c | 30 +++++++++++++++++++++++++++++-
include/common.h | 8 ++++++++
main.c | 3 ++-
4 files changed, 54 insertions(+), 2 deletions(-)
diff --git a/HelperFunctions.c b/HelperFunctions.c
index 73ba59b..c823984 100644
--- a/HelperFunctions.c
+++ b/HelperFunctions.c
@@ -539,6 +539,12 @@ u16 SupportedNicsFound()
case INTEL_I225_K_2:
case INTEL_I225_IT:
case INTEL_I225_LMVP:
+ case INTEL_I226_BLANK:
+ case INTEL_I226_V:
+ case INTEL_I226_LM:
+ case INTEL_I226_K:
+ case INTEL_I226_IT:
+ case INTEL_I226_LMVP:
case INTEL_I350_BLANK:
case INTEL_I350_1:
case INTEL_I350_2:
@@ -654,6 +660,15 @@ u8 SiliconName(u16 DeviceId)
case INTEL_I350_4:
RetVal = 6;
break;
+
+ case INTEL_I226_BLANK:
+ case INTEL_I226_V:
+ case INTEL_I226_LM:
+ case INTEL_I226_K:
+ case INTEL_I226_IT:
+ case INTEL_I226_LMVP:
+ RetVal = 7;
+ break;
}
return RetVal;
diff --git a/PciEeprom.c b/PciEeprom.c
index 7673faa..721f12f 100644
--- a/PciEeprom.c
+++ b/PciEeprom.c
@@ -151,7 +151,8 @@ char * BrandingString2[] =
"X550",
"X553",
"I225",
- "I350"
+ "I350",
+ "I226"
};
@@ -262,6 +263,15 @@ void GetDevice(struct PciDevice* DeviceInfo)
++DeviceCount;
break;
+ case INTEL_I226_BLANK:
+ case INTEL_I226_V:
+ case INTEL_I226_LM:
+ case INTEL_I226_K:
+ case INTEL_I226_IT:
+ case INTEL_I226_LMVP:
+ ++DeviceCount;
+ break;
+
case INTEL_I350_BLANK:
case INTEL_I350_1:
case INTEL_I350_2:
@@ -332,6 +342,12 @@ void GetDevice(struct PciDevice* DeviceInfo)
case INTEL_I225_K_2:
case INTEL_I225_IT:
case INTEL_I225_LMVP:
+ case INTEL_I226_BLANK:
+ case INTEL_I226_V:
+ case INTEL_I226_LM:
+ case INTEL_I226_K:
+ case INTEL_I226_IT:
+ case INTEL_I226_LMVP:
InitNvmParamsI210(DeviceInfo);
break;
@@ -586,6 +602,12 @@ void DisplayAllDevices()
case INTEL_I225_K_2:
case INTEL_I225_IT:
case INTEL_I225_LMVP:
+ case INTEL_I226_BLANK:
+ case INTEL_I226_V:
+ case INTEL_I226_LM:
+ case INTEL_I226_K:
+ case INTEL_I226_IT:
+ case INTEL_I226_LMVP:
CheckCommand(LocationUnparsed);
MapPciDevice(&dev);
DetermineNvmType(&dev);
@@ -674,6 +696,12 @@ void DetermineNvmType(struct PciDevice * dev)
case INTEL_I225_K_2:
case INTEL_I225_IT:
case INTEL_I225_LMVP:
+ case INTEL_I226_BLANK:
+ case INTEL_I226_V:
+ case INTEL_I226_LM:
+ case INTEL_I226_K:
+ case INTEL_I226_IT:
+ case INTEL_I226_LMVP:
FlashPresent = (ReadReg(dev, EECD) & EECTRL_FLASH_PRESENT);
dev->InvmPresent = 0;
diff --git a/include/common.h b/include/common.h
index fa2abb4..00c8c66 100644
--- a/include/common.h
+++ b/include/common.h
@@ -94,6 +94,14 @@
#define INTEL_I225_IT 0x0D9F
#define INTEL_I225_LMVP 0x5502
+// Intel I226 Device Ids
+#define INTEL_I226_BLANK 0x125F
+#define INTEL_I226_V 0x125C
+#define INTEL_I226_LM 0x125B
+#define INTEL_I226_K 0x3102
+#define INTEL_I226_IT 0x125D
+#define INTEL_I226_LMVP 0x5503
+
// Intel I350 Device Ids
#define INTEL_I350_BLANK 0x151F
#define INTEL_I350_1 0x1521
diff --git a/main.c b/main.c
index cc84781..14109cd 100644
--- a/main.c
+++ b/main.c
@@ -76,7 +76,8 @@ char * BrandingString[] =
"X550",
"X553",
"I225",
- "I350"
+ "I350",
+ "I226"
};
--
2.24.0.windows.2
BTW: My device had 2.13 on it and obviously needed the 2 MByte version (the 1 MByte did not work). The 2 MByte file has the EEPID 80000422 (not 80000425), so the nvm.cfg reads:
CURRENT FAMILY: 1.0.0
CONFIG VERSION: 1.20.0
; NIC device
BEGIN DEVICE
DEVICENAME: Intel(R) Ethernet Controller I226-V
VENDOR: 8086
DEVICE: 125C
SUBVENDOR: 8086
SUBDEVICE: 0000
NVM IMAGE: FXVL_125C_V_2MB_2.32.bin
EEPID: 80000422
RESET TYPE: REBOOT
REPLACES: 80000284
END DEVICE
I applied it successfully using "./nvmupdate64e -b -l nvm.log -m 00E0B468DCBC -u -c nvm.cfg" (note the missing "-f"!).
@Brandywine: I had a hard time to download the file from the github again, because you left the ZIP file with all the versions from your new version. The 2 MByte version can be downloaded like so:
"curl -o FXVL_125C_V_2MB_2.32.bin https://raw.githubusercontent.com/BillyCurtis/Intel-I226-V-NVM-Firmware/refs/heads/main/FXVL_125C_V_2MB_2.32.bin"
@meyergru
Yes, I left out the full zip of Billy Curtis bins.
BC might make updates, so probably best I don't try and rebundle his zip.
curl -O https://github.com/BillyCurtis/Intel-I226-V-NVM-Firmware/archive/refs/heads/main.zip
This way you have full set and can try different ones as needed.
the -f switch is optional, but I force it. ;)
Updated and working, thanks a lot for the guidance. As a precaution, I've applied maximum permissions to all files, including the firmware. Then, I applied the update interface by interface via its MAC, including WAN and LAN interfaces, which are in use (a mini PC with four interfaces). Each interface took five seconds to update. I left the LAN interface for last, and when updating it, I lost access and had to restart Opnsense via the physical button.
Updated
@yeraycito
Nice. Now you need to monitor for issues, but I suspect none.
Quote from: yeraycito on September 10, 2025, 07:31:01 PMI left the LAN interface for last, and when updating it, I lost access and had to restart Opnsense via the physical button.
That's a good note of a pitfall to be avoided.
This is why I targeted an unused 226 1st, then after I will move my LAN port over to the updated nic, so that when I flash the other nic I can watch it fully. It's also best to gracefully do reboots especially if the filesystem is UFS. Hard power-off via chassis pwr button is not recommended. I basically did the flashing, exit the shell back to ssh menu, choose reboot option. Some hardware won't be able to accomplish this, but hard reboot has some risk. In this situation might be best to create a shell script that sleeps for 1min then does reboot, so you run the script with nohup and & to place it into background and then run your nvmupdate command, you'll get disconnected from ssh but the script is still running, so essentially you avoid hard pwr-off, etc.
For me, at a first glance, everything works nicely. Also, a soft reboot did the trick - an interface reset probably would have sufficed, as well.
Quote from: meyergru on September 10, 2025, 08:36:16 PMan interface reset probably would have sufficed, as well.
As a cfg option? It's worth a try on an unused nic. I did read some online posts that said they still needed to reboot the system. So maybe it's a hit-miss thing? Not 100% sure.
I moved my WAN to my updated nic. LAN still running v2.17, WAN is 2.32. Will report back on any issues.
Edit: see post #59, I flashed my live LAN nic using a graceful reboot method.
nice work! thanks.
I will wait a couple of days to see if there are any issues then i will go to upgrade my nics.
Here is my NIC data:
igc0@pci0:1:0:0: class=0x020000 rev=0x04 hdr=0x00 vendor=0x8086 device=0x125c subvendor=0x8086 subdevice=0x0000
igc1@pci0:2:0:0: class=0x020000 rev=0x04 hdr=0x00 vendor=0x8086 device=0x125c subvendor=0x8086 subdevice=0x0000
igc2@pci0:3:0:0: class=0x020000 rev=0x04 hdr=0x00 vendor=0x8086 device=0x125c subvendor=0x8086 subdevice=0x0000
[1] igc0: <Intel(R) Ethernet Controller I226-V> mem 0x80800000-0x808fffff,0x80900000-0x80903fff at device 0.0 on pci1
[1] igc0: EEPROM V2.17-0 eTrack 0x80000308
[1] igc0: Using 1024 TX descriptors and 1024 RX descriptors
[1] igc0: Using 4 RX queues 4 TX queues
[1] igc0: Using MSI-X interrupts with 5 vectors
[1] igc0: Ethernet address:
[1] igc0: netmap queues/slots: TX 4/1024, RX 4/1024
[1] igc1: <Intel(R) Ethernet Controller I226-V> mem 0x80600000-0x806fffff,0x80700000-0x80703fff at device 0.0 on pci2
[1] igc1: EEPROM V2.17-0 eTrack 0x80000308
[1] igc1: Using 1024 TX descriptors and 1024 RX descriptors
[1] igc1: Using 4 RX queues 4 TX queues
[1] igc1: Using MSI-X interrupts with 5 vectors
[1] igc1: Ethernet address:
[1] igc1: netmap queues/slots: TX 4/1024, RX 4/1024
[1] igc2: <Intel(R) Ethernet Controller I226-V> mem 0x80400000-0x804fffff,0x80500000-0x80503fff at device 0.0 on pci3
[1] igc2: EEPROM V2.17-0 eTrack 0x80000308
[1] igc2: Using 1024 TX descriptors and 1024 RX descriptors
[1] igc2: Using 4 RX queues 4 TX queues
[1] igc2: Using MSI-X interrupts with 5 vectors
[1] igc2: Ethernet address:
[1] igc2: netmap queues/slots: TX 4/1024, RX 4/1024
[26] igc2: promiscuous mode enabled
Just as a note, my OPNsense is not running much.
Basically fw, suricata, bogons, dhcp4/6.
From all my reading about the 200 series, 226 in particular, the v2.17 nvm was causing the problems.
From my same reading, using a updated driver, as example the igc that's in freeBSD 14.3, also really needs to have the device be on an updated nvm image.
There's some agreeable logic in that. We have to assume driver updates and nvm image updates are being done for a reason. Sometimes it's new feature, other times a bug/security fix, or all three. I tend to follow the linux driver updates in the applicable tree to see what updates they are making, and then see if bsd org is following that.
My general hypothesis is this:
1) NVM v2.17 is no good, get off of that sooner than later.
2) If you're running latest OPNsense with freeBSD-14.3, then it's probably best to get the nics onto latest nvm (this applies to all the Intel stuff).
3) Duly noted, this thread is less relevant to non-Intel nics, but it would be wise to check with nic oem for latest firmware, but still investigate how that code plays with igc driver in freeBSD-14.3.
It's the wonderful world of hardware & software. Always problematic, always "fun". ;)
When you can't move connections around because you don't have unused nic ports.
A graceful way to flash an in-use nic, the one you ssh to.
Create the sleep reboot script, then run it with nohup to background.
Then execute your nvm update command. Voila, a graceful reboot.
#!/bin/sh
sleep 1m
reboot
chmod +x reboot.sh
nohup ./reboot.sh &
root@RiceCake:~ # nohup ./reboot.sh &
[1] 252
root@RiceCake:~ # ./nvmupdate64e -b -l nvm.log -m 00E0B468DCBB -f -u -c nvm.cfg
Intel(R) Ethernet NVM Update Tool
NVMUpdate version 1.43.20.0
Copyright(C) 2013 - 2025 Intel Corporation.
(connection drops here)
(wait about 1 to 1.5min for the reboot, login again, verify)
dmesg |grep igc
[1] igc1: <Intel(R) Ethernet Controller I226-V> mem 0x80200000-0x802fffff,0x80300000-0x80303fff at device 0.0 on pci2
[1] igc1: EEPROM V2.32-0 eTrack 0x80000425
So now that I'm thoroughly paranoid about whether or not mine has an issue... how can I know? Is there a specific symptom that the i226v exhibits and how do we measure it?
[1] igc3: <Intel(R) Ethernet Controller I226-V> mem 0x91200000-0x912fffff,0x91300000-0x91303fff at device 0.0 on pci5
[1] igc3: EEPROM V2.13-0 eTrack 0x80000286
I understand the sentiment that "if it isn't broken, don't fix it," but this is fuzzy. Maybe those sporadic internet glitches that I tolerate are not normal?... or are they?
I had 2.13 as well (https://forum.opnsense.org/index.php?msg=246834) and no problems. apart from network ports freezing when ASPM was enabled. I think that this is not a NIC-specific problem, however, because the freezes occured the same with my Intel 82559ES NICs with ASPM enabled.
I now updated to 2.32 and also: no problems.
This method might fix some glitches for people with 2.17.
Well, that was scary, but I've successfully updated all mine from EEPROM V2.17-0 eTrack 0x80000308 to EEPROM V2.32-0 eTrack 0x80000425.
I used the reboot.sh method for the in use NIC's which worked *perfectly*.
Everything seems to be great.....
Thanks everyone for this extremely useful post.....
Updated all 6 nics from 2.13 to 2.32 using the 2mb bin.
That was a wild ride, and my heart is still pounding. I feel the need for a stiff drink after that.
Even though I was not experiencing any problems, I'm not sure what is the benefit is?
Thanks all.
root@OPNsense:~ # dmesg | grep igc
[1] igc0: <Intel(R) Ethernet Controller I226-V> mem 0x81400000-0x814fffff,0x81500000-0x81503fff at device 0.0 on pci1
[1] igc0: EEPROM V2.32-0 eTrack 0x80000422
[1] igc0: Using 1024 TX descriptors and 1024 RX descriptors
[1] igc0: Using 4 RX queues 4 TX queues
[1] igc0: Using MSI-X interrupts with 5 vectors
[1] igc0: Ethernet address: a8:b8:e0:0a:14:dd
[1] igc0: netmap queues/slots: TX 4/1024, RX 4/1024
[1] igc1: <Intel(R) Ethernet Controller I226-V> mem 0x81100000-0x811fffff,0x81200000-0x81203fff at device 0.0 on pci2
[1] igc1: EEPROM V2.32-0 eTrack 0x80000422
[1] igc1: Using 1024 TX descriptors and 1024 RX descriptors
[1] igc1: Using 4 RX queues 4 TX queues
[1] igc1: Using MSI-X interrupts with 5 vectors
[1] igc1: Ethernet address: a8:b8:e0:0a:14:de
[1] igc1: netmap queues/slots: TX 4/1024, RX 4/1024
[1] igc2: <Intel(R) Ethernet Controller I226-V> mem 0x80e00000-0x80efffff,0x80f00000-0x80f03fff at device 0.0 on pci3
[1] igc2: EEPROM V2.32-0 eTrack 0x80000422
[1] igc2: Using 1024 TX descriptors and 1024 RX descriptors
[1] igc2: Using 4 RX queues 4 TX queues
[1] igc2: Using MSI-X interrupts with 5 vectors
[1] igc2: Ethernet address: a8:b8:e0:0a:14:df
[1] igc2: netmap queues/slots: TX 4/1024, RX 4/1024
[1] igc3: <Intel(R) Ethernet Controller I226-V> mem 0x80b00000-0x80bfffff,0x80c00000-0x80c03fff at device 0.0 on pci4
[1] igc3: EEPROM V2.32-0 eTrack 0x80000422
[1] igc3: Using 1024 TX descriptors and 1024 RX descriptors
[1] igc3: Using 4 RX queues 4 TX queues
[1] igc3: Using MSI-X interrupts with 5 vectors
[1] igc3: Ethernet address: a8:b8:e0:0a:14:e0
[1] igc3: netmap queues/slots: TX 4/1024, RX 4/1024
[1] igc4: <Intel(R) Ethernet Controller I226-V> mem 0x80800000-0x808fffff,0x80900000-0x80903fff at device 0.0 on pci5
[1] igc4: EEPROM V2.32-0 eTrack 0x80000422
[1] igc4: Using 1024 TX descriptors and 1024 RX descriptors
[1] igc4: Using 4 RX queues 4 TX queues
[1] igc4: Using MSI-X interrupts with 5 vectors
[1] igc4: Ethernet address: a8:b8:e0:0a:14:e1
[1] igc4: netmap queues/slots: TX 4/1024, RX 4/1024
[1] igc5: <Intel(R) Ethernet Controller I226-V> mem 0x80500000-0x805fffff,0x80600000-0x80603fff at device 0.0 on pci7
[1] igc5: EEPROM V2.32-0 eTrack 0x80000422
[1] igc5: Using 1024 TX descriptors and 1024 RX descriptors
[1] igc5: Using 4 RX queues 4 TX queues
[1] igc5: Using MSI-X interrupts with 5 vectors
[1] igc5: Ethernet address: a8:b8:e0:0a:14:e2
[1] igc5: netmap queues/slots: TX 4/1024, RX 4/1024
[7] igc1: link state changed to UP
[7] igc2: link state changed to UP
[7] igc3: link state changed to UP
[7] igc4: link state changed to UP
[7] igc5: link state changed to UP
[14] igc2: link state changed to DOWN
[14] igc3: link state changed to DOWN
[14] igc4: link state changed to DOWN
[14] igc5: link state changed to DOWN
[14] igc1: link state changed to DOWN
[17] igc2: link state changed to UP
[18] igc1: link state changed to UP
[18] igc5: link state changed to UP
[18] igc4: link state changed to UP
[18] igc2: promiscuous mode enabled
[18] igc3: promiscuous mode enabled
[18] igc4: promiscuous mode enabled
[18] igc5: promiscuous mode enabled
[18] igc0: promiscuous mode enabled
[22] igc3: link state changed to UP
root@OPNsense:~ #
Is updating to nvm v2.32 of great benefit?
Well, the best docs to get at are inside Intel protected area, so you need a developer account. I tried to register, my request was not approved.
With all the digging online I came across reports of issues related to nvm 2.17. Some of those said they updated and their issue went away. Most of what I read was iface dropping off under high bandwidth use. The exact scenario (settings, device use, etc) were not in those posts, it was more just chatter about the nvm.
Without all the detailed release notes, we can apply a little logic. I don't know anyone taking time to build an updated firmware image just for fun. Updates are usually a feature add and-or a fix. This applies to device firmware and drivers. freeBSD 14.3 did have an update in igc driver, so we expect that version to be "the latest" for 14.3, and Billy Curtis has v2.32 bin firmware, presumably the latest Intel bin.
Running latest driver with latest firmware is usually the best match. Sometimes you get new bugs related to a new feature, sometimes just a new bug from updated code, and sometimes no issue at all. But we should expect the updated stuff to be have fixes for previous known bugs.
As for power control, there's something called an Optionality bit which can completely disable ASPM. I not sure where that is just yet, but I also do not fully understand the ASPM issue. I did read that on some (some) platforms/OS the power policy was just too aggressive and would send signal to a device to enter into L0s power state when by no means it should start power savings. Perhaps there are rare setups where a LAN side port goes 100% idle so the power savings kicks in, but WAN port is always active with OPNsense, and probably 99.9% of devices have active LAN ports, thus these devices should never power save. And, from what I read about ASPM, the L0s state should not cause any 100% packet loss.
Without wrapping some processes in debug/monitor its hard to know for sure what's going on. Which is something I don't have time to do right now, and, I already updated nvm.
So now we wait to see who brings the 1st nic related issue with nvm v2.32. Mine has been stable.
Quote from: ProximusAl on September 12, 2025, 09:24:16 AMI used the reboot.sh (https://reboot.sh/) method for the in use NIC's which worked *perfectly*.
For readers, it's always best to do your 1st flash to a nic that is not the nic you use for ssh. This way you can make sure all your flash settings are good. After all the others are completed then do nic you are using for ssh, using the reboot script, etc. Never start with the nic you are ssh'd into (if it's the only nic that allows ssh, etc), because if it goes badly then you might have bricked it, but you could still connect a display/kbd/mouse and try and fix from there.
As a side note, when I flashed my un-used nic and moved my WAN cable there, the connection did not come up fully. I did have to reboot my cable modem. I suspect a glitch in DHCP, but glitch on modem side, WAN iface did not get v4/v6 IP. After modem reboot everything was fine.
Another caveat for some might be this. Some internet services (think gmail and such) may have marked your access there as "trusted" based on long use of one source IP. When you move WAN connection to a new nic (new MAC) the DHCP from ISP may hand out a completely different IP than before, and then your access to those internet services may change away from "trusted", making you re-validate yourself. gmail and yahoo is notorious for this, and it's a royal pita.
For the most part, it's ok to just leave your connections (cables) as-is and just flash the nics in proper sequence. I moved my WAN cable only because I wanted to play around flashing on an unused nic.
Thanks to the information in this message thread I was able to update from the 2.17 firmware to the latest version.
Special thanks to Brandywine for the detective work in tracking down all of the files and information and to Yeraycito for posting all of his config files which helped me figure out what changes to make to mine when my first couple of attempts didn't work.
Once I had the config file corrected, the flash was successful and after a reboot everything came up and is working fine.
So I took the bait and upgraded both of the I226-V adapters in my Bee-link ME mini to the 2.32 firmware. Uneventful, but now the system runs the latest BIOS and the latest NIC firmware - great.
Thanks, @BrandyWine for your perseverance and for proving me wrong in my assumption you were fighting wind mills.
Knowledge sharing is key for community based stuff. If I was not running OPNsense community version on a chinese mini pc, I would not have been here on the community OPNsense forums. It also kinda bugged me that the whole nvm stuff was very dark on information and we're not able to easily get docs and firmware from Intel sites (from public side).
Just a note here for readers who jumped into this thread here. Go back to around post #30 and start reading, then ready your flashing files. For the full "what is this" story, start on post #1.
(https://forum.opnsense.org/index.php?action=dlattach;attach=47727;image)
😉
Quote from: Patrick M. Hausen on September 13, 2025, 08:25:49 PM(https://forum.opnsense.org/index.php?action=dlattach;attach=47727;image)
😉
What does 226 posts signify?
I226...
Has anyone tested this yet with a protectli device?
Quote from: bbin on September 14, 2025, 12:53:06 AMHas anyone tested this yet with a protectli device?
Makes no difference where the i226-V is installed, nic nvm is nic nvm, hardware level code.
"protectli" is just an integrated name with lots of other devices in it.
Perhaps a better question to ask is, where's the documentation on Protectli site that describes how to update the nic firmware?
After successfully flashing my Lenovo box I remembered that one of the 2.5gb ports on my Minisforum MS-01 is an i226v. I ran the Intel flash utility in 'inventory' mode just to get a look at the firmware version and I got this in the log:
Warning: Cannot initialize port: [00:087:00:00] Intel(R) Ethernet Controller I226-V
Error: The selected adapter (location:[87:00:00]) cannot be updated due to inaccessible device memory.
Update the device driver and reboot the system before running this utility again.
Consult the utility documentation for more information.
I'm going to poke around in the Minisforum BIOS to see if there's a setting there that's preventing access to the NIC.
The MS-01 has one I226-V and one I226-LM, which enables access for Intel vPro, for which the machine also has a license, such that Meshcommander works with it. I would not try to change the firmware of the I226-LM, because you might destroy the vPro license - but I am only guessing as to how that license is implemented.
I doubt that you will find useful info on this on the Minisforum or Serve The Home forums. I have not seen info on how to flash I226 firmware anywhere expect for this very thread in this forum.
Quote from: CGrisamore on September 14, 2025, 01:24:11 PMWarning: Cannot initialize port: [00:087:00:00] Intel(R) Ethernet Controller I226-V
What OS is it? And your MS-01 has just one i226-V ?
Lets 1st see what's there
dmesg |grep igc
pciconf -lv
This MS-01 post about BIOS is fairly recent. Can you post pics like this https://spaceterran.com/posts/step-by-step-guide-enabling-intel-vpro-on-your-minisforum-ms-01-bios/
If there is a -LM device then you need the -LM nvm flash image, the -V won't be the correct image, and, -LM is likely a 2MB image. I do suspect you could flash the -V image onto a -LM device if the flash cfg was correct, but you would just be converting -LM features into the -V features.
As for any license and such, unless it's custom made firmware (possible but rare), I don't think any higher level software would be probing the nvm image. There are very few integrators (if any) who will maintain their own firmware for devices that are not their own.
Hi Meyergru
And you are correct. No information anywhere. I poked around the Minisforum BIOS looking for any settings which might unlock access to the NIC. I tried enabling the network stack setting which seemed to be the only thing NIC related in the BIOS (it has very limited and basic settings) and tried the Intel utility again and got the same results.
As the MS-01 has been working for a year without problems at this point I'm not going to worry about it. Just thought as I had learned how to look at and update firmware I might as well take a look at what version was installed.
Quote from: CGrisamore on September 14, 2025, 02:10:46 PMJust thought as I had learned how to look at and update firmware I might as well take a look at what version was installed.
see post #76
Hi Brandywine
I'm away from the computer at the moment but I can do some poking around later in the day.
Only one of the NIC in the MS-01 is an i226-v and the box is running Linux.
I wasn't trying to touch the other NIC (i226-lm), just wanted to see if the 226-v might be an older firmware as per this message thread.
The Intel utility sees both of the 1226 adapters but reports that the memory is inaccessible for both. It provides full details on the two 10gb adapters which made me suspect that a BIOS setting has locked the 2.5gb ports.
Quote from: CGrisamore on September 14, 2025, 03:16:48 PMHi Brandywine
I'm away from the computer at the moment but I can do some poking around later in the day.
Only one of the NIC in the MS-01 is an i226-v and the box is running Linux.
I wasn't trying to touch the other NIC (i226-lm), just wanted to see if the 226-v might be an older firmware as per this message thread.
The Intel utility sees both of the 1226 adapters but reports that the memory is inaccessible for both. It provides full details on the two 10gb adapters which made me suspect that a BIOS setting has locked the 2.5gb ports.
I am skeptical that bios has locked nic eeprom access.
Linux? What nmvupdate tool did you use?
1) The nmv util I put up was for freeBSD, there's one for Linux in the Intel 34.0 bundle download (same util name though). Although nix is a lot of common, compiled binaries are usually OS dependent. ;)
2) Also go back some posts, there's also another utility you can use on Linux, post was by Billy Curtis.
For readers here, this thread is specific to i226-V running freeBSD 14.3 natively on the pc platform. Don't expect everything to work as posted if your hardware and setup is different. VM's, Linux OS, require something slightly different than what's been posted in this thread. Not hard to modify, but understand there are differences.
Hi Brandywine
I did download a Linux version of the Intel utility as the BSD one wouldn't run (duh). Appreciate your help on working through this but I expect this discussion should move to email as the MS-01 is not my OPNSense box and I shouldn't clutter up this forum with the non-relevant discussion.
Quote from: CGrisamore on September 14, 2025, 04:26:23 PMHi Brandywine
I did download a Linux version of the Intel utility as the BSD one wouldn't run (duh). Appreciate your help on working through this but I expect this discussion should move to email as the MS-01 is not my OPNSense box and I shouldn't clutter up this forum with the non-relevant discussion.
0) Always give pertinent info when post up questions. we didnt know your MS box was not an opnsense install. I eluded to this in post #76.
1) Start a thread on Miniforums, see if any tech folks provide some decent info.
2) We can still help here, but you 1st need to provide nic info, OS info, specific 226 driver being used, and bios info as requested. Linux has a ko loaded for igc, yes? ethtool is probably the goto tool on linux for nic stuff, dmesg too will be helpful.
Hi all,
I'm the owner of a dec3840 and im wondering if the ethernet chips (Intel i210 ?) can also can be upgraded the same way as described here.
I'll do some investigation tonight on what the version of the NVM is which is currently installed.
PS: since i have no issues (except power management not eappearing to work and leading to problems in speed negotiation and freezes when enabled) i'm still in doubt if i should try an update in the first place. Any guidance from Deciso on this matter?
Quote from: Kets_One on September 18, 2025, 01:32:25 PMwondering if the ethernet chips (Intel i210 ?) can also can be upgraded the same way as described here
Yes, same process, different bin file.
Download the Intel 34.0 bundle, bin's are in there. The bin's are from 2021 though, so not sure if Intel has anything newer.
Thankyou to BrandyWine and meyergru - I updated all of my i226-v adapters across my 2 n150 mini pc's last night. They were at 2.13, the same as meyergru so that really helped. One of my mini pc's is running OpnSense bare metal and the other proxmox with a few machines, so I had to use both the FreeBSD and Linux tools but both worked fine.
I didn't appear to have any prior issues, but as BrandyWine had said - they don't update for fun, so I thought it wise to update to 2.32
Quote from: tn881023 on September 19, 2025, 09:16:01 AMThankyou to BrandyWine and meyergru
Glad to have helped.
A small (and final) update on my efforts:
As per dmesg | grep igb output my i210 is "Flashless". It is not using an external NVM but an internal (iNVM) instead. Guess this rules out any NVM update.
Quote from: Kets_One on September 22, 2025, 12:16:40 PMA small (and final) update on my efforts:
As per dmesg | grep igb output my i210 is "Flashless". It is not using an external NVM but an internal (iNVM) instead. Guess this rules out any NVM update.
Can you post pciconf -lv |grep i210
Ok readers, this thread has been all about updating NVM for the i226-V nic's, process/method similar for other models too.
I am moving to another issue that seems to have plagued many, disabling ASPM for good.
see other thread https://forum.opnsense.org/index.php?topic=48777.0
Adding some more tidbit info.
Digging some more around ASPM and related reports that ASPM was causing issues with links dying.
Interestingly enough, i226 ASPM capability is L1 only (no L0s), and my x520 is L0s only (no L1), and my SSD is L0s/L1 capable.
226 LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L1
520 LnkCap: Port #0, Speed 5GT/s, Width x8, ASPM L0s
ssd LnkCap: Port #1, Speed 8GT/s, Width x4, ASPM L0s L1
So with ASPM enabled it's possible the i226 pci link went totally offline, but the x520 will never have that issue.
Guess what? I had exactly that link dying issue issue with an Intel 82599ES (which is the X520-DAx chipset) and it went away only after I set hw.pci.enable_aspm=0.
Quote from: meyergru on September 25, 2025, 08:45:01 AMGuess what? I had exactly that link dying issue issue with an Intel 82599ES (which is the X520-DAx chipset) and it went away only after I set hw.pci.enable_aspm=0.
That's odd. Maybe state L0s is an issue too. L0s only sleeps one half of pci link, but has fast recovery.
Maybe check your nic capabilities (lspci -vv) and see what your x520 has, maybe different NVM's have different bits set.
Nope:
# pciconf -lbcv ix1@pci0:1:0:1
ix1@pci0:1:0:1: class=0x020000 rev=0x01 hdr=0x00 vendor=0x8086 device=0x10fb subvendor=0x8086 subdevice=0x000c
vendor = 'Intel Corporation'
device = '82599ES 10-Gigabit SFI/SFP+ Network Connection'
class = network
subclass = ethernet
bar [10] = type Memory, range 64, base 0x81080000, size 524288, enabled
bar [18] = type I/O Port, range 32, base 0x3000, size 32, enabled
bar [20] = type Memory, range 64, base 0x81200000, size 16384, enabled
cap 01[40] = powerspec 3 supports D0 D3 current D0
cap 05[50] = MSI supports 1 message, 64 bit, vector masks
cap 11[70] = MSI-X supports 64 messages, enabled
Table in map 0x20[0x0], PBA in map 0x20[0x2000]
cap 10[a0] = PCI-Express 2 endpoint max data 256(512) FLR RO NS
max read 512
link x4(x8) speed 5.0(5.0) ASPM disabled(L0s)
cap 03[e0] = VPD
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected
ecap 0003[140] = Serial 1 90e3baffff00be8a
ecap 000e[150] = ARI 1
ecap 0010[160] = SR-IOV 1 IOV disabled, Memory Space disabled, ARI disabled
0 VFs configured out of 64 supported
First VF RID Offset 0x0180, VF RID Stride 0x0002
VF Device ID 0x10ed
Page Sizes: 4096 (enabled), 8192, 65536, 262144, 1048576, 4194304
cap 10[a0] = PCI-Express 2 endpoint max data 256(512) FLR RO NS
max read 512
link x4(x8) speed 5.0(5.0) ASPM disabled(L0s)That's the lnk control settings as defined by bios/driver/app, etc. You disabled ASPM from (wherever) and it shows in [a0] area.
And (as we discussed earlier for what it means), the L0s in "ASPM disabled(L0s)" is telling us what specific L state is disabled. You could technically have L0s/L1 capability in nvm but have only disabled L0s, and it would show in config space as "ASPM disabled(L0s)"
I do however suspect your x520 only has L0s in NVM.
It doesn't make much sense that a nic link (pci link) would drop out in L0s, because there's plenty of wake-up routine to bring it back very fast. If the root issue is in L0s wake-up, then this to me says probably an issue in the driver code. Could probably add some debug code into driver src and recompile and load in as KLM, to see why L0s wake-up is not working as expected.
Grab lspci -vv -d 8086:10fb
Pciconf is giving condensed config space info with byte locations in []
These byte locations (for each device id) are seen from lspci -xxxx
LnkCap are bit settings for capable features coded into nvm.
Side note: my i226's have MAC from vendor Techno Scope Co. Ltd, not Intel. Hmmmm. Maybe BIOS doing it.
All I can say it did expose the typical "no more network" behaviour before I disabled ASPM via the tuneable about once per week and not anymore since.
Thanks all of you for this topic!
I upgraded my Hunsn RJ03 with i226-V from 2.17 to 2.32 version (1MB), all 4 ports without issues.
To anyone with same device:
Vendor, device etc. is the same as in default config, all you need to do is change MAC address and reboot to take effect.
P.S. I don't know if it's placebo but it seems more responsive after upgrade
Quote from: nightcom on September 30, 2025, 08:08:10 PMThanks all of you for this topic!
P.S. I don't know if it's placebo but it seems more responsive after upgrade
Probably is more responsive. New nvm with a matching new driver.
There's text in some Intel notes that say "don't run this new driver w/o 1st getting latest device firmware", paraphrased, not specifically for i226.
The nvm update tool offers the -rd option to reset user settings. However, the documentation doesn't clearly explain what this does. Would using this option be beneficial? My assumption is that it might remove manufacturer-specific tweaks and return the device to a more stock configuration, but I'm not certain.
-rd seems like a mystery option.
Maybe the user settings are the writeable registers that store the bits that config a feature?
Not all nvm util options are applicable to all eeprom's, as example, 226 1MB does not have orom.