FS 2.5GBase-T SFP not working with Turris Omnia (2024)

Omnia hardware Omnia HW help
1

Hi,

I am trying to get the FS 2.5G SFP module to work without success.
This is the same reference that @ju2wheels got working in a previous topic

Am I missing something, or is the version I got an updated version that is not compatible ?
In the logs I see that the OP’s serial was FS SFP-2.5G-T rev 1.0 sn G2230090032 dc 220711, while my version is FS SFP-2.5G-T rev 1.0 sn G2410075672 dc 240216

Here are the technical info:

  1. OS version
    TurrisOS 7.0.0 (hbt branch)

I tested HBL branch too, no success, and couldn’t test with HBD branch due to package updater issues.

  1. dbt points to sfp file:
root@turris:~# ls -l /boot
-rw-r--r--    1 root     root         21434 Jul 25  2022 armada-385-turris-omnia-phy.dtb
-rw-r--r--    1 root     root         21410 Jul 25  2022 armada-385-turris-omnia-sfp.dtb
-rw-r--r--    1 root     root          1199 Jul 25  2022 boot.scr
lrwxrwxrwx    1 root     root            37 Apr 17 12:50 dtb -> /boot/armada-385-turris-omnia-sfp.dtb
-rwxr-xr-x    1 root     root       4282696 Apr  2 03:01 zImage
  1. Logs
root@turris:~#  dmesg | grep -E "sfp|mvneta"
[    1.794461] mvneta_bm f10c8000.bm: Buffer Manager for network controller enabled
[    1.803483] mvneta f1070000.ethernet eth0: Using device tree mac address XXX
[    1.813053] mvneta f1030000.ethernet eth1: Using device tree mac address XXX
[    1.822592] mvneta f1034000.ethernet eth2: Using device tree mac address XXX
[   10.105192] sfp sfp: Host maximum power 3.0W
[   10.441714] sfp sfp: module FS               SFP-2.5G-T       rev 1.0  sn G2410075672      dc 240216  
[   26.123602] mvneta f1030000.ethernet eth1: configuring for fixed/rgmii link mode
[   26.131771] mvneta f1030000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
[   27.047795] mvneta f1034000.ethernet eth2: configuring for inband/sgmii link mode
[   27.334791] mvneta f1034000.ethernet eth2: validation with support 0000000,00000000,00000000 failed: -22
[   27.344410] sfp sfp: sfp_add_phy failed: -22

And ethtool for good measure

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

This needs to backport a patch from upstream kernel. I will look into this.

4 Likes
3

Thanks for investigating.
Let me know if there’s any way I can help move the fix along. I’m available if you need to test a fixed version on my hardware :slightly_smiling_face:

4

now being built in crashlab branch, should be ready in several hours

you will need to change into the crashlab branch with

switch-branch --force crashlab
2 Likes
5

@cm1 It is built, you can try switching the branch.

6

Thansk ! tried the crashlab branch.
Update was successful and I rebooted, but still having the same issue:

[   10.191730] sfp sfp: Host maximum power 3.0W
[   10.518052] sfp sfp: module FS               SFP-2.5G-T       rev 1.0  sn G2410075672      dc 240216  
[   30.686098] mvneta f1034000.ethernet eth2: configuring for inband/sgmii link mode
[   30.995916] mvneta f1034000.ethernet eth2: validation with support 0000000,00000000,00000000 failed: -22
[   31.005509] sfp sfp: sfp_add_phy failed: -22

Is there any way to double check if I’m really running your patched version ?
I don’t know if these info are useful:

root@turris:~# switch-branch 
You are currently in: crashlab

root@turris:~# uname  -a
Linux turris 5.15.152 #0 SMP Sat Apr 20 15:08:49 2024 armv7l GNU/Linux
7

send the output of dmesg | head

8 
root@turris:~# dmesg | head
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.15.152 (packaging@turris.cz) (arm-openwrt-linux-muslgnueabi-gcc (OpenWrt GCC 11.2.0 r20301+128-ce37d2c690) 11.2.0, GNU ld (GNU Binutils) 2.37) #0 SMP Sat Apr 20 15:08:49 2024
[    0.000000] CPU: ARMv7 Processor [414fc091] revision 1 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] OF: fdt: Machine model: Turris Omnia
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x0000000000000000-0x000000002fffffff]
[    0.000000]   HighMem  [mem 0x0000000030000000-0x000000007fffffff]
[    0.000000] Movable zone start for each node
9

Yes, that’s the new one, hmmm. Would it be possible for you to give me remote access to your router via ssh so that I can examine the SFP module more?

10

yes info sent in chat message