Should be same for eth1 and eth2 on r4 as there are same macs for both…(r3 is different in this manner where second sfp is connected to switch not sfp). Can you show output for eth2 for same state (only no sfp)? Afair i had fewer options for both when no sfp is connected…this is maybe driver bug (creating the mac with fewer options)
I didn’t make any speed settings, I left it on automatic. It looks like this:
It shows the same options for eth2 and eth1 when I remove the SFP module.
So, either the SFP module can’t deal with 2500Mb/s or a driver issue. Because according to the manufacturer it should support it.
What is the model of your SFP module that is not being recognized?
It’s this one 2.5G XPON STICK SFP ONU - LuLeey
According to name and specs it should support 2.5G. But in the SFP+ port of the R4 it doesn’t.
Not sure if the issue is SFP+ or the realtek chipset inside and the corresponding driver on the kernel side.
This one looks like it is the same as the ODI DFP-34X-2C2. Can you post the output of ethtool -m eth2 ?
Here you go. What information are you looking for? It doesn’t seem to properly load the EEPROM though, because I changed some of those values in the webinterface, but those changes are not reflected here.
The chipset is a RTL9601D according to sources I found.
ethtool -m eth2
Identifier : 0x03 (SFP)
Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
Connector : 0x01 (SC)
Transceiver codes : 0x00 0x00 0x00 0x02 0x22 0x00 0x01 0x00 0x00
Transceiver type : Ethernet: 1000BASE-LX
Transceiver type : FC: intermediate distance (I)
Transceiver type : FC: Longwave laser (LC)
Transceiver type : FC: Single Mode (SM)
Encoding : 0x01 (8B/10B)
BR, Nominal : 1300MBd
Rate identifier : 0x00 (unspecified)
Length (SMF,km) : 20km
Length (SMF) : 20000m
Length (50um) : 0m
Length (62.5um) : 0m
Length (Copper) : 0m
Length (OM3) : 0m
Laser wavelength : 1310nm
Vendor name : OEM
Vendor OUI : 00:00:00
Vendor PN : XPON-Stick
Vendor rev :
Option values : 0x00 0x1a
Option : RX_LOS implemented
Option : TX_FAULT implemented
Option : TX_DISABLE implemented
BR margin, max : 0%
BR margin, min : 0%
Vendor SN : XPONXXXXXXXX
Date code : 231127
It probably is a clone of ODI DFP-34X-2C2/3. The issue with this stick is that it advertises 1000base-LX support and sets the bitrate to 1300MBd in the EEPROM, which makes linux see is as a 1Gbit device. This behavior can be changed either by adding an sfp quirk for your device and recompiling the kernel, or editing the EEPROM and changing the relevant bytes.
I followed this post to set the correct values to the EEPROM and now it is detected as a 2500baseX device: Right SFP EEPROM config for DFP-34X-2C2 to work automatically work at 2500base-X? · Anime4000/RTL960x · Discussion #250 · GitHub
Basically, you have to remove the bit that advertises support for 1000base-LX, and set the nominal bitrate to 3100MBd instead of 1300. Note that after doing this change, the device will probably only work at 2.5gbe and it will not be recognized if you use it in a 1gbit media converter etc.
Thanks. This is so bad.
I checked out your link and found this: https://github.com/Anime4000/RTL960x/blob/main/Docs/FLASH_GETSET_INFO.md#lan_sds_mode
Have you tried changing this value instead of changing the eeprom directly?
Personally, I would prefer if I could change the eeprom to announce the correct speeds. 1G and 2.5G.
<4>change mode to 7(SGMII Force)
<4>change mode to 1(Fiber 1G)
<4>change mode to 3(SGMII MAC)
<4>change mode to 4(HiSGMII PHY)
<4>sgmii mode is 7
<4>change mode to 7(SGMII Force)
I wish there was an open-source firmware for those devices. or even easier, an option to run it inside the OpenWrt on the R4 instead of the SFP module.
Yes, I tried modes 4,5,6 (the default was 0 on mine which just tries the modes one by one until it finds a suitable one). It made no difference.
It is very easy to change the eeprom values with i2c-tools, but of course there is a risk of losing access to the module. You don’t need the program mentioned in the link I posted, if you don’t change the checksum, you will get a message in the kernel log that will state that it is wrong and which value is the correct one. So what I did was:
i2cdump -y X 0x50
where X is 0 to 5, until I got the output from my gpon stick. This is just to find the correct bus (the eeprom address is 0x50). In my case, for the wan sfp port, the bus number is 3, so i2cdump -y 3 0x50 prints the contents of the eeprom. Then:
i2cset -y 3 0x50 0x06 0x00 (removes the 1000base-LX advertisement)
i2cset -y 3 0x50 0x0c 0x1f (sets nominal bitrate to 3100MBd)
Then I removed and reinserted the sfp and I got the kernel message:
sfp sfp1: EEPROM base structure checksum failure: 0x81 != 0x71
so I just set the correct checksum (byte 0x3f) with:
i2cset -y 3 0x50 0x3f 0x81
Now the stick is identified as 2.5G:
root@OpenWrt:~# ethtool eth2
Settings for eth2:
Supported ports: [ FIBRE ]
Supported link modes: 2500baseX/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 2500baseX/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 2500Mb/s
Duplex: Full
Auto-negotiation: on
Port: FIBRE
PHYAD: 0
Transceiver: internal
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: no
The issue I have with bpi-r4 is that I cannot access the stick on its IP address, the eth2 link remains down, whereas if I use a 2.5G media converter or put it in my other router (turris omnia), it is accessible.
The auto negotiation is broken, at least for my module. I use ethtool to force it to the 1Gbps speed full duplex. You should do the same for 2.5Gbps I guess.
What I’d rather have is that it advertises both modes. And that I can then use both modes.
I think the auto negotiation being broken is just another issue that we might or might not figure out. Could be the realtek chip. Or the eeprom not being correctly setup for the kernel to figure things out.
According to linux/drivers/net/phy/sfp-bus.c at v6.6 · torvalds/linux · GitHub , lines 308-340, setting one of the fiber channel bits for 100/200/400 speed or setting the correct min/max bitrate in the eeprom, should make both 1000base-x and 2500base-x available, I might test this when I get home.
That would be cool if you could test it.
If I understood the code correctly, we need to set one of the 100/200/400 fiber bits and then set the bitrate nominal to a value of 31. Then it should set both 1000gbps and 2500gbps.
The other part of the code needs some other calculation.
Okay, I had some time and sunk into the code and the SFP spec. 
The current code active with your changes is this:
It results in only either 1000 or 2500 BASEX flags being set for the interface, because br_min and br_max are br_nom which is the value you set via i2c times 100.
If we were to set the cable type to passive then it would set multiple modes based on the nominal speed. I assume a fiber would be set to passive, since there is nothing in the cable, just a laser in the sfp.
Last option would be to tell the kernel that we have fiber channel speed. I don’t know if this has other implications that might be negative for the working of the GPON/APON module.
So I set today the relevant bits in the eeprom for the FC speeds 100 and 200, and now I get both speeds as supported:
root@OpenWrt:~# ethtool eth2
Settings for eth2:
Supported ports: [ FIBRE ]
Supported link modes: 2500baseX/Full
1000baseX/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 2500baseX/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 2500Mb/s
Duplex: Full
Auto-negotiation: on
Port: FIBRE
PHYAD: 0
Transceiver: internal
Current message level: 0x000000ff (255)
drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes
I can force the stick to 1gbit (if I disable autonegotiation). I don’t have any 1gbit sfp host, but I will borrow an old media converter from work and try it later.
After playing a bit with a 2.5g and a 1g media converter, my conclusion is that the odi dfp-34x-2c2 stick is recognized by those converters whatever the eeprom configuration and the LAN_SDS_MODE. This is because, as it turns out, if the odi stick cannot establish a link with the current lan_sds_mode, it will cycle through the other modes until it finds one that works. I am not sure if other clones of this module work the same way.
Unfortunately I do not have access to a linux device with 1gbit sfp port to test the compatibility and auto negotiation after changing the fc speed bits in the eeprom.