Turris Omnia: Experimental support for SFP cage

Hello,

I took the time to pull together the bits and pieces, to get my SFP module (TP-Link TL-SM321B) working on the Turris Omnia. Apart from adapting the device tree and enabling the necessary I2C MUX support, I only had to backport support for 1000BaseBX10 SFP from mainline kernel.

https://github.com/kkudielka/openwrt/tree/omnia-playground

It works for me. I would be interested, if it works for others as well, including those without SFP module in the cage. The WAN PHY still should work in that case, since I left the "phy" property in the node of the eth2 MAC, in parallel with the "sfp" property. I am not completely sure, whether the underlying sfp/phylink/mvneta code has been designed to cover this case.

By the way, LED support (1:1 copy from TurrisOS) is also in the branch.

2 Likes

Hello,

i have compiled the from your github source and wan with eth2 works.
If someone wants to try the image out, here it is:

The openwrt image comes with openvpn, qos, sqm, nmap and alot of other tools.
See the packages file inside the rar-package.

Just one issue i dont understand: what are eth0 and eth1 used for?
I mean, i have lan0 to lan4 which are br-lan and eth0 to eth2.
Eth2 is the wan interface, what are eth0 and eth1 used for?

The openwrt image works without any problems so far, the gui is very responsive.
Is it also possible to configure the DSA switch?

:edit:
The original settings from turris os seems to be different from the actual openwrt config.
https://doc.turris.cz/doc/en/howto/vlan_settings_omnia

openwrt:
/etc/board.d/02_network
armada-385-turris-omnia)
ucidef_set_interface_lan "lan0 lan1 lan2 lan3 lan4"
ucidef_set_interface_wan "eth2"

Thanx for your support.

Interesting. Just to be sure, can you copy/paste the result of the very same commands on your device?

root@turris-omnia:~# ls /proc/device-tree/soc/internal-regs/ethernet@34000/
clocks               managed              reg
compatible           name                 sfp
interrupts-extended  phy-mode             status
root@turris-omnia:~# 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

Concerning eth0 & eth1: these are the physical ports between the CPU and the switch. With DSA, I guess the user is not supposed to mess with these. Instead, lan0-lan4 are presented to userspace as if they were directly connected, and thus the switch is configured as a bridge, via brctl.

(TurrisOS uses kernel 4.4 and swconfig instead)

Hello, i am not sure if i understood rightly, but isnt it possible to use swconfig then to be more flexible
with the routing of the used ports? it would be nice, if we could lets say, connect lan0 to lan3 to eth0,
lan4 to eth2 and wan / sfp port to eth1. The ability to use vlans and route to a specific port of soc´s
(free) physical ports would be great.

root@omnia:~# ls /proc/device-tree/soc/internal-regs/ethernet@34000/
clocks               name                 reg
compatible           phy                  status
interrupts-extended  phy-mode
root@omnia:~# ethtool eth2
Settings for eth2:
        Supported ports: [ TP MII FIBRE ]
        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
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Half 1000baseT/Full
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: d
        Link detected: yes

Maybe this could be backported?

Hmmm. Somehow my change to the device tree didn't make it into your image. I see the "phy" property in your tree, instead of "sfp". With the latter your WAN port would have stopped working (I tested this case today).

Anyway, a few minutes ago I pushed something more user friendly (and safer, I hope). Users with an SFP module in their cage may activate support by executing "omnia_select_device_tree sfp" once after each sysupgrade.

(a bit off-topic) Concerning switch support, I agree it would be great to have the 2nd CPU port usable. But AFAIK at this moment DSA just doesn't support it. Just google for "DSA multiple CPU ports".

Is it possible to use the luci-app-rainbow from TurrisOS to set the LED colors with your changes?

In principle, yes. The driver in the kernel is the same. I don't know whether other user-space packages (rainbow) would be needed as well.

Anyway, I'm a bit lazy and haven't tried it. Instead, I achieve the same result by editing /etc/rc.local. For instance:

echo -n "16 16 16" >/sys/class/leds/omnia-led:all/color 
echo -n "0" >/sys/class/leds/omnia-led:wan/autonomous

This is all I need. Now all LEDs are not too bright, the LAN LEDs still work autonomously, and I can configure the WAN LED to my taste, using the normal OpenWrt LED configuration tools.

I have build the current master with your 5 patches (led, f2fs, sfp) and have not encountered any issues with the wan port, but i have no sfp module to test the sfp part (but maybe i can geht some modules in a few days to test it).
I also integrated rainbow-omnia and luci-app-rainbow, now I can setup the colors like in TurrisOS (with a smal bug, somehow it does not take the colors after the first save in LUCI, the second always works)

The LED driver can be submitted on the mailing list. I recommend switching it to a kmod instead of building it in though.

I'd like to polish this a bit, before submitting. At least, users should be able to configure the hardware's extra features (global brightness and per-led color & autonomous flag) via UCI. Something like the original rainbow package, but a lot simpler.

I just re-based & pushed my branch, to give you an idea. The normal boot diagnostics works as well now (flashing power LED). What is left, is the proper packaging. So, maybe I will make a pull request next weekend.

Thank you for your work! With your last 5 commits I could use the rainbow packages, but when I set up LEDs in Luci (for example user1 led) nothing happens, the leds can not be programmed. Only coloer can be changed wit the luci-app-rainbow. Does this work with your device?

I haven't looked into rainbow in detail. But I now have an alternative solution in my last commit.

vi /etc/config/omnia
service omnia_led start

As long as autonomous=0 (it is the default for the user LEDs), you can configure the behavior using the normal luci LED configuration. Otherwise it is driven by hardware.

I have tested this (power, wan, user*), and it works on my device. Just in case, please pull the whole branch again, I have done some subtle changes while rebasing.

Yes, works now! No need for the rainbow stuff anymore. Thank you! Will try to test sfp later.

I have opened a pull request for the LED support (with kmod).
https://github.com/openwrt/openwrt/pull/1542

Sorry that the pull request did go unnoticed, but that seems to be pretty much standard. I now received SFP modules to test your patches, I should have time after christmas to test it.

Well, I tried it on the mailing list and have been politely asked to get the LED driver accepted upstream first. For the moment, I am postponing this.
Good luck with the SFP modules. Just make sure that you boot with armada-385-turris-omnia-sfp.dtb, which will be in the boot partition, besides the normal dtb. For me, it has been working perfectly over the past 2 months.

Via "omnia_select_device_tree sfp" ?

Yes, exactly.

Ok, so here are my results:

Cisco DS-SFP-FC4G-SW between Omnia and a Miktorik device -> detected, but no link can be established (modules are ok)
Flexoptix S.1312.10.D (I do not know which firmware, but Flexoptix supports Turris Omnia explicitly) between Omnia and a Mikrotik device -> works fine!