SFP on turris omnia running 19.07

farmwald · January 18, 2020, 12:08am

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.

anon45274024 · January 18, 2020, 12:41am

What is the output of

ls -al /boot ?
logread | grep sfp ?

This thread ^[1] might help.

^[1] Turris Omnia: Experimental support for SFP cage

kkudielka · January 18, 2020, 9:43am

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)

farmwald · January 22, 2020, 2:33am

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

anon45274024 · January 22, 2020, 9:55am

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/

kkudielka · January 22, 2020, 7:54pm

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

farmwald · January 22, 2020, 8:23pm

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

farmwald · January 22, 2020, 8:29pm

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

farmwald · January 22, 2020, 9:06pm

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

anon45274024 · January 22, 2020, 9:08pm

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

farmwald · January 22, 2020, 9:51pm

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

farmwald · January 23, 2020, 12:05am

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

farmwald · January 23, 2020, 12:16am

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

farmwald · January 18, 2020, 2:31am

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

anon45274024 · January 26, 2020, 8:54am

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

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

pparent76 · March 10, 2021, 11:03am

Thanks a lot for help.

Although I'm not sure to fully understand how to deploy that.

Can anybody give a set of commands to run from openwrt to make it working? (Or do you need a UART cable to give commands to Uboot?)

Is it possible to create de firmeware with image builder that works straight away?

Thanks

frollic · March 10, 2021, 11:14am

to make what work ?

pparent76 · March 10, 2021, 11:26am

To make SFP work, the page you linked says it is currently unsupported.

frollic · March 10, 2021, 11:28am

that probably applies to the stable, if still relevant.

snapshots are found at https://downloads.openwrt.org/snapshots/targets/mvebu/cortexa9/

rosbeef · July 5, 2021, 12:11am

Someone can share the .config file to do my own build as i need to include 3g-modem module by default because I have no wired connection.