I’m no expert in sfps…i only have 3 where 2 working in mainline linux (1g+10g sfp) and one (2,5gbit with realtek phy) working with erics patches.
Vendor string looks strange
And ethtool misses the link partner advertised modes in upstream image…maybe try with phylink debug to see advertising on both sides
But again we discussing specific issues in a generic thread…
This path enable sfp adapter dfp-34x-2c2 to work in 2500mb mode, but in frimware from MTK - BPI-R4-BE1350-WIFI_MP4_0-SDK-20240620 my dfp-34x-2c2 work in 1000mb mode. Then why should I patch the image to work in 2500mb mode, if on the old image everything works in 1000mb mode. Maybe there is a more current solution. I’m ready to check, since I have everything on hand. If you have any ideas, I’m willing to try them.
Good afternoon. This is a complete copy of ODI dfp-34x-2c2, today I specially flashed it with the latest current firmware M114_sfp_ODI_hybrid_221209 from Anime4000, configured and received a stable connection on the firmware from MTK - BPI-R4-BE1350-WIFI_MP4_0-SDK-20240620, You can see this above in my message.
Btw, do you have the full dmesg log that after module plugged in when using snapshot? And this stick is not a real ODI stick?
No, there is no full dmesg log, this stick is a complete oem copy of ODI, I repeat once again, I previously had a bpi-r3 and there were no problems with it at all, the connection was always fast and stable. Tell me what log exactly you need and how to make it, tomorrow morning I will conduct tests and make a log entry.
I just thought it is possible that there are some related error report but has no “sfp” inside so grep won’t list it.
Hi, I have tried this and it has no effect - it actually breaks Luci - one can’t access the Network tab, I am using - OpenWrt SNAPSHOT r27350-c4a9265160 / LuCI Master 24.212.79282~65b8002
Hello everyone, today I did a test - downloaded the latest snapshot image, turned off autoneg off using ethtool and my dfp-34x-2c2 started working!!! I temporarily threw a script into startup to turn off autoneg.
Interestingly that on my r3+snapshot(SNAPSHOT r27426-232cc239b8 / LuCI Master 24.258.73557~4728618), autoneg doesn’t need to be disabled when using ODI stick. @dangowrt @frank-w Maybe this is a driver issue? I’m using the same firmware in the pon stick so it shouldn’t be pon’s firmware issue.
Settings for eth1:
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: yes
root@OpenWrt:~# uname -a
Linux OpenWrt 6.6.51 #0 SMP Sun Sep 15 22:19:49 2024 aarch64 GNU/Linux
On my old router bpi-r3 i no need any config to work dfp-34x-2c2, all working out of box. This trouble have my new bpi-r4.
The mtk hardware is not capable of doing inband auto-negotiation for 2500-basex. The linux kernel has no mechanism of dealing with this situation. Ideally, there should be a way for all phy- and mac-drtivers for all hardware to report their inband capabilities. Then phylink can setup both mac and phy, so they are working nicely together.
But there is no such thing (yet). It is very difficult to implement, because there is no standard for it yet and already much different hardware, implementing it all in different ways.
That patch is a crude solution that does something like it, but very simple and only applicable on R3/R3mini, and probably R4 also.
Another solution is to patch phy- and mac-drivers to handle this situation specifically on the hardware that it is being build for. I think this is still done on openwrt. So these patches need to be included in the build, or trouble starts again.
Have you found a solution to enable these mosfets without soldering?
I am having the same problems when trying to use a Zyxel PMG3000-D20B as described here.
Thanks for reply. Have you discussed with upstream maintainers about how to solve this issue? We can’t keep such an issue only having a downstream solution.
Yes. Russell was working on something, but I guess it was not finished at that time. It is quite difficult to find a universal solution.
I have now removed the mosfets and replaced them with solder bridges as suggested in the linked post. The Modules now show up correctly in dmesg.
I am looking for a 1 Gbps SPF/RJ45 adapter, compatible with the BPI-R4, to increase the number of Ethernet ports in my BPI-R4 box. I want to use the BPI-R4 like a router device in my lab. Each Ethernet port as the gateway for separate ipv4 LANs.
This SFP/RJ45 module listed on the Banana PI R4 site:
https://wiki.banana-pi.org/Getting_Started_with_BPI-R4#1.EF.BC.8910G_SFP_Module
AliExpress is the only place where it is available @ about USD 40/each
Besides the above are there any other SPF/RJ45 adapters (1Gbps OK) that work out of the box in BPI-R4? Please reply with brand/model. Thanks.
https://nl.aliexpress.com/item/1005006215128124.html
They sell a module with the 88E1111 inside. It is best supported in all linux distro’s. They sell 2 different ones, GSFP-1G-T and GSFP-1G-TX, so better contact them and ask them what is the difference…
Probably the difference is as described in this commit’s description.:
[PATCH v3] net: phy: marvell: add special handling of Finisar modules with 88E1111 (kernel.org)
With all the other 1g sfp modules on aliexpress it is unclear what is inside, unless you spend 20 or more on finisar of similar brands.
I am recently bought this adapters - https://aliexpress.com/item/1005007271882485.html?sku_id=12000040029177418 and its works perfectly fine with 1gbit and 2.5gbit standarts with bpi-r4
$40 for 3 pieces
and what i really like, this module have much lower temperature and power consumption then 10gbit version
root@OpenWrt:~# ethtool -m eth2
Identifier : 0x03 (SFP)
Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
Connector : 0x07 (LC)
Transceiver codes : 0x00 0x01 0x00 0x00 0x00 0x00 0x02 0x00 0x00
Transceiver type : SONET: OC-48, short reach
Encoding : 0x05 (SONET Scrambled)
BR, Nominal : 2500MBd
Vendor name : OEM
Vendor OUI : 00:00:00
Vendor PN : SFP-2.5G-T
Vendor rev : 1.0
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 : XC202409051030
Date code : 240905
Optical diagnostics support : Yes
Laser bias current : 6.000 mA
Laser output power : 0.5000 mW / -3.01 dBm
Receiver signal average optical power : 0.4000 mW / -3.98 dBm
Module temperature : 52.64 degrees C / 126.75 degrees F
Module voltage : 3.3233 V
Module temperature high alarm threshold : 95.00 degrees C / 203.00 degrees F
Module temperature low alarm threshold : -50.00 degrees C / -58.00 degrees F
Module temperature high warning threshold : 90.00 degrees C / 194.00 degrees F
Module temperature low warning threshold : -45.00 degrees C / -49.00 degrees F
Could you please show the output of:
dmesg | grep sfp
Then we know which phy we are buying…