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.
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??
No news, I am just regularly re-basing the branch against master, and it is working fine for me.
Upon request, I had submitted the LED support to openwrt-devel, but it was rejected. I guess the same would happen to the SFP support.
A clean solution with support for hot plugging would be a modification of the phylink subsystem (see this linux-netdev thread). At the moment, I don't have time for this.
Did you try submitting the SFP support?
No, so far not.
In case anybody is interested, I force-pushed a slightly improved version. No need for omnia-select-device-tree anymore. Instead, the u-boot environment is modified to probe for SFP module presence at boot time, and to choose the appropriate device tree.
Just be aware, only the new sysupgrade will set the new environment. So, you may have to sysupgrade twice, or run the new fw_setenv command (from /lib/upgrade/sdcard.sh) manually.
Finally, I have included Russell King's SFP patches, which are waiting for review in patchwork. They seem to work for me.
Any one got kernel crash on turris omnia with latest snapshot?
[12612.523821] irq 51: nobody cared (try booting with the "irqpoll" option)
[12612.530543] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.88 #0
[12612.536562] Hardware name: Marvell Armada 380/385 (Device Tree)
[12612.542509] [<c010f5e8>] (unwind_backtrace) from [<c010aee8>] (show_stack+0x10/0x14)
[12612.550273] [<c010aee8>] (show_stack) from [<c06d3adc>] (dump_stack+0x90/0xa4)
[12612.557516] [<c06d3adc>] (dump_stack) from [<c01704c4>] (__report_bad_irq+0x3c/0xc0)
[12612.565278] [<c01704c4>] (__report_bad_irq) from [<c01703f0>] (note_interrupt+0x238/0x2a8)
[12612.573562] [<c01703f0>] (note_interrupt) from [<c016d928>] (handle_irq_event_percpu+0x4c/0x58)
[12612.582281] [<c016d928>] (handle_irq_event_percpu) from [<c016d978>] (handle_irq_event+0x44/0x68)
[12612.591175] [<c016d978>] (handle_irq_event) from [<c0170e0c>] (handle_level_irq+0x10c/0x154)
[12612.599633] [<c0170e0c>] (handle_level_irq) from [<c016cb40>] (generic_handle_irq+0x24/0x34)
[12612.608095] [<c016cb40>] (generic_handle_irq) from [<c04081c0>] (mvebu_gpio_irq_handler+0x114/0x144)
[12612.617249] [<c04081c0>] (mvebu_gpio_irq_handler) from [<c016cb40>] (generic_handle_irq+0x24/0x34)
[12612.626229] [<c016cb40>] (generic_handle_irq) from [<c016d164>] (__handle_domain_irq+0x98/0xac)
[12612.634952] [<c016d164>] (__handle_domain_irq) from [<c03f5d7c>] (gic_handle_irq+0x5c/0x90)
[12612.643325] [<c03f5d7c>] (gic_handle_irq) from [<c0101a0c>] (__irq_svc+0x6c/0x90)
[12612.650823] Exception stack(0xc0a01f30 to 0xc0a01f78)
[12612.655886] 1f20: 00000000 1855b4d8 eedd6344 c0118160
[12612.664083] 1f40: c0a00000 c0a03cb4 00000000 c0a03cf4 c0947768 00000000 00000000 c0a01f88
[12612.672279] 1f60: c0a0fb00 c0a01f80 c01082f8 c01082fc 60000013 ffffffff
[12612.678913] [<c0101a0c>] (__irq_svc) from [<c01082fc>] (arch_cpu_idle+0x34/0x38)
[12612.686327] [<c01082fc>] (arch_cpu_idle) from [<c0152120>] (do_idle+0xdc/0x1b8)
[12612.693654] [<c0152120>] (do_idle) from [<c0152458>] (cpu_startup_entry+0x18/0x20)
[12612.701242] [<c0152458>] (cpu_startup_entry) from [<c0900df4>] (start_kernel+0x4f0/0x500)
[12612.709440] handlers:
[12612.711718] [<ef31836d>] irq_default_primary_handler threaded [<52d404a9>] pca953x_irq_handler
[12612.720353] Disabling IRQ #51
From fdt-utils utilised fdtdump to get contents for:
================================================================================
File 1: "ftdump_sfp_dtb.txt"
File 2: "ftdump_sfp_dtb.txt"
================================================================================
Lines modified at 3
================================================================================
- // totalsize: 0x46cb (18123)
+ // totalsize: 0x46ef (18159)
================================================================================
Lines modified at 5
================================================================================
- // off_dt_strings: 0x42a4
+ // off_dt_strings: 0x42c0
================================================================================
Lines modified at 10
================================================================================
- // size_dt_strings: 0x427
+ // size_dt_strings: 0x42f
- // size_dt_struct: 0x426c
+ // size_dt_struct: 0x4288
================================================================================
Lines modified at 516
================================================================================
- phy = <0x0000000e>;
+ managed = "in-band-status";
================================================================================
Lines added at 517
================================================================================
+ sfp = <0x0000000e>;
================================================================================
Lines modified at 569
================================================================================
- status = "okay";
+ status = "disabled";
================================================================================
Lines deleted at 572
================================================================================
- phandle = <0x0000000e>;
================================================================================
Lines modified at 881
================================================================================
- status = "disabled";
+ status = "okay";
================================================================================
Lines added at 888
================================================================================
+ phandle = <0x0000000e>;
Wondering whether fdtput could perhaps be leveraged to manipulate the active device tree and thus change from the cli between SFP and PHY?
Usage: write a property value to a device tree
fdtput <options> <dt file> <node> <property> [<value>...]
fdtput -c <options> <dt file> [<node>...]
fdtput -r <options> <dt file> [<node>...]
fdtput -d <options> <dt file> <node> [<property>...]
The command line arguments are joined together into a single value.
<type> s=string, i=int, u=unsigned, x=hex
Optional modifier prefix:
hh or b=byte, h=2 byte, l=4 byte (default)
Options: -[crdpt:vhV]
-c, --create Create nodes if they don't already exist
-r, --remove Delete nodes (and any subnodes) if they already exist
-d, --delete Delete properties if they already exist
-p, --auto-path Automatically create nodes as needed for the node path
-t, --type <arg> Type of data
-v, --verbose Display each value decoded from command line
-h, --help Print this help and exit
-V, --version Print version and exit
I would never try to change the device tree on the running kernel. But, indeed, one generic dtb, modified in RAM by some magic using U-Boot fdt commands, that might work.
Hi kkudielka,
Thanks for all your works, but my turris omnia always got kernel crash...
[ 8415.566424] irq 76: nobody cared (try booting with the "irqpoll" option)
[ 8415.573149] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.19.98 #0
[ 8415.579168] Hardware name: Marvell Armada 380/385 (Device Tree)
[ 8415.585112] [<c010f588>] (unwind_backtrace) from [<c010ae8c>] (show_stack+0x10/0x14)
[ 8415.592879] [<c010ae8c>] (show_stack) from [<c06cd8bc>] (dump_stack+0x90/0xa4)
[ 8415.600123] [<c06cd8bc>] (dump_stack) from [<c01700cc>] (__report_bad_irq+0x3c/0xc0)
[ 8415.607885] [<c01700cc>] (__report_bad_irq) from [<c016fff8>] (note_interrupt+0x238/0x2a8)
[ 8415.616170] [<c016fff8>] (note_interrupt) from [<c016d530>] (handle_irq_event_percpu+0x4c/0x58)
[ 8415.624890] [<c016d530>] (handle_irq_event_percpu) from [<c016d580>] (handle_irq_event+0x44/0x68)
[ 8415.633783] [<c016d580>] (handle_irq_event) from [<c0170a14>] (handle_level_irq+0x10c/0x154)
[ 8415.642241] [<c0170a14>] (handle_level_irq) from [<c016c748>] (generic_handle_irq+0x24/0x34)
[ 8415.650703] [<c016c748>] (generic_handle_irq) from [<c0407d60>] (mvebu_gpio_irq_handler+0x114/0x144)
[ 8415.659858] [<c0407d60>] (mvebu_gpio_irq_handler) from [<c016c748>] (generic_handle_irq+0x24/0x34)
[ 8415.668838] [<c016c748>] (generic_handle_irq) from [<c016cd6c>] (__handle_domain_irq+0x98/0xac)
[ 8415.677561] [<c016cd6c>] (__handle_domain_irq) from [<c03f594c>] (gic_handle_irq+0x5c/0x90)
[ 8415.685933] [<c03f594c>] (gic_handle_irq) from [<c0101a0c>] (__irq_svc+0x6c/0x90)
[ 8415.693432] Exception stack(0xc0a01f30 to 0xc0a01f78)
[ 8415.698495] 1f20: 00000000 104d5e9c eedd6344 c0118100
[ 8415.706691] 1f40: c0a00000 c0a03cb4 00000000 c0a03cf4 c0946768 00000000 00000000 c0a01f88
[ 8415.714888] 1f60: c0a0fac0 c0a01f80 c01082f8 c01082fc 60000013 ffffffff
[ 8415.721522] [<c0101a0c>] (__irq_svc) from [<c01082fc>] (arch_cpu_idle+0x34/0x38)
[ 8415.728937] [<c01082fc>] (arch_cpu_idle) from [<c0151f54>] (do_idle+0xdc/0x1b8)
[ 8415.736263] [<c0151f54>] (do_idle) from [<c015228c>] (cpu_startup_entry+0x18/0x1c)
[ 8415.743855] [<c015228c>] (cpu_startup_entry) from [<c0900df8>] (start_kernel+0x4f4/0x504)
[ 8415.752053] handlers:
[ 8415.754331] [<ae7c3303>] irq_default_primary_handler threaded [<d8ad48ae>] pca953x_irq_handler
[ 8415.762965] Disabling IRQ #76
Any idea about this? Thanks.
I have never seen such a thing on my system. Are you sure this goes away, if you boot without SFP module?
Now that you are asking me for ideas.... On my system:
[0]# cat /proc/interrupts
....
76: 0 0 f1018140.gpio 14 Level 8-0071
77: 0 0 pca953x 4 Edge sfp
78: 0 0 pca953x 3 Edge sfp
79: 0 0 pca953x 0 Edge sfp
....
To me IRQ #76 very much looks like an unhandled interrupt due to one of the PCA9538 input pins changing, see Turris Omnia schematic. One candidate would be pin 7, coming from the PHY connected to the WAN port.
Anyway, I never seem to get an interrupt on these (current uptime 7 days).
Hello there.
The wiki page advised me to check this forum post.
I am looking into installing vanilla OpenWrt on my Turris, but the eth1 issue is the one deal breaker.
eth1 switch configuration is currently not supported in OpenWrt, only port 5 is the uplink to the switch.
Is this still the case on OpenWrt's trunk?
As the title of this thread says, it is concerned with support for the SFP cage.
Anyway, as far as I know, DSA support for multiple CPU ports is neither in mainline kernel, nor in OpenWrt.
what does this mean?
Turris Omnia uses DSA for its switch. 5 of the ports belong to 2 CPU ports(only 1 is used). The WAN port/SFP is connected to a third.
The Linksys WRT series do not use DSA for this reason.
hello
im got a turris omnia and several GPon SFP modules but only one module works with turris (DFP-34G-2C2)
the other modules that i have that doesnt work are (MA5671A oem and other unlocked with HL23446 firmware) Carlitosxxpro CPGOS03-490-v2 (realtek chipset) G-010s-a g-010s-b and zisa op151s
How i can debug or something to view what its the issue? Ma5671A unlocked modded its working on a neutral Switch without issues but in turris omnia doesnt work
kernel | sys log should show some related SFP info, but its verbosity may depend on the kernel (debug) config flags, particularly related to driver debugging.
tool for getting module info ethtool -m eth2
tool for dumping the module's eprom content ethtool -m eth2 raw on | hexdump -C
common causes with SFP module issues