SFP on turris omnia running 19.07

Is anyone using the SFP wan port on a Turris Omnia running OpenWRT 19.07 (not Turris OS 4.x)?
If so, can you post instructions?
I tried the suggested "ln -sf armada-385-turris-omnia-sfp.dtb /boot/dtb && reboot", but it only seems to work for Turris OS 4.x, at least it didn't seem to work for me.
Thanks.

What is the output of

  • ls -al /boot ?
  • logread | grep sfp ?

This thread [1] might help.


[1] Turris Omnia: Experimental support for SFP cage

1 Like

The boot protocol is quite different between TurrisOS and OpenWRT.
If you have OpenWRT 19.07 installed, sysupgrade should have set this u-boot environment variable for you:

# fw_printenv openwrt_mmcload
openwrt_mmcload=setenv bootargs "$openwrt_bootargs cfg80211.freg=$regdomain"; fatload mmc 0 0x01000000 zImage; fatload mmc 0 0x02000000 armada-385-turris-omnia.dtb

So, by default u-boot tries to load armada-385-turris-omnia.dtb from the FAT filesystem in /dev/mmcblk0p1, which is the boot partition and not mounted by default. Putting something in /boot will not have any effect.
I suggest you mount /dev/mmcblk0p1 somewhere, and copy TurrisOS armada-385-turris-omnia-sfp.dtb over there, next to zImage and armada-385-turris-omnia.dtb. And then,

# fw_setenv openwrt_mmcload 'setenv bootargs "$openwrt_bootargs cfg80211.freg=$regdomain"; fatload mmc 0 0x01000000 zImage; fatload mmc 0 0x02000000 armada-385-turris-omnia-sfp.dtb'

Next time, u-boot should load the device tree for SFP.
(The experimental SFP support mentioned in the thread linked above does essentially the same thing, but you would have to build your own image)

1 Like

Thanks, it's almost working.
OpenWRT sees the SFP module, but I get the following error in the system log:

Wed Jan 22 02:30:49 2020 kern.err kernel: [ 8.599054] mvneta f1034000.ethernet eth2: validation of 802.3z/1000base-x with support 00000,00002440 failed: -22

errno 22 prints hint

EINVAL 22 Invalid argument

It is strange that MVNETA is printing that error since the validation is done by SFP-BUS (and necessary arguments probably parsed back to MVNETA)


Did you customise the kernel build conf? The disto's source code [2] sets CONFIG_SFP=y for the MVEBU target and thus the drivers SFP-BUS and SFP should be present.

What is the output of:

  • logread | grep sfp
  • ethtool eth2
  • ethtool -i eth2
  • ethtool -m eth2

Which hardware revision [3] is the node?


[2] https://git.openwrt.org/?p=openwrt%2Fopenwrt.git&a=search&h=HEAD&st=grep&s=CONFIG_SFP
[3] https://docs.turris.cz/hw/omnia/revisions/

For reference, just in case you have a similar SFP module:
I have a TP-LINK TL-SM321B (1000Base-BX10 compatible, but different wavelength pair). When I still was at kernel 4.14, I had to back-port the following two patches from 4.19, to make it work:
sfp: add support for 1000Base-PX and 1000Base-BX10
net: phy: sfp: fix the BR,min computation

Turris Omnia (version RTROM01, running OpenWRT 19.07)

dmesg | grep -E "eth2|sfp"
[    1.134317] mvneta f1034000.ethernet eth2: Using hardware mac address d8:58:d7:00:57:9a
[    8.505524] sfp sfp: module UBNT             UF-SM-1G-S       rev      sn FT18051615332    dc 16-05-18
[    8.514863] sfp sfp:   LC connector, encoding 8b10b, nominal bitrate 1.3Gbps +0% -0%
[    8.522628] sfp sfp:   1000BaseSX- 1000BaseLX- 1000BaseCX- 1000BaseT- 100BaseTLX- 1000BaseFX- BaseBX10+ BasePX-
[    8.532742] sfp sfp:   10GBaseSR- 10GBaseLR- 10GBaseLRM- 10GBaseER-
[    8.539023] sfp sfp:   Wavelength 1310nm, fiber lengths:
[    8.544349] sfp sfp:     9µm SM    : 3000m
[    8.548539] sfp sfp:  62.5µm MM OM1: unsupported/unspecified
[    8.554300] sfp sfp:    50µm MM OM2: unsupported/unspecified
[    8.560058] sfp sfp:    50µm MM OM3: unsupported/unspecified
[    8.565818] sfp sfp:    50µm MM OM4: unsupported/unspecified
[    8.571578] sfp sfp:   Options: hpl, txfault, los+
[    8.576382] sfp sfp:   Diagnostics: ddm, intcal, rxpwravg
[    8.581799] mvneta f1034000.ethernet eth2: validation of 802.3z/1000base-x with support 00000,00002440 failed: -22
[   11.117303] mvneta f1034000.ethernet eth2: configuring for SGMII/sgmii link mode
[   11.125165] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready

