Ok so the tl;dr is:
The card is perfectly fine except for it not recognizing the flash chip, which I was able to fix. Most of the issues stem from the SFP modules I was using. The card works with:
- 1G SFP-DAC
- 10G SFP+-DAC on 1G speed
- 1000base-T RJ-45 SerDes SFP
- 10/100/1000base-T RJ-45 SGMII SFP
- 1000base-SX SFP
- 10Gbase-SX SFP on 1G
Can't test 1000base-LX SFP and 10Gbase-LX SFP on 1G, since I don't have such modules but most likely work also. Also haven't tested active DAC cables.
The ethtool outputs are correct and make sense after further investigation.
I spent quite some time reading the i350 datasheet and other sources until I understood all of this. I'll give you a summary.
----------------
PART 1: Clearing up the problems I had:
Why was the SFP module EEPROMM dump not working?
Well, as it turns out there was something I forgot. I was using an out-of-tree version of the Intel igb driver. After uninstalling that one, I was able to use ethtool -m enp2s0f0 again to obtain the module eeprom information.
I discovered this through
this discussion on sourceforge. To be specific, it works on my Proxmox system with kernel 5.15.53-1-pve and same version igb driver 5.15.53-1-pve.
For more details like ethtool -m output for these modules and PHY register dumps, see the next post.
These are the modules, that I tested an worked:
- Intel branded Finisar FTLX8571D3BCV-IT 10Gbase-SX on 1G speed
- Cisco MGBSX1 1000base-SX
- QSFPTEK QT-SFP-M CO SFP 1000M RJ45 100M in SerDes mode and SGMII mode (Marvell Alaska Ultra 88E1111 PHY chip) also work with 10/100 speeds if in SGMII mode
- 10Gtek CAB-1GSFP-P 1GBase-CU DAC
- HiFiber CAB-10GSFP-P 10Gbase-CU DAC on 1G speed
Modules that work with quirks:
- QSFPTEK QT-SFP-T CO SFP 10/100/1000 RJ45 in SGMII mode (Marvell Alaska Ultra 88E1111 PHY chip)
- Cisco MGBT1 SFP RJ45 (unknown PHY chip)
Modules that don't work:
- FS.com SFP-10G-T 10GBASE-T-SFP+ (Marvell Alaska X 88X3310/40P PHY chip)
Why does the FS 10Gbase-T module not work?
Problem is that the i350 chip has to agree on a speed with the PHY in the module. This happens over MDIO. MDIO has two flavors, Clause 22 and Clause 45.
The problem here is that the i350 can only speak Clause 22 and the module PHY only Clause 45. To make it work, a translation needs to happen. The driver should handle this. As far as I understand, the igb driver can't do this. I'm not sure but if it would use phylink and phylib, it could potentially work. Intel uses their on implementation according to this
discussion.
I had an idea how to fix this but I don't know if it's possible. If there was a way to manually programm the PHY registers in the module, the module might work together with the i350 if it's forced to 1G. As for as I understand, it's in 10G mode by default.
Here is what happens whens I try to establish a link between the FS module and the QSFPTEK module:
Code:
igb 0000:02:00.0 enp2s0f0: After fix-ups FlowControl is now = 3
igb 0000:02:00.0 enp2s0f0: Configuring Autoneg:PCS_LCTL=0x0217000C
igb 0000:02:00.0 enp2s0f0: Initializing the Flow Control address, type and timer regs
igb 0000:02:00.0 enp2s0f0: PCS Auto Neg has not completed.
igb 0000:02:00.0 enp2s0f0: PCS Auto Neg has not completed.
igb 0000:02:00.1 enp2s0f1: hw->fc.current_mode = 3
igb 0000:02:00.1 enp2s0f1: Flow Control = RX PAUSE frames only.
igb 0000:02:00.1 enp2s0f1: 1000 Mbs,
igb 0000:02:00.1 enp2s0f1: Full Duplex
igb 0000:02:00.1 enp2s0f1: hw->fc.current_mode = 1
igb 0000:02:00.1 enp2s0f1: 1000 Mbs,
igb 0000:02:00.1 enp2s0f1: Full Duplex
igb 0000:02:00.1 enp2s0f1: igb: enp2s0f1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
IPv6: ADDRCONF(NETDEV_CHANGE): enp2s0f1: link becomes ready
igb 0000:02:00.0 enp2s0f0: PCS Auto Neg has not completed.
igb 0000:02:00.0 enp2s0f0: PCS Auto Neg has not completed.
igb 0000:02:00.0 enp2s0f0: PCS Auto Neg has not completed.
The QSFPTEK module can establish a link with the FS module but the FS module can't establish a link with the i350, it gets stuck on PCS Auto Neg.
Whats wrong with the other modules?
The Cisco MGBT1 works in SerDes mode but doesn't in SGMII mode.
SerDes mode is activated when you insert the module on a booted system with the driver loaded. If the driver is not loaded and you insert the module and then load the driver, the driver tries to operate in SGMII mode but fails.
Here ist the error:
Code:
igb 0000:02:00.2 0000:02:00.2 (uninitialized): Vendor ID 0x00008000 read at address 1
igb 0000:02:00.2 0000:02:00.2 (uninitialized): Vendor ID 0x00008000 read at address 2
igb 0000:02:00.2 0000:02:00.2 (uninitialized): Vendor ID 0x00008000 read at address 3
igb 0000:02:00.2 0000:02:00.2 (uninitialized): Vendor ID 0x00008000 read at address 4
igb 0000:02:00.2 0000:02:00.2 (uninitialized): Vendor ID 0x00008000 read at address 5
igb 0000:02:00.2 0000:02:00.2 (uninitialized): Vendor ID 0x00000000 read at address 6
igb 0000:02:00.2 0000:02:00.2 (uninitialized): I2CCMD Error bit set
igb 0000:02:00.2 0000:02:00.2 (uninitialized): PHY address 7 was unreadable
igb: probe of 0000:02:00.2 failed with error -2
It can't read PHY register 7 for some reason and produces a hardware initialization failure. I suspect there is something wrong with the PHY register configuration.
Removing the module and reloading the driver doesn't solve the issue, you have to reboot.
The QSFPTEK QT-SFP-T CO seems to be SGMII only. Meaning you have to reload the driver after inserting it to make it work. It doesn't work in SerDes mode.
One thing about the QSFPTEK QT-SFP-M CO module:
This one seems to be able to work in SerDes and SGMII mode. When inserting it with the driver loaded, it operates at 1G fixed speed. When reloading the driver it changes to SGMII mode and works with 10/100/1000 speeds.
This is how this looks like:
Code:
igb 0000:02:00.1 0000:02:00.1 (uninitialized): Vendor ID 0x0000FFFF read at address 1
igb 0000:02:00.1 0000:02:00.1 (uninitialized): Vendor ID 0x0000FFFF read at address 2
igb 0000:02:00.1 0000:02:00.1 (uninitialized): Vendor ID 0x0000FFFF read at address 3
igb 0000:02:00.1 0000:02:00.1 (uninitialized): I2CCMD Error bit set
igb 0000:02:00.1 0000:02:00.1 (uninitialized): PHY address 4 was unreadable
igb 0000:02:00.1 0000:02:00.1 (uninitialized): I2CCMD Error bit set
igb 0000:02:00.1 0000:02:00.1 (uninitialized): PHY address 5 was unreadable
igb 0000:02:00.1 0000:02:00.1 (uninitialized): Vendor ID 0x00000141 read at address 6
igb 0000:02:00.1 0000:02:00.1 (uninitialized): Masking off all interrupts
igb 0000:02:00.1 0000:02:00.1 (uninitialized): Masking off all interrupts
igb 0000:02:00.1 0000:02:00.1 (uninitialized): Initializing the IEEE VLAN
igb 0000:02:00.1 0000:02:00.1 (uninitialized): Programming MAC Address into RAR[0]
igb 0000:02:00.1 0000:02:00.1 (uninitialized): Clearing RAR[1-31]
igb 0000:02:00.1 0000:02:00.1 (uninitialized): Zeroing the MTA
igb 0000:02:00.1 0000:02:00.1 (uninitialized): Zeroing the UTA
igb 0000:02:00.1 0000:02:00.1 (uninitialized): After fix-ups FlowControl is now = 3
igb 0000:02:00.1 0000:02:00.1 (uninitialized): Configuring Autoneg:PCS_LCTL=0x0213000C
igb 0000:02:00.1 0000:02:00.1 (uninitialized): Soft resetting SGMII attached PHY...
igb 0000:02:00.1 0000:02:00.1 (uninitialized): Reconfiguring auto-neg advertisement params
igb 0000:02:00.1 0000:02:00.1 (uninitialized): autoneg_advertised 2f
igb 0000:02:00.1 0000:02:00.1 (uninitialized): Advertise 10mb Half duplex
igb 0000:02:00.1 0000:02:00.1 (uninitialized): Advertise 10mb Full duplex
igb 0000:02:00.1 0000:02:00.1 (uninitialized): Advertise 100mb Half duplex
igb 0000:02:00.1 0000:02:00.1 (uninitialized): Advertise 100mb Full duplex
igb 0000:02:00.1 0000:02:00.1 (uninitialized): Advertise 1000mb Full duplex
igb 0000:02:00.1 0000:02:00.1 (uninitialized): Auto-Neg Advertising de1
igb 0000:02:00.1 0000:02:00.1 (uninitialized): Restarting Auto-Neg
igb 0000:02:00.1 0000:02:00.1 (uninitialized): Unable to establish link!!!
igb 0000:02:00.1 0000:02:00.1 (uninitialized): Initializing the Flow Control address, type and timer regs
igb 0000:02:00.1 0000:02:00.1 (uninitialized): Phy info is only valid if link is up
igb 0000:02:00.1: added PHC on eth0
igb 0000:02:00.1: Intel(R) Gigabit Ethernet Network Connection
igb 0000:02:00.1: eth0: (PCIe:5.0Gb/s:Width x1) xx:xx:xx:xx:xx:xx
igb 0000:02:00.1 eth0: NVM PBA number is not stored as string
igb 0000:02:00.1: eth0: PBA No: 106300-000
igb 0000:02:00.1: Using MSI-X interrupts. 4 rx queue(s), 4 tx queue(s)
igb 0000:02:00.1 enp2s0f1: renamed from eth0
Also, this is how the ethtool output looks like after that:
Code:
root@Proxmox:~# ethtool enp2s0f1
Settings for enp2s0f1:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: Unknown!
Duplex: Unknown! (255)
Auto-negotiation: on
Port: Twisted Pair
PHYAD: 6
Transceiver: internal
MDI-X: off (auto)
Supports Wake-on: d
Wake-on: d
Current message level: 0x00007fff (32767)
drv probe link timer ifdown ifup rx_err tx_err tx_queued intr tx_done rx_status pktdata hw wol
Link detected: no
Why does the 10G Fiber module and 10G DAC cable work?
Many people are preaching that SFP+ modules don't work in SFP slots. Doesn't seem to be true here.
If both sides operate on 1G, the SFP+ fiber module seems to have no issues.
Short DAC cables are entirely passive, except the eeprom that has no active function for link establishing, there a no active components in it.
You can compare it to a normal Cat6A cable. Those also don't care at what speed they operate.
Haven't tested active DAC cables.
How did I make the card recognize the flash?
After making the following changes to the eeprom, the flash was accessible again and I was able to flash PXE etc. to it.
| Word Name and Adress | Word in HEX / Binary before Change | Word in HEX / Binary after Change | Changes |
|---|
| Compatibility Word (Word 0x03) | 0800 (0000100000000000) | 0000 (0000000000000000) | Bit 11:
1 -> 0
LOM mode to NIC. |
| EEPROM Sizing and Protected Fields (Word 0x12) | 5C80 (0101110010000000) | 6080 (0110000010000000) | Bit 13-10:
0111 -> 1000
EEPROM size 16kbytes -> 32kbytes according to eeprom chip datasheet |
| PCIe Init Configuration Word 2 (Word 0x19) | 7000 (0111000000000000) | 3000 (0011000000000000) | Bit 14:
1 -> 0
IO_Sup (I/O Support) disabled |
PCIe Control 2 (Word 0x28) | 1C40 (0001110001000000) | 1C4D (0001110001001101) | Bit 0:
0 -> 1 Flash BAR in the PCI configuration space enabled.
Bit 1-3:
000 -> 110
Flash Size 64KB to 512KB according to flash chip datasheet |
What's up with the confusing ethtool output?
All of the information is based on this video, which explains how Layer 1 and 2 work in Linux.
The ethtool output is this:
Code:
root@Proxmox:~# ethtool enp2s0f0
Settings for enp2s0f0:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseKX/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 1000baseKX/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: Unknown!
Duplex: Unknown! (255)
Auto-negotiation: on
Port: FIBRE
PHYAD: 0
Transceiver: internal
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00007fff (32767)
drv probe link timer ifdown ifup rx_err tx_err tx_queued intr tx_done rx_status pktdata hw wol
Link detected: no
Let's first see what the igb driver reports to ethtool:
Pretty straightforward, if the NIC'S media type is not copper, it's fibre, does 1000baseKX_full and supports auto negotiation.
Is that actually correct? Kind of... It seems like the SFP variants of the i350 cards are kind of an afterthought. Intel's i350-f4 doesn't have SFP modules and not too many OEMs made this SFP variant...so I guess no one ever asked for a more correct reporting in ethtool when it works just fine either way.
Let's look at the lines that might be confusing more closely:
Supported ports: [ FIBRE ]
Port: FIBRE
We're using SFP modules, so it doesn't have to be fiber. DAC and RJ45 SFPs are also working.
What are the other options? Let's look at the ethtool source code.
This section lists the possible options for "Supported Ports" :
TP, AUI, BNC, MII, FIBRE and Backplane
Twisted Pair, AUI, BNC, MII, FIBRE, Diract Attach Copper, None, Other and Unknown!
I guess it would make sense listing multiple supported ports.
TP for RJ45 SerDes SFPs, MII for RJ-45 SGMII SFP, FIBRE for SX and LX SFPs, and Direct Attach Copper for DAC cables.
Backplane, as far as I understand, would only fit for PCI mezzanine cards for blade servers.
On the other hand, Intel x520 and x710 also show FIBRE as port.
Also, see i350 datasheet page 699 for the different modes the card can operate in. The term fiber is used for SerDes operation here.
Supported link modes: 1000baseKX/Full
Advertised link modes: 1000baseKX/Full
1000baseKX actually is for backplane connections.
What are the options in ethtool?
Possible ones for this card could be:
- 10/100/1000base-T for RJ45 SFPs
- 1000base-X for fiber SFPs
- 1000base-CU is missing
- 1000base-KX
So why use KX?
I guess they use KX because backplane connection could also be interpreted as the SerDes lanes on the card from the i350 chip to the SFP cages.
Again, this doesn't seem to be much of a concern. The x520 reports 1000baseT and 10000baseT. The x710 reports 10000baseT/Full, 1000baseX/Full, 10000baseSR/Full and 10000baseLR/Full.
Supports auto-negotiation: Yes
Advertised auto-negotiation: Yes
Why auto negotiation if the card only operates at 1G speed with non SGMII (10/100/1000) modules?
The process of auto negotiation still happens, but the card just reports only the 1G capability to the link partner.
Transceiver: internal
This one was very confusing. "SFP module" is often used as a synonym for "transceiver", so it should make sense to have "external" here. What I have found out is that transceiver is also used as a synonym for the PHY (component).
You should watch the video (the whole one, do it, it's worth the time) I linked to fully understand this but in summary:
The SFP module is not the whole transceiver and the PCS portion of the PHY/transceiver that's integrated into the i350 is always active to enable the communication over the SerDes lines to whatever type of module there is in the SFP cage.
I can only imagine this to report "external" if the card is in SGMII mode with an external PHY chip (not inside an SFP module but on the main PCB) directly connected to the (SG)MII pins of the i350 controller.
Also, X520 and X710 report "internal" here as well.
--------------
PART 2 EEPROM Flashing:
Let's start with how to obtain debug information from the igb driver.
1. How to get igb debug information:
- unload the driver
rmmod igb
- load the driver with options and dynamic debugging on
modprobe igb debug=16 dyndbg==p
- view the information with
demsg | grep igb
If you don't see additional messages you might also enter dmesg -n 8 and then repeat the previous steps. This might also print the messages on your current console screen. You'll need to do this after every reboot. This was all I needed to do on my Proxmox system. You might need to jump through some more hoops on different systems.
I also found this command in my notes, but i don't remember when I needed it:
echo -n 'module igb +p' > /sys/kernel/debug/dynamic_debug/control
More information on dynamic debugging of kernel modules
here.
---
2. How to read/dump the i350 EEPROM:
There are multiple tools to do this. You can do it with ethtool, nvmupdate and eeupdate. ethtool and nvmupdate are publicly available, eeupdate is confidential. Your company needs to sign an NDA to get access. You don't need it but it has some additional functionalities when it comes to interfacing the card. You can find its readme file out there to find out more. I searched it for hours until if found out I can use nvmupdate. You can nonetheless find eeupdate via google. Two sources are leaking it under a different name if you really need it.
I think eeupdate was used for intel network chips until the X520 series and nvmupdate is now the successor for X550 series and newer. Luckily, we can use nvmupdate also for the older cards.
If you are on BSD I think there is nothing like ethtool. In this case use NVMUpdate.
You can also use a CH341a bios flasher. More info on that in section 4.
2.1. Installing the Intel® Ethernet Adapter Debug Driver for Linux (iqvlinux):
I don't know if this is really necessary. I have not tested all of this without it installed and I don't want to test all this all over again...so just install it to be safe. eeupdate wil throw a warning if this is not installed. You will also need it if you have a disabled option ROM flash and want to dump the EEPROM with NVMUpdate.
Finding the newest version that is compatible with the current Proxmox 5.15.x kernel was quite tedious. The repository on sourceforge is outdated. You can't compile the old driver on current kernel versions.
Eventually, I found it. The newest version is packaged with the Intel Ethernet Connections Boot Utility, Preboot Images, and EFI Drivers.
- Download the latest version from Intel here.
- unpack
tar -xzvf Preboot.tar.gz
cd ./PREBOOT/APPS/Bootutil/Linux_x64/DRIVERSchmod +x install
Before installing, you need to install your kernel headers and build-essential.
5. apt install build-essential
6. For Proxmox do apt install pve-headers or apt install pve-headers-$(uname -r) Adjust according to your system. If the download fails, make sure you have the pve-no-subscription repository in your /etc/apt/sources.list
deb http://download.proxmox.com/debian/pve bullseye pve-no-subscription
7. run ./install
If this still fails and it complains about a missing autoconf.h file, try reinstalling the kernel headers. apt reinstall pve-headers-$(uname -r) or apt reinstall pve-headers. This was an issue I had. Then run the install script again.
The driver should be installed now.
2.1. EEPROM dump with ethtool:
The dump from ethtool comes in a format that needs modification before you can edit and flash the image with the other tools to the eeprom.
- Read with
ethtool -e enp2s0f0 raw on > eeprom.bin (you might need to change the interface name)
- Then
hexdump -ve '8/2 "%04X " " \n"' eeprom.bin > eeprom.eep
Now it's in the format that the nvmupdate and eeupdate can use. (Same format as these tools' dump command produces)
2.2 EEPROM dump with NVMUpdate:
note: I stated in the original post that NVMUpdate would not detect the card. That was wrong. It detects it and prints information about it but does not read or flashthe EEPROM without modification of the nvmupdate.cfg file.
This only works if you have a detected and enabled option rom flash or already have a dump from ethtool.
In case the flash is not activated, you need to activate it using intel BootUtil (see 2.1).
1. run BootUtil to identify your nic ./bootutil64e
2. activate the flash ./bootutil64e /NIC=X /FE
If that doesn't work, try to do it with
IBAUtil.exe DOS tool from
Dell.
Create a bootable FreeDOS USB Stick with Rufus to use it. Commands should be the same like BootUtil.
We have to do this because there is now way in NVMUpdate to just dump the EEPROM. You always have to update flash or eeprom in the same step.
Now to NVMUpdate:
- Download NVMUpdate from the intel website.
- unzip it
unzip 700Series_NVMUpdatePackage_v9_01.zip might need to apt install unzip first.
- unpack the .tar
tar -xvzf 700Series_NVMUpdatePackage_v9_01_Linux.tar.gz
cd ./700Series/Linux_x64/chmod +x nvmupdate64e- run
./nvmupdate, this should display all intel NICs in the system
- run
./nvmupdate64e -i -l to display more information of all intel NICs in the system
- Add the configuration for your device to
nvmupdate.cfg
Should look like this:
Code:
CURRENT FAMILY: 1.0.0
CONFIG VERSION: 1.14.0
;Release 19.3/19.4 to Release 20.0
BEGIN DEVICE
DEVICENAME: DEVICENAME: Intel(R) I350 Gigabit Fiber Network Connection
VENDOR: 8086
DEVICE: 1522
SUBVENDOR: 8086
SUBDEVICE: 1522
SKIP OROM: FALSE
OROM IMAGE: BootIMG.FLB
;EEP IMAGE:
;EEPID:
;REPLACES:
RESET TYPE: POWER
END DEVICE
BEGIN DEVICE
DEVICENAME: XL710
...
The information to insert here is based on the previous output of ./nvmupdate64e -i -l . Lines with a semicolon as the first character are commented out.
8. Now update the option ROM and dump the eeprom and flash with ./nvmupdate64e -l -b -u
This creates a folder with the name of your NICs MAC adress containing the macadress.flb and macadress.eep file.
.eep is the eeprom dump, .flb is the flash dump.
If it doesn't work try with the -f flag to force the flashing of the OROM.
Full documentation of NVMUpdate
here.
2.3 dump with eeupdate:
- Make sure you installed the iqv drivers, see 2.1.
- Run eeupdate once to identify nic
- run again
./eeupdate64e /NIC=x /DUMP to dump the eeprom
To be on the safe side, run ./eeupdate64e /NIC=ALL /DUMP , in case you **** up and select the wrong NIC to flash in the flashing step.
3. Editing the EEPROM image:
Now to edit it I like to copy it on a Windows machine, open the .eep file in editor and copy the single words into
HxD.
Then open the i350 controller datasheet chapter 6 eeprom map and find what you want to change.
Copy the word into HxD and click on it. On the right side you see the bits its made of.
One 4 character group in the eeprom.eep file is one word. The first word of the first line is address 0X00 the last address 0x07. Second line starts with 0x08 to 0x0F. Third line starts with 0x10 and so on.
Let's look at one example word:
0A37
In HxD default viewing mode you will see:
0A 37
If you click on 0A, the data inspector will show it in Binary 8 bit form. You read from right to left. In this case:
bit 15 -> 00001010 <- bit 8
And 37 will be:
bit 7 -> 00110111 <- bit 0
Now look into the datasheet and identify which bit you need to change, highlight it in the data inspector, change it and press enter. The word should have changed now, just apply the change accordingly in the eeprom.txt file.
When you made all your changes, save them and copy the file back to your Linux machine.
4. Flashing the eeprom:
Before doing this, please be aware that flashing eeproms from other NICs, like flashing i210 eeprom to i350 eeprom might break the card. Not completely but it might not show up on the PCIE-Bus anymore what also means, you can't flash it with any of these tools anymore. This is because parts of the eeprom configure the initial state of some PCIE control structures/registers aka CSR space. This is the only part of this I don't really understand right now.
If you break it, you have two options.
- Rip the flash from the board and force it to operate in eeprom-less mode. This is bad. The default configuration in eeprom-less mode, probably makes it show up in the PCIE-Bus again but it also won't work properly anymore since the configuration is wrong.
- Use a CH341 based BIOS-chip flasher. I recommend this one that has a voltage switch:
The other popular one floating around is the black one in this video:
But be careful with this one. Like the video says, this one sends 5V over the data lines even if it's in 3.3V mode. This might kill the chip. Make sure to find the datasheet to your eeprom chip to find out the correct voltage. There is a big community around this so I won't explain this in detail. I tested it on a i350-t2 and it worked. Sometimes in-circuit flashing doesn't work and you have to remove the eeprom from the board, flash it and resolder it.
Anyway...
Before you flash, write down your NIC's MAC-adresses. Usually they won't be overwritten but I haven't tested this thoroughly. Flashing the .eep file from someone else with different MAC-Adresses should not change your MAC adress...should.
4.1 Flashing with ethtool:
i didn't bother learning how to do this, but others have done this with X520s to unlock it for other brand SFPs. See this
thread.
4.2 Flashing with nvmupdate:
Modify nvmupdate.cfg again to something like this:
Code:
CURRENT FAMILY: 1.0.0
CONFIG VERSION: 1.14.0
;Release 19.3/19.4 to Release 20.0
BEGIN DEVICE
DEVICENAME: DEVICENAME: Intel(R) I350 Gigabit Fiber Network Connection
VENDOR: 8086
DEVICE: 1522
SUBVENDOR: 8086
SUBDEVICE: 1522
SKIP OROM: TRUE
;OROM IMAGE: BootIMG.FLB
EEP IMAGE: eeprom.eep
;EEPID:
;REPLACES:
RESET TYPE: POWER
END DEVICE
BEGIN DEVICE
DEVICENAME: XL710
...
After that, run ./nvmupdate -l -b -u.
Because we are using the same eep image revision, this will fail, because the programm thinks the current image and the modified file are the same. To force the flashing, use ./nvmupdate -l -b -u -f
4.3 Flashing with eeupdate:
Be carefull here and make sure to select the correct NIC.
./eeupdate64e /nic=X /D eeprom.eep
5. Reboot
That's it.
