Getting 2.5G Working with RTL960x XPON Sticks on the Turris Omnia: LAN_SDS_MODE and the EEPROM Step
Mode 6 is the right answer — but it’s only half the job
If you’re running an RTL960x-based XPON stick like the Luleey LL-XS2510 or the ODI DFP-34X-2C2 in a Turris Omnia, and ethtool is showing only 1000baseX/Full with no mention of 2.5G, you’re dealing with two separate problems that need to be solved in order. The first is the LAN_SDS_MODE setting inside the module. The second is how the Linux kernel reads the module’s I2C EEPROM to decide what link speeds to advertise. Most guides address one or the other. You need both.
What LAN_SDS_MODE actually controls
The RTL960x chip has a host-side SERDES interface — the physical signaling it uses to talk to the router’s SoC. LAN_SDS_MODE sets which protocol that SERDES uses. Three values are relevant to 2.5G:
- Mode 4 — HiSGMII PHY: The stick presents itself as a PHY, expecting the host to provide a HiSGMII MAC. Used with routers and switches built around a Realtek MAC, including certain MikroTik units.
- Mode 5 — HiSGMII MAC: The inverse — the stick acts as a MAC over HiSGMII. Less common in practice.
- Mode 6 — 2500Base-X: Standard 2500Base-X signaling, suitable for hosts that implement it through a standard MAC/PCS stack.
HiSGMII is a Realtek-proprietary protocol. The Turris Omnia’s Marvell Armada 385 SoC does not speak it. Its mvneta Ethernet driver uses standard inband/2500base-x mode when negotiating at 2.5G on the SERDES. Modes 4 and 5 will leave the host unable to lock onto the link above 1G. Mode 6 is the correct setting for the Omnia.
How to set LAN_SDS_MODE on the LL-XS2510
Assuming you can reach the module’s built-in telnet CLI (default address is typically 192.168.100.1 when the stick is in a bridged mode), the command is short:
flash set LAN_SDS_MODE 6
rebootThe module needs a full reboot for the change to apply. After it reconnects, the Omnia’s kernel log should include a line along the lines of mvneta ... switched to inband/2500base-x link mode, which confirms the SERDES link came up at the right speed. You can check with dmesg | grep mvneta.
The worry about bricking the module is reasonable but mode-specific. Setting an incompatible mode (like 4 or 5 on a host that doesn’t speak HiSGMII) breaks the network link to the module, leaving you with no easy way back in. Mode 6 on an Omnia should negotiate cleanly, since that’s exactly what the Armada 385’s SERDES supports. Still, if you’re doing extensive experimentation, knowing how to reach the UART console beforehand is the sensible precaution.
Why ethtool still shows only 1000baseX after the mode change
This is where most guides stop, and where the confusion starts. The LAN_SDS_MODE change affects the SERDES link layer on the module. Linux’s SFP subsystem, however, separately reads the module’s I2C EEPROM — the SFP MSA-standard data at address 0x50 — to determine what link modes to expose to the network stack. If the EEPROM’s extended compliance byte (byte 36 of lower page 0) doesn’t include the 2500Base-X bit, the kernel will never offer 2500base-x as a link mode option, regardless of what the module is actually signaling on the wire.
That is why ethtool reports only 1000baseX/Full. The module’s EEPROM is telling the kernel it only supports 1G. The SERDES mode and the EEPROM advertisement are independent. Both need to match the target speed.
Option 1: Patch the SFP EEPROM
The RTL960x community has documented how to modify the module’s internal EEPROM so it correctly advertises 2500Base-X support. The relevant field is the extended compliance code at byte 36. Setting the appropriate bits there causes the Linux SFP driver to recognise the module as 2500base-x capable, which in turn allows mvneta to negotiate at that speed automatically — no kernel patch required on the router side.
The exact byte value depends on the firmware version running on the module. The Anime4000/RTL960x GitHub repository has worked examples for several variants, including notes specific to the LL-XS2510 and the DFP-34X-2C2.
Option 2: Kernel-side speed override
If EEPROM modification isn’t an option, a kernel patch can force the SFP subsystem to treat a specific module as 2500base-x capable based on the module’s vendor ID strings. Patches for RTL960x-based sticks have circulated in both the Turris and OpenWrt communities. The tradeoff is that this fix lives on the router, not the module, so you’d need to rebuild the kernel or wait for an upstream update that includes it. It’s less portable — move the stick to another router and you’re back to 1G unless that router also has the patch.
The full sequence from start to finish
Here’s the order of operations that works on an Omnia with an RTL960x stick:
- Telnet into the module and check the current value with
flash get LAN_SDS_MODE. - Set
flash set LAN_SDS_MODE 6and reboot the module. - After reconnect, run
dmesg | grep mvnetaon the Omnia and confirm the link shows inband/2500base-x. - Check
ethtool eth2. If it still only shows 1000baseX, the EEPROM hasn’t been updated yet. - Patch byte 36 of the module’s SFP EEPROM (or apply the router-side kernel override) so Linux sees the 2500base-x compliance bit.
- Reload the SFP driver or reboot the router, then verify that ethtool reports 2500baseX/Full at Speed: 2500Mb/s.
A note on recovery
If you end up with a misconfigured SDS mode and lose the network interface to the module, some RTL960x sticks support a hardware reset by power-cycling the fiber connection several times within about thirty seconds. The module’s web management interface may also remain reachable if it’s on a separate VLAN or can be bridged from another interface. For anyone doing repeated experimentation, a USB-to-UART adapter on the module’s UART test pads is the only fully reliable recovery path — it’s a one-time soldering job that gives you access regardless of what the network interface is doing.
Sources
