Turris Omnia: Experimental support for SFP cage

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!

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.

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.

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.