It seems that the QCA9984 chipset with the closed source firmware is already doing the encryption/decryption of WiFi packets on-chip. The NSS crypto capability doesn't look like it's being used for anything for the factory firmware. Once I get the NSS cores stable enough for routing tasks, I'll probably look into the crypto functions.
It is indeed - if you ssh into the "stock" firmware (actually Voxel's recompile) there are four wifi devices ... wifi0, wifi1, ath0 and ath1
I also get my full broadband line speed of 384Mbps over 5Ghz, versus around 220-230Mbps with OpenWRT so for faster connections the offloading of wifi is arguably more important than NAT offloading.
Poking around it also offloads the qdisc for QoS so SQM could get a huge boost in throughput on NSS enabled devices.
no news, bad news
Still working on it , although progress is slow, as I've now used the R7800 as my main router. Still trying to make it stable enough for production use.
The R7800 should be able to do 400-500mbps using a 2x2 WiFi client over 5GHz, at least that's what I got when I tested it some time back. With a 3x3 client, it should get to around 600-700mbps that probably maxed out the Krait CPU. So with the NSS cores off-loading the routing all the CPU cycles can be devoted to WiFi traffic.
We're one step close to getting the ipq806x NSS cores & drivers work. I think I've isolated the cause of the random reboots that my R7800 is experiencing when the NSS cores are enabled to process network packets. My R7800 is now up for more than 38 hours without any reboots. It is now acting as my main Internet router, running with the NSS cores accelerating routing tasks.
It turns out that the NSS firmware/core has issue with the NSS cores' frequency scaling. The NSS firmware probably crashed when the NSS core driver tries to scale the CPU frequency up or down and this causes the R7800 to reboot. Doesn't happen all the time. I still haven't figure out how to reliably trigger this bug.
The good news is that this issue can be worked around at the moment, which is what I did. I just simply disable the frequency scaling of the driver and force the CPU frequency to a fix one, either 110, 600 or 800 MHz for ipq8065. This can be done via procfs which the NSS driver exposes.
I'll have to study the NSS driver codes in greater details to understand and hopefully fix this 'bug'.
If there's anyone who owns a R7800 interested to try out, I'll upload a new build for testing, or you can build a firmware image yourself from my GitHub repo.
My builds are currently based on the lede-17.01 branch. From the patches required, it looks like it may not be difficult to change it to add support for the 4.19 kernel, which the lastest master is based on.
Also, folks with other ipq806x routers who would like to try it out can based it on my GitHub source tree here:
Would love to see it work on other ipq806x routers as well.
That's good news! Maybe @dissent1 can give some pointers?
well i just wanted to thank you for the amazing work
i admit i have not understood what the status is with reference to the whole nss driver package (crypto? just because i remember you have been talking about this for so long :)), but i'm happy also to see this quoted part. As far as i can remember, @Ansuel was not that confident on taking the nss drivers to work on newer kernels..
I have a working build environment (i use it to build hnyman's builds by myself..) but i don't know how to build yours, so when you upload your image let us know, if i'll find time to test it i'll do with pleasure!
thanks a lot lot lot, this can really be a revolution for IPQ806x routers..
well we have the source so... difficult but not impossibile
@pattagghiu I've uploaded my R7800 firmware build with the NSS drivers here:
If you don't mind, could you help test two scenario?
Run the firmware as it is. I would like to know if your R7800 would also randomly reboot. Just to be sure that my router is not defective, as it is a refurbished unit.
Run the firmware with the following startup script:
echo 800000000 > /proc/sys/dev/nss/clock/current_freq
The above command will force the NSS core clock to max frequency and disable frequency auto scaling. From what I've gathered so far, it looks like it is the frequency scaling that likely crashed the NSS firmware causing a spontaneous reboot.
The firmware seems to be performing good. I did a quick DSLReport.com test earlier, on my 500/100 mbps Internet service and managed to get all As from the test, and that's with 32/32 down/up streams during the test.
I'll be keeping the R7800 as my main Internet router at the moment, as it seems stable serving LAN and WiFi clients doing general surfing, video streaming, radio streaming, VOIP, VPN on router, etc. So it looks promising so far.
Hopefully it is stable for you as well.
How often should it happen?
can i see the reboots from system logs? (how? :))
I'm rarely at home, but i can simulate the kind of traffic needed with one of my raspberries to see if during day something happens..
Could you please list the packages contained in the build?
My build is quite customized, so even if i'll find the time to test, i'll have to do it only by little times
I assume the second scenario will have to be tested only if the first fails..
Edit: sorry, could you please confirm if the image has the software partition standard or large, like hnyman's builds? in the first case i fear i should also go back to tftp, which is annoying
Unfortunately I also do not know what triggered it. Sometimes it's fast, sometimes after a few hours. No logs, no exceptions ... even when I have the router connected via the serial port, monitoring the console.
You can refer to the config.seed file on the packages installed. If the packages you installed are non-kernel modules, you can install them again via the router management page.
If the first scenario is stable for you, then it means my router is broken, then no need to test Scenario 2.
My firmware has the the large UBI partition compiled. I.e. you will see 79MB of free space for software installation.
well my router is now up from 51 days, so i can just check the uptime lol
btw, let me try to clone the repository and understand how to build it (but i fear not all of my packages are working on 17.1, for example luci on nginx ssl?)
as far as i have understood, i should:
- clone the repository
- ./scripts/feeds update -a
- ./scripts/feeds install -a
- make menuconfig (i assume i can't use the config file of my actual image..)
right? let's see
Edit to add: is it right in make menuconfig i still have to select the target and the system? isn't there a default config? thanks
i built a seemingly working firmware from 67a02e0f89c56d7871bac096fff24a2ed9d40a8b but had reboots ~every 5mins constant from a non-refurb unit(~1.5 - 2 years use)
I could try yours later tonight, I may not have built everything, I just searched though menuconfig.
@pattagghiu you need to choose the NSS drivers or it won't work at all, as my repository will not load the stmmac gmac driver. Use the steps below to build a firmware on your own environment:
- clone the repository 'https://github.com/quarkysg/openwrt.git'
- switch to the 'lede-1701-ipq806x-nss' branch
- update additional feeds: './scripts/feeds update -a'
- install additional feeds: './scripts/feeds install -a'
- copy the 'config.seed' file in my Box upload to your cloned repo at (1.) and name it '.config'.
- run 'make menuconfig' and choose additional packages that you need
- finally, run 'make package=R7800 -j4' to make firmware just for the R7800. The '-j4' switch is to enable 4 compile threads to make the build complete faster. Increase or decrease according to your environment, based on the number of CPU cores you have in your build machine.
After a while, you should have the image built in:
@ratking you should pull additional commits I made since 'https://github.com/quarkysg/openwrt/commit/67a02e0f89c56d7871bac096fff24a2ed9d40a8b' as you will get the qca-nss-clients driver and minor fixes as well. Just update to HEAD of my GitHub repo.
Since you also encounter the random reboots, you will need the command below as a workaround to make your R7800 stable:
echo 800000000 > /proc/sys/dev/nss/clock/current_freq
Do try it out and see if that solves your reboot problem.
Damn, missed those
All, I am happy to test a build but I am not able to build myself.
@Videopac give a look here
ok my build failed with a not-so-clear message
include/toplevel.mk:205: reciipe for target 'world' failed make: *** [world] Error 1
Your clues will be (potentially quite a bit-) above this final exit statement.