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.