2.5G with Luleey LL-XS2510 SFP and Omnia

There have been some threads already on this community discussing how to get the Turris SFP-cage to actually perform at 2.5G with compatible modules. If memory serves right, most of them revolved about DAC. So not the Luleey LL-XS2510 XPON module, that I am using in my device right now.

Other communities discuss “my” SFP but unfortunately do use them in Unify or Mikrotik equipment - so not directly applicable either…

Since blindly following some tutorials will probably render the SFP inoperational, I’d rather talk it through here with you - hoping that someone else might be using the exact same setup and can share some insights.

The LL-XS2510 ist a RTL960x/DFP-34X-2C2 based XPON-SFP that in theory should not only support 1G but also 2.5G operation.

However, when plugging the device into the Omnia, it will only operate in 1000baseX/Full mode - and ethtool won’t even mention 2.5G:

root@turris:~# ethtool eth2
Settings for eth2:
	Supported ports: [ FIBRE ]
	Supported link modes:   1000baseX/Full 
	Supported pause frame use: Symmetric
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  1000baseX/Full 
	Advertised pause frame use: Symmetric
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Speed: 1000Mb/s
	Duplex: Full
	Port: FIBRE
	PHYAD: 0
	Transceiver: internal
	Auto-negotiation: on
	Supports Wake-on: d
	Wake-on: d
	Link detected: yes

Looking at the threads in the community here, people seem to be part of three camps:

  • Either it just works out of the box (great! happy for you!)
  • There is some problem with the i2c-communication which can be fixed by disabling auto-negotiation and fixing the speed to 2.5G
  • Use a kernel-patch to load some workaround to automatically pin the interface-speed to 2.5G

Number one does obviously not apply, and I can’t see any problems in the sys- or kernel-log that would indicate number two. Also, since ethtool seems to be convinced that 1000baseX is the only way to go, I cannot change the configuration of the port to 2.5G either…

Looking at RTL960x/Docs/2.5Gb.md at main · Anime4000/RTL960x · GitHub or ODI Realtek DFP-34G-2C2 | Hack GPON, there are three modes that can be used to force the SFP into 2.5G by using the flash set LAN_SDS_MODE command:

  • 4 for HiSGMII PHY
  • 5 for HiSGMII MAC
  • 6 for 2500Base-X

What is keeping me from just randomly issuing the above command is the fact, that choosing the wrong LAN_SDS_MODE will render the module unusable if the surrounding hardware does not support it. And since I do not have a media-converter or other router that just supports all of those modes (and my desire to start soldering an UART connection to the module is pretty low), that would translate to “no internet” for me…

My interpretation of the output of ethtool above would make me want to believe that mode 6 (2500Base-X) would be the correct one - but I am not 100% sure. Anyone here that can confirm/deny it?

Thank you for everyone’s input!

Actually I bricked RTL960x module with Animes firmware by choosing wrong mode. Was lazy to recover that. But I do use different module now. And I am using a patch to sfp.c in kernel to make it force advertize 2,5Gig. And it works.

If you give me branch you use on your Omnia and output from:

dmesg | grep -E "sfp|mvneta"

I might build a kernel for you as anyway I have to do one for me and it can be the same kernel just a patch in two places. It might work if your module supports autoneg. Do you know what chipset it is based on?

Edit: Owww so its RTL960x based hmmm…
Well we might try. I will try to build a kernel during the weekend. Make a snapshot before installing it and thats it. If something goes wrong then mode 2 recovery. But I believe it should work. And doesnt alter the SFP module so its eeasier to recover

I know from Anime4000 wiki that some firmwares on RTL960x support autoneg and for some you have to set lan mode. Then probbably you dont need a patch and just set a mode

Very much appreciated - I did indeed see your patch and I was about to start setting up a build env and try to adapt it… But your offer would take out much of the guesswork :slight_smile:

root@turris:~# dmesg | grep -E "sfp|mvneta"
[    1.823206] mvneta_bm f10c8000.bm: Buffer Manager for network controller enabled
[    1.832238] mvneta f1070000.ethernet eth0: Using device tree mac address d8:58:d7:00:7f:06
[    1.841823] mvneta f1030000.ethernet eth1: Using hardware mac address d8:58:d7:00:7f:05
[    1.851129] mvneta f1034000.ethernet eth2: Using hardware mac address d8:58:d7:00:7f:06
[   10.648458] sfp sfp: Host maximum power 3.0W
[   10.978555] sfp sfp: module OEM              XPON-Stick       rev      sn XPON24050026     dc 240506  
[   10.991842] mvneta f1034000.ethernet eth2: switched to inband/1000base-x link mode
[   19.938230] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[   19.974572] mvneta f1030000.ethernet eth1: configuring for fixed/rgmii link mode
[   19.982986] mvneta f1030000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[   46.556318] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control rx/tx

