I'd like to get some help from you guys, I'm trying to add support for DSA on my router Archer C7, I've been modifying the device DTS file and I'm getting nowhere since the changes I make so far get me these errors in the kernel log:
[ 0.499018] libphy: Fixed MDIO Bus: probed
[ 1.190109] libphy: ag71xx_mdio: probed
[ 1.197041] switch0: Atheros AR8337 rev. 2 switch registered on mdio-bus.0
[ 1.204213] Atheros AR8216/AR8236/AR8316: probe of mdio-bus.0:00 failed with error -22
[ 1.215299] ar8327: qca,phy-rgmii-en is not specified
[ 1.222046] ar8327: qca,phy-rgmii-en is not specified
[ 1.227744] ag71xx 19000000.eth: Could not find valid phy node
I know some stuff, but this is garbage to me since it's device tree coding and I've never done that before.
Can someone help me?
I've been using a branch in my github to make those changes, this is the link to the file:
If I can make it and maybe Openwrt believes it's usefull it can be merged in trunk as DSA is super usefull, simpler to deploy and simpler to understand.
But there are some issues, when linux detects eth0 it doesn't detect the switch and vice versa, any help from developers? @blogic I've read that you made transition for IPQ8xxx devices, could you help me?
Wow, that's quite a feat! Based on your work I decided to try with my WDR4300 and Archer C7v2. The latter has two CPU ports - I think I might need to backport some patches to support multiple CPU ports through DSA, but even without that, the setup should work at single CPU port.
I really, really wonder, why there was so little interest for conversion of existing ath79 devices to DSA so far.
I believe that that's an issue that's easy to solve... the patches going around allow the user to select which ports are bound to a port, but that doesn't seem like a proper solution because the bandwidth might be wasted, instead the ports should be bound together in a low level link aggregation in a round-robin fashion, and then that link aggregation interface should be used as the CPU port. Unfortunately, I do not have the knowledge in coding to perform this...
It will work perfectly, from my experience it works great, the only thing that would make it better would be qca8k routing offloading like there is in some mediatek targets. I have seen that blogic has made some work with this https://git.openwrt.org/?p=openwrt/staging/blogic.git;a=commit;h=dd3bdac6d1dcd98d4d494052f7df31ca21558d6f but since then the linux kernel has added a proper api to offload stuff with the iptables-offload/nftables-offload modules and his work has unfortunately become obsolete.
I have no idea either, these devices would very much benefit from DSA
I reviewed the upstream driver and got the explanation - the work is going on, but there is still a lot to be done, only beginning to be ready to move ath79 target.
Regarding CPU link aggregation, this makes sense - this way combination of any two ports could sustain full-duplex gigabit traffic through CPU port, at least in theory, not just WAN<->LAN. I haven't had a chance to dig in this deep, though, and I don't know if QCA8337 et al, support this.
Anyway, I tried building an image for WDR4300 as a test, and it crashed - I haven't had time to debug this, yet. I have one question as well: how did you derive MDIO address for the switch? Is it always 16? This doesn't correspond to previous entries in device tree. It'd be nice if you could take a quick look at my patches here: https://github.com/Leo-PL/openwrt/commits/ath79-dsa - I imported your patch and split the kernel configuration part and device-specific part as well.
A friend of mine, with quite substantial background on DSA and WDR4300 on hand, told me he's willing to do some work on this, first to get DSA running, and then on the offloading part.
I took another attempt on building an image for my WDR4300 and C7v2, but still wonder form where did the MDIO address 16 came from, other than copying stuff from @blogic's tree.
Could you please post a boot log from your unit running DSA? Would definitely help me map the connections for my devices.
So I am now using your ath79-dsa branch. Boots just find on my Archer C7 v4. Lan-Lan normal speed 940-ish mbps. Lan-Wan not great: around 330-ish. Clearly HW-Nat is not enabled and I couldn't find any patches that suggest that it was added. Software and Hardware offload both ticked.
Another observation (not related to DSA): I can't use wlan0 (5ghz) in client-mode any more. This was working before and is still working on my Zyxel NB6817 which seems to use the same driver.
[ 62.388256] wlan0: authenticate with d4:5f:25:eb:ce:5a
[ 62.398528] wlan0: send auth to d4:5f:25:eb:ce:5a (try 1/3)
[ 62.405381] wlan0: authenticated
[ 62.411423] wlan0: associate with d4:5f:25:eb:ce:5a (try 1/3)
[ 62.418551] wlan0: RX AssocResp from d4:5f:25:eb:ce:5a (capab=0x831 status=0 aid=2)
[ 62.427724] ath10k_pci 0000:00:00.0: pdev param 0 not supported by firmware
[ 62.435029] ath10k_pci 0000:00:00.0: failed to enable peer stats info: -122
[ 62.442267] wlan0: associated
[ 68.618606] wlan0: deauthenticated from d4:5f:25:eb:ce:5a (Reason: 15=4WAY_HANDSHAKE_TIMEOUT)
[ 68.641529] ath10k_pci 0000:00:00.0: mac flush null vif, drop 0 queues 0xffff
[ 91.465445] wlan0: authenticate with d4:5f:25:eb:ce:5a
[ 91.475772] wlan0: send auth to d4:5f:25:eb:ce:5a (try 1/3)
[ 91.482285] wlan0: authenticated
[ 91.491460] wlan0: associate with d4:5f:25:eb:ce:5a (try 1/3)
[ 91.498526] wlan0: RX AssocResp from d4:5f:25:eb:ce:5a (capab=0x831 status=0 aid=2)
[ 91.507643] ath10k_pci 0000:00:00.0: pdev param 0 not supported by firmware
[ 91.514948] ath10k_pci 0000:00:00.0: failed to enable peer stats info: -122
[ 91.522418] wlan0: associated
[ 97.698239] wlan0: deauthenticated from d4:5f:25:eb:ce:5a (Reason: 15=4WAY_HANDSHAKE_TIMEOUT)
Speaking of the NB6817: is the wiki correct that is has the AR8337 switch without "N" for hardware NAT, but is using the same DSA driver? LAN-WAN speeds on that device is higher (better CPU). (using Ansuel git ipq806x-dsa branch)
multiple people have reported speed problems with routing. iperf performance is higher than with the swconfig driver. I have no idea if that's only for qca8337. I only have qca8327 units.
HWNAT is not implemented yet.
I believe the ipq stuff doesn't have the N variant. The ipq stuff uses a separate networking processor that doesn't have an upstream driver.