I force pushed some changes in this version. In blogic's staging tree, he didn't remove swconfig from the kconfig, but he did remove references to the driver that depended on it.
EDIT: My .config looks like this after my changes.
An interesting thing to remember about the build system is that the same kernel is typically used for all boards on a given target. That should give you some insight as to why the kernel module was not removed.
Do you really need to add a patch to enable DSA? I believe that you only need to neutralize the ones that disable it, because upstrem(linux kernel) it is automatically enabled, am I wrong?
Does that mean that you can now build a image?
@jeff @neheb Thanks for your help guys! I got it working just fine with a version 5 of my commit on my WRT1900ACSv2-GB.
Thu Mar 14 03:14:19 2019 kern.notice kernel: [ 1.416863] Registering SWP/SWPB emulation handler
Thu Mar 14 03:14:19 2019 kern.info kernel: [ 1.423145] mv88e6085 f1072004.mdio-mii:00: switch 0x1760 detected: Marvell 88E6176, revision 1
Thu Mar 14 03:14:19 2019 kern.info kernel: [ 1.573544] libphy: mv88e6xxx SMI: probed
Thu Mar 14 03:14:19 2019 kern.info kernel: [ 1.577593] DSA: switch 0 0 parsed
Thu Mar 14 03:14:19 2019 kern.info kernel: [ 1.581010] DSA: tree 0 parsed
Thu Mar 14 03:14:19 2019 kern.info kernel: [ 1.846552] Marvell 88E1540 mv88e6xxx-1:00: attached PHY driver [Marvell 88E1540] (mii_bus:phy_addr=mv88e6xxx-1:00, irq=POLL)
Thu Mar 14 03:14:19 2019 kern.info kernel: [ 1.956551] Marvell 88E1540 mv88e6xxx-1:01: attached PHY driver [Marvell 88E1540] (mii_bus:phy_addr=mv88e6xxx-1:01, irq=POLL)
Thu Mar 14 03:14:19 2019 kern.info kernel: [ 2.064489] Marvell 88E1540 mv88e6xxx-1:02: attached PHY driver [Marvell 88E1540] (mii_bus:phy_addr=mv88e6xxx-1:02, irq=POLL)
Thu Mar 14 03:14:19 2019 kern.info kernel: [ 2.176550] Marvell 88E1540 mv88e6xxx-1:03: attached PHY driver [Marvell 88E1540] (mii_bus:phy_addr=mv88e6xxx-1:03, irq=POLL)
Thu Mar 14 03:14:19 2019 kern.info kernel: [ 2.284489] Marvell 88E1540 mv88e6xxx-1:04: attached PHY driver [Marvell 88E1540] (mii_bus:phy_addr=mv88e6xxx-1:04, irq=POLL)
Side note: The LuCI Switch section disappeared so I guess that won't be a problem anymore. I also had to change the LED trigger from ethX to wan.
Of course I haven't really tested stability yet. I also haven't tested VLAN functionality. Literally just booted.
@tiagogaspar8 Yep I can confirm it works. But you have to flash from factory/don't tick "Keep Settings". I mean I can build an image - but I don't know what packages you want/need so it's probably best if you could build it yourself.
Just use the patch linked below in your openwrt build directory via
patch -p1 -i name-of-patch.patch
It will work with the current master as of 17cb490
https://github.com/jeolives/openwrt/commit/fd66eec5f0be614982ee890a61457d269d9afd24.patch
Also with regards to sending this to openwrt trunk, this will probably get rejected.
You mean "bonding"/"load balancing"? Marvell switches that support DSA management should support bonding as well. Refer to Linksys GPL code or Marvell 88E6095 datasheet for more details.
I've even tried porting the bonding code to OpenWrt master (swconfig VLAN based) but I'm not very clear which registers to wrote.
Marvell Armada 385 SoC also supports HW NAT acceleration, which is advertised as Accelerated Data Path. However there is no source code available yet (only available with NDA?). I wonder if Turris Omnia team will bother porting the feature to upstream flow offload infrastructure.
Shouldn't be an issue here then. I wonder which switches don't do bonding...
Turris Omnia already does line rate. It can potentially help with OpenVPN but I doubt it.
@ParanoidZoid switch section is swconfig. Expected behavior since you removed it.
It will not get rejected if you also write an swconfig to DSA migration script.
Finally had time to run through the dmesg/syslog.
Hmm...facing an issue where the RGMII interface isn't starting up. I'll need to look back on what I did. First step will probably be removing Blogic's patch. But everything is working fine. I mean I was able to setup everything without anything blowing up disastrously.
Side note, would you happen to know what eth0/eth2 does in the dtsi?
If this makes sense:
eth0 in logs = sgmii/eth2 and eth1 in the logs = rgmii-id/eth0
armada-385-linksys.dtsi
...
ð0 {
status = "okay";
phy-mode = "rgmii-id";
buffer-manager = <&bm>;
bm,pool-long = <0>;
bm,pool-short = <1>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
ð2 {
status = "okay";
phy-mode = "sgmii";
buffer-manager = <&bm>;
bm,pool-long = <2>;
bm,pool-short = <3>;
fixed-link {
speed = <1000>;
full-duplex;
...
Hypothetically, if I were to have the time to write a migration script, it would just have to modify interface names in /etc/config/network right? Where would I even place this script so that it only runs once and gets deleted after a sysupgrade? I'm also unable to test VLANs as I don't really have a use case for them in my setup...
That's really nice to hear!
That's the idea, as I've read someone say before, it can be as simple as doing round-robin, the switch/cpu sends packets though one port then through another port and so on, that way we can achieve some kind of simple, non restrictive load balancing, but this need the switch and the cpu to see both ports as one, for example like the linux would see CPU named port, 2gbps capable, but in the background the driver would be doing round robin throgh the real interfaces CPU1 and CPU2. Does that make sense?
That seems very intersting, I'll be looking into it!
If anyone won't do ti I can try to look into it!
Eth0 is supposed to not start, it's disabled as DSA doesn't support more than one cpu port, it's configured, enabled, but it won't transmit data to the switch as the switch doesn't have it set up.
I'll just post the link to the file, you'll understand it as soon as you see it.
https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/armada-385-linksys.dtsi
OK, found this, can we try it ?
The links don't work and we need the "adp-sdk" which you can only get through I presume this link: https://extranet.marvell.com/extranet/dms/documents.do?groupID=4&subGroupID=79213
Which is probably only for customers who have signed a binding NDA & contract to conduct business.
Can you post your output from ethtool -S eth0 (or what ever eth device is used) please?
How many broadcast frames does it show?
Doing a tcpdump gives me the following:
16:31:01.379458 00:01:5c:74:fc:46 (oui Unknown) > Broadcast, ethertype MEDSA (0xdada), length 68:
0x0000: 0000 c020 0000 0806 0001 0800 0604 0001 ................
0x0010: 0001 5c74 fc46 5fde ac01 0000 0000 0000 ..\t.F_.........
0x0020: 5fde afa0 0000 0000 0000 0000 0000 0000 _...............
0x0030: 0000 0000 0000 ......
16:31:01.399856 00:01:5c:74:fc:46 (oui Unknown) > Broadcast, ethertype MEDSA (0xdada), length 68:
0x0000: 0000 c020 0000 0806 0001 0800 0604 0001 ................
0x0010: 0001 5c74 fc46 5fde ac01 0000 0000 0000 ..\t.F_.........
0x0020: 5fde aef8 0000 0000 0000 0000 0000 0000 _...............
0x0030: 0000 0000 0000 ......
16:31:01.399859 00:01:5c:74:fc:46 (oui Unknown) > Broadcast, ethertype MEDSA (0xdada), length 68:
0x0000: 0000 c020 0000 0806 0001 0800 0604 0001 ................
0x0010: 0001 5c74 fc46 5fde ac01 0000 0000 0000 ..\t.F_.........
0x0020: 5fde aef8 0000 0000 0000 0000 0000 0000 _...............
0x0030: 0000 0000 0000 ......
^C
2236 packets captured
2237 packets received by filter
0 packets dropped by kernel
2000 broadcasts in 10 seconds not bad...
When letting it run for longer there are also dropped packets.
Seems like they all belong to DSA and it doesn't affect performance.
I also don't know where the mac address 00:01:5c:74:fc:46 comes from?
1 Like
I don't really know how to interpret this output:
root@WRT1900ACS:~# uptime
21:22:59 up 15 min, load average: 0.56, 0.34, 0.17
root@WRT1900ACS:~# ethtool -S eth0
NIC statistics:
good_octets_received: 216014092
good_frames_received: 244261
bad_octets_received: 0
bad_frames_received: 0
broadcast_frames_received: 94
multicast_frames_received: 1023
unrec_mac_control_received: 0
good_fc_received: 0
bad_fc_received: 0
undersize_received: 0
fragments_received: 0
oversize_received: 0
jabber_received: 0
mac_receive_error: 0
bad_crc_event: 0
collision: 0
late_collision: 0
rx_discard: 1
rx_overrun: 0
frames_64_octets: 454
frames_65_to_127_octets: 267075
frames_128_to_255_octets: 7075
frames_256_to_511_octets: 5028
frames_512_to_1023_octets: 3539
frames_1024_to_max_octets: 247510
good_octets_sent: 175643964
good_frames_sent: 286918
excessive_collision: 0
multicast_frames_sent: 1532
broadcast_frames_sent: 392
fc_sent: 0
internal_mac_transmit_err: 0
eee_wakeup_errors: 0
p05_in_good_octets: 175649036
p05_in_bad_octets: 0
p05_in_unicast: 284994
p05_in_broadcasts: 392
p05_in_multicasts: 1532
p05_in_pause: 0
p05_in_undersize: 0
p05_in_fragments: 0
p05_in_oversize: 0
p05_in_jabber: 0
p05_in_rx_error: 0
p05_in_fcs_error: 0
p05_out_octets: 216042341
p05_out_unicast: 243246
p05_out_broadcasts: 115
p05_out_multicasts: 1059
p05_out_pause: 0
p05_excessive: 0
p05_collisions: 0
p05_deferred: 0
p05_single: 0
p05_multiple: 0
p05_out_fcs_error: 0
p05_late: 0
p05_hist_64bytes: 436
p05_hist_65_127bytes: 203346
p05_hist_128_255bytes: 2723
p05_hist_256_511bytes: 1974
p05_hist_512_1023bytes: 1353
p05_hist_1024_max_bytes: 207706
p05_sw_in_discards: 0
p05_sw_in_filtered: 0
p05_sw_out_filtered: 24774
(I believe one of my family members were torrenting at this time [SQM is also on], hence the CPU usage).
Network topology (ignoring WLAN) is:
ISP GPON Modem <-> WRT1900ACS <-> Tenda PH3 Powerline Adapter (a) <-> Tenda PH3 Powerline Adapter (b) <-> E1200 as a Dummy AP <->Raspberry Pi with Pi-Hole
Do you guys also know whats going on here? Googling didn't end up helping.
[ 84.321793] br-lan: failed (err=-34) to set attribute (id=6)
It appears twice in the kernel log, and only after WLAN0 and WLAN1 enter forwarding state.
I've been searching but I found nothing, have you tried removing and re-adding the bridge?
Figured it out - it was br-lan trying to enable STP on WLAN0 and WLAN1. I don't even know if I really need it anyways.
So I've made a firmware with what I believe is your patch @ParanoidZoid (?) And DSA is working as expected! Without a flaw from what I can see!
Now I'll try to focus on the script to see if I can find a way to enable a smooth transition.
On another topic....
I'd like some help from the experts in Linux. Can't we use kmod-bond to bond eth0 and eth1 into one virtual port and assign it as the CPU port? That way technically the mentioned limitation of DSA and one CPU port allowed. What I think is that DSA may work in a "lower level" then channel bonding? I hope I'm wrong ahahahah
ethtool -S eth0
NIC statistics:
...
broadcast_frames_received: 36582908
...
Compared to your 94 broadcast frames.
I don't know what's going there.
This is on kernel 4.19 and wrt1200.
But everything seems to work normally.
I think you'd need to change something else as well. I was checking up on /etc/config/network and saw that it was still generating switch0 stuff.
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '0 1 2 3 5t'
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '4 6t'
Specifically the lines regarding swconfig...but changing this would change it for every single device that runs OpenWrt...
Apparently it's something related to a 'failsafe'?
At least as I understand it, DSA switches need to be configured using ip commands to set up Linux bridges, not by poking directly into the registers as swconfig does. You should be able to remove the generation of the UCI sections by removing the device from the case statement in base-files/etc/board.d/02_network
I don't know if there has been any work done on a syntax for defining VLANs and port properties in UCI. I did my configuration in a shell script. UCI definitions will likely be a lively discussion when it comes to that point.
1 Like