Running on Turris OS 7.0.2 HBS, Kernel 5.15.148

@pc-coholic Hi so I re-thought that and I think it wont work with the kernel patch. Simply because the SFP based on RTL960x is not working internally in 2,5Gbps mode.

But I will confirm that when I unbrick the RTL960x I have and check it out.

From what I understand LAN_MODE of 6 should do the trick. But dont consider that as an advice I will check it out on the SFP I have and confirm that. Anyway mine is bricked so lets spare you the problems

Edit: i ordered SFP breakout PCB:

Not from this shop because of the riddiculus price but just 5x pcb only.
I should have components to make 2 of them for now. Just to unbrick that SFP.

Off topic: @backon will you be interested in one PCB after I recieve them? You are experimenting with different SFPs. Let me know in DM I may send you one for shipping cost only.

2 Likes

For my DFP-34X-2C3 I followed this guide to force 2500base-X by editing the module’s EEPROM: Right SFP EEPROM config for DFP-34X-2C2 to work automatically work at 2500base-X? · Anime4000/RTL960x · Discussion #250 · GitHub

Now my omnia detects it as 2500base-x. Since you don’t have the same model, there might be differences in what you need to change if you go that way. I for example had to set the checksum as 0x81 instead of 0x80, since the guide is for the 2C2 variant and I have the 2C3.

Also after this change, the SFP will not advertise 1000baseX support so it will not work on 1gbit media converters etc.

2 Likes

@AreYouLoco Did you ever get a chance to test if LAN_SDS_MODE 6 would fix the issue on your bricked SFP?

Somehow using the LAN_SDS_MODE command makes me less nervous than following the guide @alex posted… :wink:

Well I soldered the SFP Breakout Board. But UART access pins are so tiny and also SFP takes more current than I able able to supply from USB so it doesnt fully boot. I didnt figure it out yet.

Probabbly precise soldering (so free time needed) and some external 3V3 source.

I will ask guys from local HS if they may borrow some PSU to use.

So I did bite the bullet and tried flash set LAN_SDS_MODE 6 - and exactly nothing happened…

Powercycled the router and the SFP, the setting was retained - but still only a 1000-BaseX connection. At least I didn’t brick my SFP :sweat_smile:

Uninstalling mwan3 did also improve throughput (900-950 from 700-750); but still below the 1G+ that I get by chucking the SFP into a media-converter and connecting laptop directly to it.

Maybe now a kernel patch is needed. That I did to mine SFP to inform Omnia to negotiate 2,5Gbps.

Give me the output of ethtool eth2 and dmesg grep -E “(mvneta|sfp)”

Also as stated on Anime4000 wiki some RTL960x have autoneg and some not. Maybe yours have it there are CI and D exact models of chipset. Normally you should have a brick but somehow its auto negotiating 1Gbps so you might have D model. I think now we need to inform Omnia that your SFP can do 2,5Gbps and it might work.

I will build a kernel for you to try.

Owww wait you already have posted it above. Ok so I am building in a moment. Will prepare a patch.

@pc-coholic Done.

I hope mega is ok. Make sure to do:

schnapps create "Before new kernel"

Put file in /srv (if you have a msata drive. If not wherever)
then

opkg install --force-reinstall /srv/kernel_5.15.148-1-f107ab883b9ff1076967eb64dab57050_arm_cortex-a9_vfpv3-d16.ipk
reboot

And check speed (if it boots :sweat_smile:) if not then rollback but should work.
Its rebased on v7.1.3 tag from the turris_build repo. And backdoors included for free ofc😉

Thank you for the backdoors :wink:

So I installed the new kernel and even switched back to LAN_SDS_MODE 6 - but no changes unfortunately…

root@turris:~# dmesg | grep -E "sfp|mvneta"
[    1.836516] mvneta_bm f10c8000.bm: Buffer Manager for network controller enabled
[    1.845583] mvneta f1070000.ethernet eth0: Using device tree mac address d8:58:d7:00:7f:06
[    1.855166] mvneta f1030000.ethernet eth1: Using hardware mac address d8:58:d7:00:7f:05
[    1.864455] mvneta f1034000.ethernet eth2: Using hardware mac address d8:58:d7:00:7f:06
[   10.465709] sfp sfp: Host maximum power 3.0W
[   10.812779] sfp sfp: module OEM              XPON-Stick       rev      sn XPON24050026     dc 240506  
[   10.822178] mvneta f1034000.ethernet eth2: switched to inband/1000base-x link mode
[   24.135560] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[   24.174038] mvneta f1030000.ethernet eth1: configuring for fixed/rgmii link mode
[   24.181956] mvneta f1030000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[   49.673416] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control rx/tx

