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.
EDITS:
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!