Ipq806x NSS build (Netgear R7800 / TP-Link C2600 / Linksys EA8500)

lenovomi · 2021-12-14T23:18:10.634Z

thank you for the explanation, yes the ath10k vs ath10k-ct comparison would be appreciate.

lenovomi · 2021-12-14T23:18:37.650Z

this is for netgrear / tplin/ linksys right? what zyxel device are you mentioning?

salim-b · 2021-12-14T23:23:07.956Z

This one which has the same SoC as the Netgear R7800:

OpenWrt Wiki – 21 Dec 17

ZyXEL NBG6817

ZyXEL NBG6817 Also known as ZyXEL Armor Z2 AC2600. The hardware is very similar to the ZyXEL NBG6816 (Armor Z1), but uses an all QCA IPQ8065 design (SOC and QCA9984 wlan) instead, like the Netgear Nighthawk x4s (r7800) and the Synology rt2600ac. ...

SiXX · 2021-12-14T23:32:21.870Z

lenovomi:

this is for netgrear / tplin/ linksys right? what zyxel device are you mentioning?

NBG6817

Essentially the same as the R7800. Wonderful device!

ACwifidude · 2021-12-15T03:30:48.295Z

The builds with the “ath10k” in the name are running mainline firmware and drivers. The builds with no additional description are running the OpenWRT default ath10k-ct firmware and drivers.

I am currently running the ath10k-ct master build on my three r7800s since I posted the build 2 days ago. I have 1 strictly as the wired router and 2 running as wireless access points. I find my clients like ath10k-ct and the performance is good (see below iperf testing with an iPhone 2x2 client + OpenWrt with 5 different variations of builds - testing done 3 months ago).

OpenWrt SNAPSHOT, r18312+30-3b20eb185b
 -----------------------------------------------------
root@OpenWrt:~# uname -a
Linux OpenWrt 5.10.82 #0 SMP Sun Dec 12 01:17:15 2021 armv7l GNU/Linux
root@OpenWrt:~# uptime
 21:08:17 up 2 days,  6:24,  load average: 0.00, 0.00, 0.00

ath10k-ct with NSS
[SUM]   0.00-30.01  sec  1.61 GBytes   462 Mbits/sec                  receiver
[SUM]   0.00-30.03  sec  1.85 GBytes   530 Mbits/sec  126             sender

ath10k with encap offloading and NSS:
[SUM]   0.00-30.01  sec  1.65 GBytes   473 Mbits/sec                  receiver
[SUM]   0.00-30.01  sec  1.81 GBytes   517 Mbits/sec  784             sender

ath10k with encap offloading:
[SUM]   0.00-30.01  sec  1.63 GBytes   468 Mbits/sec                  receiver
[SUM]   0.00-30.01  sec  1.50 GBytes   428 Mbits/sec  1717             sender

ath10k
[SUM]   0.00-30.01  sec  1.60 GBytes   459 Mbits/sec                  receiver
[SUM]   0.00-30.01  sec  1.14 GBytes   326 Mbits/sec  699             sender

ath10k-ct
[SUM]   0.00-30.01  sec  1.53 GBytes   437 Mbits/sec                  receiver
[SUM]   0.00-30.01  sec  1.21 GBytes   347 Mbits/sec  763             sender

GloooM · 2021-12-15T16:52:14.133Z

After some trial and error, I seems to be finally find solution. I've created this PR https://github.com/ACwifidude/openwrt/pull/5

Based on this message IPQ806x NSS Drivers - #1795 by Ansuel I was tried to flip phy-mdio-addr in qcom-ipq8064-eax500.dtsi and set 4 for gmac2 and 0 for gmac1 and eventually I've got working configuration.
Then I've move this values to qcom-ipq8064-ea7500-v1.dts but it is fails again.
Seems to be dts in ea7500-v1 doesn't override eax500 parameters, so I've moved gmacs configs to ea8500.dts and my modified to ea7500-v1.dts

Now I can achieve 900+mbit/s through ethernet with NAT. Need to watch several days for check stability.

ACwifidude · 2021-12-15T20:07:11.424Z

Sounds good. Keep me posted. If it works well on your testing I’ll add it in to the next build (next 1-2 weeks, I want to see how the 5.10 build does for a little longer to assess stability)

GloooM · 2021-12-15T21:07:32.980Z

I have another question about nss-ifb. Is it possible to work per vlan on single interface?
I've tried

