Yes, I believe so... Although, I'll admit I might have been using a mix of the drivers I found from the BR500 repo. I updated yours to use GCC 6.3.0 and a later binutils. I'll rebase, clean and try again.
I think the binaries are closed source for the drivers, but the qca-wifi kernel hooks (sorry, not sure what you'd call it) are open source. I'm basing this on what I found for the BR500 which seems to be very similar to R7800
@qosmio if you trust what I’ve compiled do try what I’ve uploaded into my Box account. If you have access to your R7800 serial console, you can use the initramfs image to test and see if the random reboots still occurs. That way you don’t need to flash the image into your router’s flash memory.
Looks like I needed to manually purge the qca-nss-drv folders out of staging and build. Did a target/linux/clean as well and so, been up for 2 hours! Everything's running pretty smoothly. And I can hit like speeds of 968mbps on my fiber. Great work!
Would be awesome if you were able to get the qca-wifi drivers working. I can finally bring this router back into commission!
Will keep testing this overnight with some heavy dl/ul tests.
I had done that originally, but I think I may have flashed an older image I compiled. I rebuilt everything last night and it's been up since then. However, I'm having some trouble with my WiFi. I'm getting a lot of failed TX errors and my connection seems to just drop. Ethernet seems to be fine though.
This is what I'm noticing in the logs.
[Fri Feb 22 16:37:04 2019] wlan0: NSS TX failed with error: Unknown NSS TX status
[Fri Feb 22 16:41:25 2019] wlan0: NSS TX failed with error: Unknown NSS TX status
[Fri Feb 22 16:41:25 2019] wlan0: NSS TX failed with error: Unknown NSS TX status
[Fri Feb 22 16:42:17 2019] wlan0: NSS TX failed with error: Unknown NSS TX status
[Fri Feb 22 16:42:17 2019] wlan0: NSS TX failed with error: Unknown NSS TX status
[Fri Feb 22 16:43:41 2019] wlan0: NSS TX failed with error: Unknown NSS TX status
My R7800 shows the same thing in the bootlog . Odd that yours exhibit problems. My iPad seems stable connecting to both the 2G and 5G interfaces.
I’m now trying to compile the wlan-open mac80211 and ath10k drivers from the QSDK repository. Let’s see if that drivers combination solves your issue and hopefully improves the WiFi performance.
Wow, you guys have done an awesome work here!
What is current status for PPPoE/IPsec/etc offloading? Do we know firmware API to control offloading?
Could drivers from QSDK be ported to trunk in terms of license etc?
PPPoE & IPSec offloading is supported by the QCA NSS drivers. My ISP uses PPPoE over 802.1Q, so I can confirm that it's working. Whether it is accelerated I can't really tell tho.
As for IPSec, my builds currently do not have all the necessary drivers to offload IPSec. I'll probably get to it later.
At the moment, I'm trying to figure out how to improve WiFi performance with the ath10k drivers. Not making much headway tho.
As for licensing, the source codes are released using GPL2 license if I'm not wrong, so it can be used freely. The closed source NSS firmware tho, I'm not sure. Getting the drivers accepted into mainline source tree tho, will be difficult IMHO.
From a purely technical point of view, it might be possible to refactor the code to hook into the hardware-flowoffloading infrastructure, this would probably be the 'easiest' approach for mainline acceptance (the work needed to actually accomplish this however would be far from easy).
Have been reading up on the mac80211 and ath10k sources and also learning on the Linux network stack architecture. From what I've learnt so far, to accelerate WiFi performance using the NSS firmware, we need to push both RX/TX transmit to push/pull the network packets to the NSS firmware via the NSS drivers.
From what I've seen so far with the patches I've applied to the mac80211 driver, only outgoing WiFi traffic passes through the NSS firmware. Incoming WiFi traffic via the RX path in the mac80211 driver bypasses the NSS firmware, because the ath10k driver made use of the NAPI framework, which also implement GRO. Using NAPI forces incoming WiFi traffic to go via the slow-path. From what I understand, for the NSS ECM driver to accelerate network traffic, both RX/TX traffic have to go thru the NSS firmware.
The ath10k driver from the QSDK repository doesn't make use of NAPI, but I have problem compiling it successfully for LEDE-17.01. So kind of stuck again.
Anyone here has deep understanding of the ath10k and mac80211 code who could provide me on some pointers? Would it be possible to disable NAPI easily for the current ath10k driver?
Happy to report minor progress on the WiFi interface front in terms of performance. I managed to improve the WiFi performance somewhat, with reduced CPU utilisation. Turns out I was using the wrong NSS driver API all along. I've checked in the changes in my GitHub repository.
Do try to compile your own firmware and report back if you do see improved WiFi performance.
My builds still taxes the Krait CPU when WiFi traffic is being processed. I'm guessing that it's due to the encryption/decryption tasks performed processing the WiFi traffic.