It will be recognised as the sfp details are accessed out of band - SDA line? However it will not be able negotiate the link for the data lines.
I am not even sure whether SFP+ 10G unit can negotiate anything less than 10Gbps , which would mean it is just not possible to run in a SFP cage, where it seems to max out at 5Gbps going by the wikpedia page.
Again, does anyone know if I am wrong in my assumption?
Did someone tested BPI-R3 with C-Data FD511GX-RM0 SFP module?
I want to replace ISP’s ONU.
UPD.
Also I found this module: https://v-solution.ru/onu-v2801f-v-solution-1ge-sfp.html I believe this sfp module has the same hardware as C-Data FD511GX-RM0 module.
But is its power consumption too high (≤4W)? I believe, it is now limited to 3W max only in BPI-R3 firmware? I don’t plan to use another (lan) sfp module, so I think, that is safe to raise max power to 4 W in the firmware, right?
Hi,
I have DFP-34G-2C2 (GPON version) of this SFP chip and I’m interested in getting this board but I’d like to be sure the module will work.
I have it working with a ClearFog GT 8K, that I’d like to replace with R3 as it’s much cheaper with similar specs.
I didn’t manage to configure 2500base-x, even after tweaking LAN_SDS_MODE but 1000base-x works fine nevertheless (which in my personal case does not matter much as my plan throttles me at 300Mbps)
Were the “OEM” “SFP-2.5G-T” devices ones you had on-hand to test?
I got a pair from the SinoVoip Co.,Limited Banana PI AliExpress and as quirked they never notice the link state, and thus never come up to pass traffic. I’m curious if my modules are just slightly different or if it is possible the quirk needs to be updated to be functional.
Using kernel 6.4-rc5 as my base I changed the quirk from “2500baseT” to “2500baseX” as shown in sfp-fix-oem-2500baseX.patch (544 Bytes) to get it to notice the link. With this both SFP ports detect the SFP and can detect the link when the ethernet cable is connected. SFP2 passes traffic. SFP1 doesn’t pass traffic, but I believe that is expected without any additional patches on top of 6.4-rc5.
But in my case link came up,only speed was not detected,but i get full 2g5 traffic through it with iperf3. In 1g mode i had retransmitts so maybe your patch does better
I hope 6.4 is not broken again. Daniel and i had both sfp ports working so far
After getting SFP-1 working, I tested 2.5g between them and that yielded retransmitts, but I’m pretty sure that’s IRQ related. Just for testing I pushed the MTU up and didn’t get retransmitts.
It might be my SFP’s, it is possible they’re different but identifying the same.
My initial go had a lot of mud thrown at the wall, but I’ve finally narrowed down to exactly what got SFP-1 working for me, and it’s odd. sfp-reenable-autoneg.patch (511 Bytes)
Of course, as you found, auto-negotiation doesn’t work on SFP-1 or SFP-2, so neither SFP works on boot with that, but once disabled on both of them, they both kick into gear and start working.
ethtool -s eth1 autoneg off speed 2500 duplex full
ethtool -s lan4 autoneg off speed 2500 duplex full
The 2g5 modules are copper (rj45) not optical. These need additional patches not yet in mainline. But from software level the cheap oem is better supported than the tplink as it has a phy detected which can be used to show the real speed. On tplink the phy is not yet accessible from software.
Hello Daniel,
I use on my BPI R3 a GPON sfp module OEM DFP-34X-2C2 capable of both 1000base-x and 2500base-x.
Unfortunately the stable OWRT v23.05.2 only showing 1000base-x then I created following patch as per your suggestion:
target/linux/generic/pending-5.15/706-net-sfp-add-quirk-for-DFP-34X-2C2.patch
text
Enabling this option makes DFP-34X-2C2 working at 2500baseX
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -383,6 +366,12 @@ static const struct sfp_quirk sfp_quirks
.part = "MXPD-483II",
.modes = sfp_quirk_2500basex,
}, {
+ // OEM DFP-34X-2C2 GPON ONU can operate at 2500base-X, but report 1.2GBd
+ // NRZ in their EEPROM
+ .vendor = "OEM",
+ .part = "DFP-34X-2C2",
+ .modes = sfp_quirk_2500basex,
+ }, {
// Huawei MA5671A can operate at 2500base-X, but report 1.2GBd
// NRZ in their EEPROM
.vendor = "HUAWEI",
and after the compilation with patch ethtool correctly showing:
Settings for eth1:
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
Can you please add the patch for this stick in the openwrt development so that it will be embedded in next versions?
Thanks in advance from all DFP-34X-2C2 users.
As I don’t have the hardware myself for testing the best would be you submitted this patch to upstream Linux mailing lists. As things have advanced in upstream Linux since v5.15, the equivalent patch you should submit to netdev mailing list would look like that:
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 2abc155dc5cf8..a14f61bab256f 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -495,6 +495,9 @@ static const struct sfp_quirk sfp_quirks[] = {
// 2500MBd NRZ in their EEPROM
SFP_QUIRK_M("Lantech", "8330-262D-E", sfp_quirk_2500basex),
+ // DFP-34X-2C2 GPON ONU supports 2500base-X
+ SFP_QUIRK_M("OEM", "DFP-34X-2C2", sfp_quirk_2500basex),
+
SFP_QUIRK_M("UBNT", "UF-INSTANT", sfp_quirk_ubnt_uf_instant),
// Walsun HXSX-ATR[CI]-1 don't identify as copper, and use the
Once sent to Linux netdev kernel mailing list, the patch will show up in Netdev + BPF - Patchwork
From there, download the patch file and add it to (including the complete patch description and X-Patchwork* headers, so we can track it and remove it once we move to newer kernels which will then include it) to both target/linux/generic/pending-5.15 and target/linux/generic/pending-6.1. Then make change both patches so they actually build and work on Linux 5.15 and Linux 6.1 (ie. the patch content will then look like what you are suggesting above, but include a patch description and X-Patchwork… headers), commit that to your local openwrt.git checkout and submit the resulting patch to OpenWrt’s openwrt-devel mailing list or open a pull request on Github.
If you face any difficulties or have questions, please ask, I will help and assist you along the process.
So this is linux not openwrt specific…openwrt then adds the patches from linux
You send patches to the recipients listed by get_maintainer.pl script of linux source. Get net-next source first,add your changes and use git format-patch to get patchfile