printf eth1.2 > /sys/module/nss_ifb/parameters/nss_dev_name

but it doesn't work.
My EA7500 seems to be has hardware fault, and when I upload more 50mbit through eth0 it hangs during seconds.
I've configured switch to forward both vlans through eth1, and it is work perfectly, except nss-ifb, which limit speed in both direction simultaneously.

I've tried using standard sqm without nss offloading, but it seems to be doesn't work with nss interfaces.

RadioOperator · 2021-12-16T20:21:09.297Z

Hi, I tried your PR on my ea8500. wan/wifi ok, but eth0 not, my PC(dhcp) Lan cannot get a IP address.
But in kernel initial log:

[   65.616300] ipq8064-mdio 37000000.mdio eth0: 1000 Mbps Full Duplex
[   66.723380] device eth0 entered promiscuous mode
[   66.727430] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Any suggesttions for my problem, thanks.

sppmaster · 2021-12-16T21:04:26.243Z

With latest master build I have lots of these rows in syslog

kern.warn kernel: [190278.650860] br-lan: received packet on wlan1 with own address as source address (addr:MAC address here, vlan:0)

GloooM · 2021-12-16T21:04:44.439Z

But images from @ACwifidude works fine?

If you have same problem as me, then you can try set

qcom,phy-mdio-addr = <4>;

in gmac2 config in .dts file for 8500

ACwifidude · 2021-12-16T22:51:12.806Z

NSS hardware offloading bypasses some of the common features in OpenWrt (/Linux). Several things are hard coded to allow this handover to bypass several CPU intensive intensive steps in the routing process. This is why main CPU usage is so low - once it is initially recognized these packets are eligible to be hardware offloaded - these packets can bypass through the alternative dedicated pathway that the NSS processors / firmware provide.

Looks like you’ve run in to a feature that is hard coded for certain interfaces. NSS fq codel doesn’t talk with normal OpenWrt SQM. Best guess, It’ll probably take a big overhaul of the NSS patches to get your specific configuration to work.

RadioOperator · 2021-12-17T04:30:17.391Z

After mod qcom,phy-mdio-addr = <4>; , the LAN port really works OK! Thanks.
This is first time NSS build worked on my ea8500 ok, I'm testing it now.

I'm using @ACwifidude latest code kernel 5.10 branch, thanks @ACwifidude .

When I tried to flash openwrt on my ea8500 several month before, I noticed these are 2 different versions ea8500 in the market. One is USA version, openwrt ok. The other is Hong Kong version, cannot use openwrt. My ea8500 is HK version, I flashed openwrt official FW ok and not work using any NSS builds, maybe your solution is the root cause related different versions - a little bit hardware variants. If this is sure. maybe we have to work out 2 different versions FWs build for different HWs or make the initial code Auto detect the hardware likes openwrt Official code did(I do not know if it has).

RadioOperator · 2021-12-17T12:40:09.137Z

Hi, @ACwifidude ,
I'm using your code Kernel 5.10 branch, the menu, missing Kernel Log item.
2102 branch has it.

Please tell me if this problem is something wrong on my side, thanks.

ACwifidude · 2021-12-17T13:13:44.915Z

Kernel log is no longer on of the main menu options in luci. System log now has system log and kernel log tabs. Check there and you should see it.

RadioOperator · 2021-12-17T13:16:05.090Z

haha, thanks, got it.

MrHugelberg · 2021-12-17T13:24:06.145Z

Does anyone have problems with nlbwmon counting traffic correctly? Since I'm using your kernel 5.10 build my traffic stats are weird and aren't correct at all anymore and I don't know what i am doing wrong.
Before it worked just fine. Same config.

RadioOperator · 2021-12-17T15:58:27.000Z

Hi, attached. Thanks

(Attachment EA8500-u-boot.orig.zip is missing)

SiXX · 2021-12-17T16:19:13.799Z

MrHugelberg:

Does anyone have problems with nlbwmon counting traffic correctly? Since I'm using your kernel 5.10 build my traffic stats are weird and aren't correct at all anymore and I don't know what i am doing wrong.
Before it worked just fine. Same config.

Yes - has been this way for a while now (even in stable 21.02 builds). I don't use it too often myself, so I haven't bothered to look further into it yet... but from the system logs it appears it runs out of memory and stops tracking as a result.

KONG · 2021-12-17T18:01:08.118Z

In my 21 build I added a fix for it, since I'm using the 21 build without nss on my main router. I can add that fix to the nss build next time I sync.