Turris Omnia: Experimental support for SFP cage

For Developers
5

Maybe this could be backported?

6

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".

1 Like
7

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

8

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.

1 Like
9

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)

10

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

11

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.

12

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?

13

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.

14

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

15

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

16

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.

17

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.

1 Like
18

Via "omnia_select_device_tree sfp" ?

19

Yes, exactly.

20

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!

1 Like
21

Good to hear.

Concerning the Cisco module, it seems to be advertised as Fibre Channel SFP module (and not Ethernet). There seems to be a lot of guesswork involved during parsing of the SFP firmware (phylink.c et al). Maybe Mikrotik and Linux do it in different ways, ending up in incompatible configurations.

1 Like
22

Maybe that is why TurrisOS has this https://github.com/CZ-NIC/turris-misc/blob/master/sfpswitch/sfpswitch.py ? The module can work as 1Gb Ethernet.

1 Like
23

In my understanding of recent Linux kernels (>=4.14), parsing of SFP module EEPROM is done by phylink_sfp_module_insert() in phylink.c and the supporting sfp_parse_*() functions in sfp-bus.c. The code covers Fibre Channel modules.

To find out what is going wrong, you may want to correlate that code with your kernel messages and/or the output of ethtool -m eth2. The structure of the EEPROM is declared in include/linux/sfp.h.

24

there was any news ? i have some cisco and juniper sx sfp , and i will give it a try!!
in the future this support will become part of the standard tree??