BPI-R3 SFP Module compatibility

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?

UPD2

It is said here: https://github.com/Anime4000/RTL960x/blob/main/Docs/2.5Gb.md that we can flash v2801f for proper 2,5 Gbe support. Also there is said, that sfp modules, based on RTL960x has 3 different 2.5Gb Modes: Screenshot_20230529-082537_Pixel%20Launcher

Which one should I use with BPI-R3? I got this info for eth1 interface (is eth1 correct interface for internet sfp module?) Screenshot_20230529-084701_Pixel%20Launcher

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)

https://lore.kernel.org/netdev/167955062190.14332.12018910625899155487.git-patchwork-notify@kernel.org/T/

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.

i2cdump -y 0 0x50
i2cdump -y 0 0x50
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 03 04 07 00 01 00 00 00 00 02 00 05 19 00 00 00    ???.?....?.??...
10: 1e 14 00 00 4f 45 4d 20 20 20 20 20 20 20 20 20    ??..OEM         
20: 20 20 20 20 00 00 00 00 53 46 50 2d 32 2e 35 47        ....SFP-2.5G
30: 2d 54 20 20 20 20 20 20 31 2e 30 20 03 52 00 19    -T      1.0 ?R.?
40: 00 1a 00 00 32 33 30 34 31 38 30 30 31 31 20 20    .?..2304180011  
50: 20 20 20 20 32 33 30 34 31 38 20 20 68 f0 01 99        230418  h???
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
SFP Internal Photos

top bottom phy

Yes they are recognized as such,but have not disassembled them :stuck_out_tongue:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/phy/sfp.c?id=50e96acbe11667b6fe9d99e1348c6c224b2f11dd

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

With 2500baseX mode I get the following between SFP-2 and a 1g port. Once I got SFP-1 working it performed identically.

[ ID] Interval           Transfer     Bitrate         Retr
[  6]   0.00-10.00  sec  1.10 GBytes   941 Mbits/sec    0             sender
[  6]   0.00-10.00  sec  1.09 GBytes   939 Mbits/sec                  receiver

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)

-	sfp_quirk_disable_autoneg(id, modes, interfaces);

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

I have similar SFP and after tweaking LAN_SDS_MODE to 4 - sfp module disappeared. Do you have any problems like that?

Were you able to get the 10G one to work in 2.5G mode? What does the following error in your log mean?

[ 1356.020273] mtk_soc_eth 15100000.ethernet eth1: validation with support 0000000,00000000,00000000 failed: -22

I am also getting it with this device

Any updates on the fixes getting into the main branch?

I should finally soon get my BPI-R3 soon and want to start on the correct foot.

I also ordered the recommended optical SFP module. Thank you frank-w and ericwoud!

Are those still the optical modules most likely to work?

The fixes for sfp power and thermaltrips are merged to next,so will land in 6.8.

Which modules do you mean? My h!fibre work without issues.

Thanks - good news!

The ones I was referring to was from an earlier post of yours:

Here is a new sale for 13.22€ and without shipping costs if interested:

https://m.de.aliexpress.com/item/1005005052139284.html

But I now see the H!fibre module you also mentioned:

Amazon.de

The one from ericwoud:

This one has an option to order for banana pi

€ 14,24 59%OFF | SFP-2.5GE-RJ45 Gigabit 2.5G Module SFP To RJ45 Optical Interface Expansion 2500M Rate Compatible Huawei H3C Cisco TPLINK Switch https://a.aliexpress.com/_EyiBS4l 40

Anyone have any experience?

I’ll try the H!fibre first.

Thanks!

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.

Thanks! Got the H!fibre from Amazon: https://www.amazon.com/dp/B07B47SSHH Everything works without a hitch.

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.

Hi Daniel, this is the first time fo me to submit a patch. Can you please explain what do you mean for “send to Linux netdev”. Do I have to use

git send-email [email protected] --to="[email protected]" 001-description.patch

or do I have to send to

[email protected]

or do I have to subscribe:

openwrt-devel

Thanks in advance for your help. Best regards and Merry Christmas Sergio

https://www.kernel.org/doc/html/v5.3/networking/netdev-FAQ.html

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

If 1000M is not an issue, here is a nice offer €5,92 (buy 2 for free shipping):

https://nl.aliexpress.com/item/1005006169925450.html

It says i2c access to phy, so should be ok…

1 Like

Submitted the patch and shown in Patchwork Netdev+BPF as success. What is now the next step? Thanks for your kind help.

waiting for the patch to be reviewed and applied :slight_smile:

can you post link to the patch (patchwork)?