Patching Intel X520 EEPROM to unlock all SFP+ transceivers

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

santeo

New Member
Mar 26, 2024
2
3
3
Hello!
I have an Intel X520-DA2 card that I want to unlock. Is this the correct command for flipping the bits to
unlocked based on the information below:
(Don't know how to do the binary math, so I am not completely sure if the command below is completely right according to the output below?)

sudo ethtool -E enp1s0f0 magic 0x154d8086 0x58 value 0xfd <-- Wrong
sudo ethtool -E enp1s0f0 magic 0x154d8086 offset 0x58 value 0xfd <-- Correct

EDIT: When running the above command I got:
ethtool: bad command line argument(s)
For more information run ethtool -h

I should have the right magic word?
It does not work with length 1 in the end either..

ip addr
4: enp1s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
5: enp1s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff


lspci -nn:
01:00.0 Ethernet controller [0200]: Intel Corporation Ethernet 10G 2P X520 Adapter [8086:154d] (rev 01)
01:00.1 Ethernet controller [0200]: Intel Corporation Ethernet 10G 2P X520 Adapter [8086:154d] (rev 01)


sudo ethtool -e enp1s0f0 offset 0x58 length 1
Offset Values
------ ------
0x0058: fc



sudo ethtool -e enp1s0f0
Offset Values
------ ------
0x0000: 60 09 02 00 00 00 40 00 6d 00 fd 00 8d 01 a3 01
0x0010: a9 01 af 01 b7 01 bf 01 c7 01 cf 01 09 02 b8 05
0x0020: 00 05 ff ff ff ff ff ff ff ff fa fa 9d 37 c8 02
0x0030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0040: a3 37 ff ff ff ff ff ff ff ff ff ff ff ff 94 37
0x0050: 8e 37 28 40 35 40 40 36 fc ff bd 08 00 80 48 02


Thanks in advance!
 
Last edited:

MPServers

Member
Feb 4, 2024
30
18
8
Hello!
I have an Intel X520-DA2 card that I want to unlock. Is this the correct command for flipping the bits to
unlocked based on the information below:
(Don't know how to do the binary math, so I am not completely sure if the command below is completely right according to the output below?)

sudo ethtool -E enp1s0f0 magic 0x154d8086 0x58 value 0xfd
Include "length 1" on the end of the -E command that sets that value.

I just did this on a couple X520 card in a system I was converting to fiber SFP's and didn't realize it wouldn't accept my Cisco modules. Fortunately I had a couple Intel modules I could use for now, but it bugged me and I found this thread after searching.

You have to specify that length on the set command, which some earlier posts leave out, probably a change in "ethtool" itself over the years.

Here's the command I used, for example:
ethtool -E enp131s0f0 magic 0x154d8086 offset 0x58 value 0xfd length 1

I also made the mistake of not double-checking my device ID so it took me a little more reading to realize my X520 (in a Dell) is 154d, not the other one used in other examples. Once I made that change also, it worked fine.

Well, I say it worked, but I still need to try out those Cisco modules now that I've made the change, just to make sure it *really* worked. :)
 

santeo

New Member
Mar 26, 2024
2
3
3
Include "length 1" on the end of the -E command that sets that value.

I just did this on a couple X520 card in a system I was converting to fiber SFP's and didn't realize it wouldn't accept my Cisco modules. Fortunately I had a couple Intel modules I could use for now, but it bugged me and I found this thread after searching.

You have to specify that length on the set command, which some earlier posts leave out, probably a change in "ethtool" itself over the years.

Here's the command I used, for example:
ethtool -E enp131s0f0 magic 0x154d8086 offset 0x58 value 0xfd length 1

I also made the mistake of not double-checking my device ID so it took me a little more reading to realize my X520 (in a Dell) is 154d, not the other one used in other examples. Once I made that change also, it worked fine.

Well, I say it worked, but I still need to try out those Cisco modules now that I've made the change, just to make sure it *really* worked. :)
Thank you very much! I just saw that my command was missing the offset word. I did this in the middle of the night, and I guess I was really tired to miss that. :)

This command now worked for me with my other Intel X520 (actually it is a 82599ES):
ethtool -E enp1s0f0 magic 0x10fb8086 offset 0x58 value 0xfd length 1

The magic word was different on that card: (so had to change to 10fb8086.
01:00.0 Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)

And for my other card this command works:
ethtool -E enp1s0f0 magic 0x154d8086 offset 0x58 value 0xfd length 1
Magic word comes from here:
01:00.0 Ethernet controller [0200]: Intel Corporation Ethernet 10G 2P X520 Adapter [8086:154d] (rev 01)
01:00.1 Ethernet controller [0200]: Intel Corporation Ethernet 10G 2P X520 Adapter [8086:154d] (rev 01)


(Of course run as root, otherwise you have to put sudo first)
 
Last edited:

AntoineNet

New Member
Jul 25, 2024
4
0
1
Sorry to bump this, but do anyone of you know if this patch would work on Dell 942V6 Intel X520-DA2 ?

Thanks a lot
 

AntoineNet

New Member
Jul 25, 2024
4
0
1
I can't specifically attest to this variant, it seems to work with lots of others.

If it were mine, I'd try it.
The thing is I found a good deal on ebay but it comes in a big pack haha so it's risky if I cannot apply this patch. Applied the patch today to a genuine Intel Card and it worked great so it would be amazing if this patch is assured to work on the Dell 942V6 variant of the Intel X520-DA2.
 

MPServers

Member
Feb 4, 2024
30
18
8
How different could it be? :D

Just be sure to confirm the correct magic #. A couple of the X520's I ran this on came from Dell servers - I can't say for sure if they were that Dell 942V6, I didn't look at the sticker on the card, just whatever Windows or Linux was reporting it as.
 
  • Like
Reactions: AntoineNet

AntoineNet

New Member
Jul 25, 2024
4
0
1
I can confirm the new instructions for current ethtool work as Eric describes.

However, having applied 0xFD to both my X520 cards, I no longer get the unsupported SFP message (on Windows so I can't use the option for ixgbe) but I also do not get a successful link. I'm also interested therefore in other possible bits - as well as the specific drivers people have used on Windows for 10Gb unsupported SFPs.
If we patch a card with linux and return to windows does it work? Can we use unsuported SFP+ tranceivers on the card after the patch inside windows?

Also @MPServers
 

AntoineNet

New Member
Jul 25, 2024
4
0
1
How different could it be? :D

Just be sure to confirm the correct magic #. A couple of the X520's I ran this on came from Dell servers - I can't say for sure if they were that Dell 942V6, I didn't look at the sticker on the card, just whatever Windows or Linux was reporting it as.
Thanks so you think it will work?
 

ikkuranus

New Member
Mar 26, 2022
2
0
1
I have 2 Intel x520-da1 which both contain FD in 0x58. They both refuse to work in windows or pfsense while my ODI DFP-34X-2C2 is inserted.
It works just fine in Linux OSes such as unraid or with a live image of debian.
 

blunden

Active Member
Nov 29, 2019
702
227
43
I have 2 Intel x520-da1 which both contain FD in 0x58. They both refuse to work in windows or pfsense while my ODI DFP-34X-2C2 is inserted.
It works just fine in Linux OSes such as unraid or with a live image of debian.
Unlocking it would probably fix that. :) I'm guessing the Linux distros you used might've set the allow_unsupported_sfp=1 flag when loading the driver.
 

blunden

Active Member
Nov 29, 2019
702
227
43
Yes but doesn't FD= already on?
Oh, I you're right. :D I read that first post wrong last night. The bit in question is 1 when the lock is disabled (resulting in FD) and 0 when it's not (resulting in FC).

Then I don't know why you're having that problem. :confused:
 

Zune

New Member
Apr 27, 2023
17
7
3
Brazil
So thanks for the research, that's highly appreciated as I have a few Cisco UCS machines with the x520 card with Cisco stickers on it, Cisco SFP+ modules installed and the card not liking them.
Bitflipped and all works fine.

To make life easier for others, here's a quick-and-dirty patcher written in python that does the bitstring calculations and the flashing in one go: Intel x520 EEPROM Patcher allows to unlock the x520 network card to work with non-intel branded SFP modules.

It's Linux only, bugfixes and improvements are welcome.
Just to say, I've followed this tutorial and ran the GitHub python script and everything worked fine!

P.S: You don't need to install Linux on your system, just run as live CD, download ethtool package to check the NIC's info and run python code available on the GitHub repo above (if your Distro doen't have python pre-installed, install python via apt and done!).
 
  • Like
Reactions: JustinClift

ZPrime

New Member
Jun 1, 2016
26
3
3
43
Cleveland, OH
Anybody have any clue if this would work for an Intel X553? Uses the same `ixgbe` driver in Linux; this is the "onboard" NIC in the Intel Atom Denverton CPUs (C3xxx)...
 

MPServers

Member
Feb 4, 2024
30
18
8
Hard to say... I don't know enough about what change is being made exactly to the card. You're specifying it's PCI id and giving it an offset, a byte value to set (and length of just one byte) and modifying that location in the EEPROM. That may be fine for the X520 but for other cards, not sure... I'm just guessing it's something/somewhere else unless that NIC is so close to the X520 that the firmware is pretty close or identical.
 

blunden

Active Member
Nov 29, 2019
702
227
43
Anybody have any clue if this would work for an Intel X553? Uses the same `ixgbe` driver in Linux; this is the "onboard" NIC in the Intel Atom Denverton CPUs (C3xxx)...
At the very least I would expect the offsets to be different.

Have you verified that your C3xxx based device isn't actually unlocked from the factory?