Another Turris Omnia (same version, running Turris OS 4.0.3)

dmesg | grep -E "eth2|sfp"
[    4.404289] mvneta f1034000.ethernet eth2: Using hardware mac address d8:58:d7:00:5a:82
[    5.252577] sfp sfp: module UBNT             UF-SM-1G-S       rev      sn FT18051615350    dc 16-05-18
[    5.261914] sfp sfp:   LC connector, encoding 8b10b, nominal bitrate 1.3Gbps +0% -0%
[    5.269676] sfp sfp:   1000BaseSX- 1000BaseLX- 1000BaseCX- 1000BaseT- 100BaseTLX- 1000BaseFX- BaseBX10+ BasePX-
[    5.279790] sfp sfp:   10GBaseSR- 10GBaseLR- 10GBaseLRM- 10GBaseER-
[    5.286073] sfp sfp:   Wavelength 1310nm, fiber lengths:
[    5.291398] sfp sfp:     9µm SM    : 3000m
[    5.295589] sfp sfp:  62.5µm MM OM1: unsupported/unspecified
[    5.301349] sfp sfp:    50µm MM OM2: unsupported/unspecified
[    5.307106] sfp sfp:    50µm MM OM3: unsupported/unspecified
[    5.312866] sfp sfp:    50µm MM OM4: unsupported/unspecified
[    5.318626] sfp sfp:   Options: hpl, txfault, los+
[    5.323429] sfp sfp:   Diagnostics: ddm, intcal, rxpwravg
[    5.328844] mvneta f1034000.ethernet eth2: switched to 802.3z/1000base-x link mode
[   20.152651] mvneta f1034000.ethernet eth2: configuring for 802.3z/1000base-x link mode
[   20.161971] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
[   20.471348] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[   20.479214] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
[   24.595923] mvneta f1034000.ethernet eth2: Link is Down
[   24.734067] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off

Pretty sure my hardware version is CZ11NIC13, as all three were purchased on Indiegogo campaign.

I'm using the stock 19.07 OpenWRT release. I haven't tried any of the recent development builds.

The MVNETA error is present on OpenWrt but not TOS and latter subsequent configuring the correct link mode, assuming this not being a hardware fault in the module that is hosted in the OpenWrt node - did you exchange the modules?

Maybe as @kkudielka pointed out one of those patches will remedy the issue. There are also a few recent SFP related commits in the OpenWrt Master branch [4].

However, somehow the issue seems to be with 802.3z and MVNETA.

If it is neither a hardware fault and the patches not providing a relief either I could only reckon that the Device Tree in TOS is different than the one in OpenWrt.


[4] https://git.openwrt.org/?p=openwrt%2Fopenwrt.git&a=search&h=HEAD&st=commit&s=sfp

I've already swapped the SFP modules, which didn't help.
I'll try the latest development release.

With the latest dev snapshot, I get a different failure:


grep -E "eth2|sfp"
[    1.169504] mvneta f1034000.ethernet eth2: Using hardware mac address d8:58:d7:00:57:9a
[    8.654165] sfp sfp: Host maximum power 1.0W
[    8.974491] sfp sfp: module UBNT             UF-SM-1G-S       rev      sn FT18051615332    dc 180516
[    8.983833] sfp sfp: Host does not support 2.0W modules, module left in power mode 1
[    8.991602] mvneta f1034000.ethernet eth2: switched to inband/1000base-x link mode
[   11.302463] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
[   11.311423] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
[   11.477952] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[   11.485853] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
[   15.918414] mvneta f1034000.ethernet eth2: Link is Down
[   16.046610] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off

Actually, even with the errors, the SFP interface is working.
So the dev snapshot seems to have the right updates.

ls -aF /boot => "./ ../ dtb@"
ethtool -m eth2 -> "Cannot get module EEPROM information: Not supported"

I saw the thread you mentioned. It doesn't give a clear recipe for success, at least that I could see.

Thanks.

Mike

Take it that you reverted from Master to 19.07? You would again have to go through SFP on turris omnia running 19.07


The issue in 19.07 that is causing

[ 8.581799] mvneta f1034000.ethernet eth2: validation of 802.3z/1000base-x with support 00000,00002440 failed: -22

are apparently some missing SFP related patches in 19.07. Potential avenues to deal with the matter:

  • custom build a 19.07 image for the TO that includes the patches
  • join the OpenWrt developer IRC channel and raise the subject there
  • lodge a bug report on OpenWrt's bug tracker (since it impedes the device functionality it might be accepted as bug) and wait for a developer to remedy the issue
  • if you have the ability submit a patch to the OpenWrt developer mailing list