Is your module working at 2,5Gbps in the media converter? What do you get from

flash get LAN_SDS_MODE

I guess I was doing something too fast. Will try to build again today. But in gemeral there is sfp.c file in kernel sources. And there are some quirks added by kernel developer @rmk that I tried to use. To force inform that module supports 2,5Gbps based on vendor and module name.

Running the SFP in the media converter, flash get LAN_SDS_MODE does return LAN_SDS_MODE0=0 - which kinda makes sense, since that’s the value it’s configured to…?

cat /proc/lan_sds/lan_sds_cfg however is returning lan_sds_mode = 4(HiSGMII PHY), whereas within the Omnia it’s (as expected) lan_sds_mode = 1(Fiber 1G)

Hi @pc-coholic here is new build:

Same procedure with snapshot before. Then install && reboot. And please show me what ethtool eth2 shows

1 Like

Well would you look at this :slight_smile:

martin@catate:~/Downloads$ ssh root@192.168.1.1 -l root
 Warning: Changes performed using anything other than
 official web interface reForis are not covered by
 Turris support team unless instructed!


BusyBox v1.35.0 (2024-04-02 01:04:13 UTC) built-in shell (ash)

      ______                _         ____  _____
     /_  __/_  ____________(_)____   / __ \/ ___/
      / / / / / / ___/ ___/ / ___/  / / / /\__ 
     / / / /_/ / /  / /  / (__  )  / /_/ /___/ / 
    /_/  \__,_/_/  /_/  /_/____/   \____//____/  
                                             
 -----------------------------------------------------
 TurrisOS 7.1.3, Turris Omnia
 -----------------------------------------------------
root@turris:~# ethtool eth2
Settings for eth2:
	Supported ports: [ FIBRE ]
	Supported link modes:   2500baseX/Full
	                        1000baseX/Full
	Supported pause frame use: Symmetric
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  2500baseX/Full
	Advertised pause frame use: Symmetric
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Speed: 2500Mb/s
	Duplex: Full
	Auto-negotiation: on
	Port: FIBRE
	PHYAD: 0
	Transceiver: internal
	Supports Wake-on: d
	Wake-on: d
	Link detected: yes
root@turris:~# 
martin@catate:~/Downloads$ ssh sfp
admin@192.168.1.4's password: 


BusyBox v1.22.1 (2024-10-26 11:47:05 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

# cat /proc/lan_sds/lan_sds_cfg 
lan_sds_mode = 4(HiSGMII PHY)
# 

Amazing work, thank you :slight_smile:

Ok but can you actually achieve speeds over 1Gig? Also to note that pkgupdate will reinstall kernel so be sure to disable auto updates for now. Or keep them on approval and reinstall kernel after update from the package.

I will share modification I made so you may rebuild yourself if I die tomorrow or something😅

Well… I guess it depends on how I am looking at it…

Running a speedtest agains https://telekomde.speedtestcustom.com/ (which seems to be the most reasonable one to use since it’s the one provided by my ISP - and which yielded 1G+ using the media converter), max-speed is still around 900 to 950.

htop is reporting 100% usage of one of the two CPU-cores by ksoftirqd/0.

Just for fun, I ran two concurrent speedtests which - at least in the luci-provided realtime charts - peak at 1.4GBit…

I am wondering, if this might be related to the issues outlined in this article: APU2 1Gbit throughput on pfSense (configuration instructions)

In luci there is global configuration in network and try to enable packet steering to balance on both cores.

Also some other fix I found:


echo 3 > /sys/class/net/eth0/queues/rx-0/rps_cpus
echo 3 > /sys/class/net/eth1/queues/rx-0/rps_cpus
echo 3 > /sys/class/net/eth2/queues/rx-0/rps_cpus

I have it added in /etc/rc.local

But you may enable packet steering and run those 3 echo commands from console and then again speedtest and htop to check core usage

This is helping - usage of both cores and it did push me over the 1G threshold :slight_smile:

Well then enjoy your fast internet today. My contract is ONLY 400Mb/200Mb even tho SFP negotiates 2,5Gbps as well with a patch. But enough for normal usage.