[solved] Intel i226 Firmware (see post #39)

[yeraycito]

Configuration

[yeraycito]

nvm.cfg

[BrandyWine]

nvm.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.

[BrandyWine]

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

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.

Code Select Expand

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



[meyergru]

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:

Code Select Expand

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"

[BrandyWine]

@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. ;)

[yeraycito]

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.

[yeraycito]

Updated

[BrandyWine]

@yeraycito

Nice. Now you need to monitor for issues, but I suspect none.

I 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.

[meyergru]

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.

[BrandyWine]

an 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.

[BrandyWine]

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.

[raberrio]

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:

Code Select Expand

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


[BrandyWine]

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". ;)
 

[BrandyWine]

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