IPQ806x NSS Drivers


I tried to compile the ecm, but it seems like it may not be straightforward as well. It seems to be based on the 3.x iptables APIs, which probably changed for the 4.x kernels.

I'm still struggling with making the crypto engine work, which have more value to me atm. Trying to figure out how to configure the clocks needed from the Netgear board file source codes. My lack of understanding of the clock APIs for both 3.x and 4.x is proving to be a big handicap ... sigh ...

Would appreciate if anyone can provide useful pointers in porting clock devices between kernel versions.


Or add -std=gnu89 like the kernel does. Or add static.


Isn't ECM needed for everything, or just connection offloading?

Might there be another branch somewhere staged against the 4.x kernels?


That sounds logical. There are a lot of ifdef in the Makefile referencing the 3.14 kernel. So that functions were probably declared in their 3.x header but not in the 4.x. To rule out this i'll apply the flag @neheb is pointing out to see were it takes me.

@philjohn yes, reading the code comments, Makefiles and doc there are a lot of references pointing out that the ecm (enhanced connection manager) is the module processing all the traffic rules and offloading.

So things are going slow but i'll try my best with the time i have for this task.

Thanks for the feedback ans tips!


Still struggling with the ecm. I mamaged to isolate errors and correct them but new ones arise. the ECM has a lot of dependencies, shorcut-fe and fast-classifier among them. Still with the -std=c89 flag is throwing errors. Long road ahead i guess.


Made a little bit more progress on the nss-crypto drivers. Managed to activate all 4 nss-crypto devices but it looks like it's not running right. I'm guess the clocks are not configured properly resulting in the crypto devices not processing. There's a companion benchmark utilities that can be loaded. It seems to start the benchmark test ... but I don't see it completing. So close ...

I've committed the device tree entries in my GitHub repo. If anyone knows where's the mistake, pls do point it out to me.


Hi i've cloned your repo, switched to the qca-nss branch, created a new one qca-nss-ecm and added the ecm code. Let's see if i can progress a little bit in your branch, that compiles shortcut-fe perfectly.


Remember to disable the stmmac GMAC driver and enable the nss-gmac driver. Otherwise the nss-drv will not be able to load.

On a separate note, does anyone knows how to associate the rpm-clk clocks with devices instead of the usual gcc clocks? I need to enable the already defined nss-fabric_0/1_clk clocks to make the NSS cores start running (I think) but it is defined as a rpm-clk instead of a gcc clocks. So the NSS cores is still not running properly. Haiz ....


Search for nss_fabric_0 in http://github.com/SVoxel/R7800 gives this:


2938 DEFINE_CLK_RPM(nssfab0_clk, nssfab0_a_clk, NSS_FABRIC_0, NULL);
2939 DEFINE_CLK_RPM(nssfab1_clk, nssfab1_a_clk, NSS_FABRIC_1, NULL);
2941 static DEFINE_CLK_VOTER(sfab_msmbus_a_clk, &sfab_a_clk.c, 0);

Does that help?

Also, a search for "rpm_clk" gives some results.

Also, be sure to use exact searches, with CAPS when needed. clk_rpm or CLK_RPM don't give any result but DEFINE_CLK_RPM does!


The same RPM clocks are also defined in lede/openwrt’s Linux kernel. It shows up in the debugfs. Problem is I don’t know how to associate it with the NSS devices such that the drivers recognize and can initialize it.


Hi @quarky, can I know how do you crosscheck that the nss-crypto is not performing?


I've been trying to find were the stmmac driver is loaded (which kernel package) but i couldn't find it, at least in the menuconfig options. BTQ i selected the ipq806x and target X4S. Maybe i should change the last one to generic?



The nss-crypto driver source includes a benchmark kernel module which I can invoke to start a benchmark run. I see it starts, but it never complete the run. I think it’s due to the nss_core_fabric clocks not activated correctly.


Use ‘make kernel_menuconfig’ to disable the in kernel drivers.


Hi @quarky!

Two things,

If i clone your github repo and try to build the image, there is an error related to board-2.bin and the hash (it is not valid). I suppose this is related with the recently update from kvalo


if you can update the repo i'll clone it again and start from there.

On the other to avoid this, i'ved clone the openwrt repo and tried to build from there applying the changes from your repo (mainly added the kernel packages) but shortcut-fe is not compiling and it is a dependency of the ECM.

I seems that the struct sk_buff does not have the property fast_forwarded


Since skbuff.h is a header of the kernel included in the sfe_ipv4.c it is not avised to modify it.
Compiling the shortcut-fe module copied from your repo should be straight forward but i'm missing something. Do you have any clue?.

About the nss-crypto, nice work, hoping to see it working soon.


That's odd. I did not change the board-2.bin file. I only changed to a newer version of the ath10k firmware. I'm compiling from the 'lede-17.01-nss-qca' branch without issue.

Did you switch to the nss-qca branch after cloning?

The error with shortcut-fe compile is because you likely only copied the source package. There's also 3 patch files in the target/linux/general/patches-4.4 directory that's needed to patch the standard 4.4 kernel to support shortcut-fe.

I would suggest you re-clone my repo, checkout the lede-17.01-qca-nss branch, configure the package and kernel to remove the stmmac driver, select the nss-gmac & nss-drv package and try 'make PROFILE=R7800' again. My branch should be complete for builds.



Well thanks for your response!. i forgot about the kernel patches :frowning:

yeah i was using the lede-17.01-qca-nss branch and moreover i created a new one lede-17.01-qca-nss-ecm based on the last one to continue the work.

Due to my lack of expertise in the toolchain i'm a "little off" but i'll follow your steps and try to keep up :smiley:


Ok, understood. The best people to ask about this are @blogic and @dissent1, they are/ have been working in-depth on the IPQ806x target. Maybe they can provide some guidance?


@quarky While searching with the terms "qca", "nss" and "ecm", I came across this:
For me it is difficult to judge if it is of interest, or not. Please have a look.


Thanks @bouwew!

Having a look at the repos and sources i can see that the code is similar from the QSDK branchs in the codeaurora repo:


Similar filenames and also code: the diffs are minimal

In the codeaurora repo the commits are newer, two months the newest.