IPQ806x NSS Drivers

@KONG @ACwifidude - Looks like something in HEAD or the 5.4.139 kernel broke the build again. I dug in a bit but it's over my head. Do either of you guys have some time to check it out?

Complete build log with error.

You'll need to patch master with the two commits in PR#4221 to get my proposed rebase of kernel 5.4.139.

Section showing error:

make -j1 -C "/scratch/union/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/linux-5.4.139" KCFLAGS="-fmacro-prefix-map=/scratch/union/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi=target-arm_cortex-a15+neon-vfpv4_musl_eabi" HOSTCFLAGS="-O2 -I/scratch/union/staging_dir/host/include -I/scratch/union/staging_dir/hostpkg/include -I/scratch/union/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/host/include -Wall -Wmissing-prototypes -Wstrict-prototypes" CROSS_COMPILE="arm-openwrt-linux-muslgnueabi-" ARCH="arm" KBUILD_HAVE_NLS=no KBUILD_BUILD_USER="" KBUILD_BUILD_HOST="" KBUILD_BUILD_TIMESTAMP="Sun Aug  8 13:17:14 2021" KBUILD_BUILD_VERSION="0" HOST_LOADLIBES="-L/scratch/union/staging_dir/host/lib" KBUILD_HOSTLDLIBS="-L/scratch/union/staging_dir/host/lib" CONFIG_SHELL="bash" V=''  cmd_syscalls= KBUILD_EXTRA_SYMBOLS="/scratch/union/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/symvers/gpio-button-hotplug.symvers" KERNELRELEASE=5.4.139  M="/scratch/union/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/qca-nss-gmac-9b74deef" EXTRA_CFLAGS="-DCONFIG_NSS_DEBUG_LEVEL=4 -I/scratch/union/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/qca-nss-gmac-9b74deef/nss_hal/include -I/scratch/union/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/qca-nss-gmac-9b74deef/nss_hal/ipq806x" modules
make[4]: Entering directory '/scratch/union/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/linux-5.4.139'
  CC [M]  /scratch/union/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/qca-nss-gmac-9b74deef/ipq806x/nss_gmac_dev.o
  CC [M]  /scratch/union/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/qca-nss-gmac-9b74deef/ipq806x/nss_gmac_ctrl.o
/scratch/union/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/qca-nss-gmac-9b74deef/ipq806x/nss_gmac_ctrl.c: In function 'nss_gmac_of_get_pdata':
/scratch/union/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/qca-nss-gmac-9b74deef/ipq806x/nss_gmac_ctrl.c:994:21: error: too few arguments to function 'of_get_mac_address'
  maddr = (uint8_t *)of_get_mac_address(np);
                     ^~~~~~~~~~~~~~~~~~
In file included from /scratch/union/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/qca-nss-gmac-9b74deef/ipq806x/nss_gmac_ctrl.c:44:
./include/linux/of_net.h:14:12: note: declared here
 extern int of_get_mac_address(struct device_node *np, u8 *mac);
            ^~~~~~~~~~~~~~~~~~
make[6]: *** [scripts/Makefile.build:262: /scratch/union/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/qca-nss-gmac-9b74deef/ipq806x/nss_gmac_ctrl.o] Error 1
make[5]: *** [scripts/Makefile.build:497: /scratch/union/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/qca-nss-gmac-9b74deef/ipq806x] Error 2
make[4]: *** [Makefile:1734: /scratch/union/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/qca-nss-gmac-9b74deef] Error 2
make[4]: Leaving directory '/scratch/union/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/linux-5.4.139'
make[3]: *** [Makefile:49: /scratch/union/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/qca-nss-gmac-9b74deef/.built] Error 2
make[3]: Leaving directory '/scratch/union/package/qca/qca-nss-gmac'
time: package/qca/qca-nss-gmac/compile#0.99#0.18#1.71
    ERROR: package/qca/qca-nss-gmac failed to build.
make[2]: *** [package/Makefile:116: package/qca/qca-nss-gmac/compile] Error 1
make[2]: Leaving directory '/scratch/union'
make[1]: *** [package/Makefile:110: /scratch/union/staging_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/stamp/.package_compile] Error 2
make[1]: Leaving directory '/scratch/union'
make: *** [/scratch/union/include/toplevel.mk:230: world] Error 2

it's very easy to fix, refer to the commits on how to fix this. Minimal changes required :smiley:

Sorry, which commits? Plus, you're assuming I understand the errors :smiley:

The .138 patch seems benign and should build.

The .139 patch may interfere with this recent commit: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=774b386a928339ef1169f5b121fce2ccd3aa5e96

I’d double check these recent changes against your patch and see if there is a conflict.

1 Like

I'll have to let one of you guys take this... it's beyond me to figure out what's wrong and fix it.

EDIT: Just grepping for some key words here not knowing what the actual code does.
My 5.4.139 patch shows

% grep smsc95xx *.patch|grep mac_a
0002-kernel-bump-5.4-to-5.4.139.patch:  static void smsc95xx_init_mac_address(struct usbnet *dev)

The first error shows:

/scratch/union/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/qca-nss-gmac-9b74deef/ipq806x/nss_gmac_ctrl.c: In function 'nss_gmac_of_get_pdata':
/scratch/union/build_dir/target-arm_cortex-a15+neon-vfpv4_musl_eabi/linux-ipq806x_generic/qca-nss-gmac-9b74deef/ipq806x/nss_gmac_ctrl.c:994:21: error: too few arguments to function 'of_get_mac_address'
  maddr = (uint8_t *)of_get_mac_address(np);

I'm not sure what to change nor if I'm remotely on the right track.

Added a patch that uses new of_get_mac_address api:

4 Likes

Confirmed functional NSS with 5.4.139. Thanks!

Building @KONG 's kernel5.4-nss-qsdk10.0 branch against HEAD recently throws an error:

...
make[2] target/compile
 make[3] -C target/linux compile
    ERROR: target/linux failed to build.
make -r world: build failed. Please re-run make with -j1 V=s or V=sc for a higher verbosity level to see what's going on
make: *** [/scratch/union/include/toplevel.mk:230: world] Error 1

When you build with 1 job it seems the problem is an option in the config (kernel?) is not refreshed. I'm wondering how to fix this. Note that if I build without rebasing in kong's kernel5.4-nss-qsdk10.0 branch, I do not experience this.

% make -j1 V=s
...
scripts/kconfig/conf  --syncconfig Kconfig
net/sched/Kconfig:45: warning: menuconfig statement without prompt
net/Kconfig:478:warning: multi-line strings not supported
*
* Restart config...
*
*
* Core Netfilter Configuration
*
Netfilter ingress support (NETFILTER_INGRESS) [Y/n/?] y
Netfilter NFNETLINK interface (NETFILTER_NETLINK) [N/m/y/?] n
Netfilter NFACCT over NFNETLINK interface (NETFILTER_NETLINK_ACCT) [N/m/y/?] n
Netfilter NFQUEUE over NFNETLINK interface (NETFILTER_NETLINK_QUEUE) [N/m/y/?] n
Netfilter LOG over NFNETLINK interface (NETFILTER_NETLINK_LOG) [N/m/y/?] n
Netfilter OSF over NFNETLINK interface (NETFILTER_NETLINK_OSF) [N/m/y/?] n
Netfilter connection tracking support (NF_CONNTRACK) [M/n/y/?] m
Netdev packet logging (NF_LOG_NETDEV) [N/m/y/?] n
Connection mark tracking support (NF_CONNTRACK_MARK) [Y/?] y
Connection tracking zones (NF_CONNTRACK_ZONES) [Y/n/?] y
Supply CT list in procfs (OBSOLETE) (NF_CONNTRACK_PROCFS) [Y/n/?] y
Connection tracking events (NF_CONNTRACK_EVENTS) [N/y/?] n
Connection tracking timeout (NF_CONNTRACK_TIMEOUT) [N/y/?] n
Connection tracking extension for dscp remark target (NF_CONNTRACK_DSCPREMARK_EXT) [N/y/?] (NEW)

I rebuilt at this commit from a couple days ago “kernel: bump 5.4 to 5.4.140”

Don’t see any obvious commits that would cause major issues since that time.

Is it complaining about your config file in the log?

I successfully compiled HEAD+5.4.142 by first building the build bot R7800 config, then make clean and rebasing against kong's branch and my own nss config. Let me try this again a bit later today going right for the NSS code + 5.4.142.

1 Like

It built fine/I cannot reproduce the original error I reported :man_shrugging:

1 Like

Hi, need help, can i use the branch openwrt-21.02-ipq806x-nss-qsdk11 on quarkysg's repo? is this stable? if not please suggest me which branch should i try.

Also, do i need to select the nss modules under kernel? if yes please let know which ones from the below to be selected. im no system programmer, pls help

I would suggest you try @ACwifidude repo. Mine does not include the NSS firmware. If you manage to get hold of the 11.2 NSS firmware, feel free to use my repo. My R7800 is running it now, with 63 days uptime.

Otherwise pls try @ACwifidude repo.

First two posts should get you started.

great documentation there, thanks a lot. i ll check and get back

@quarky thanks

I have a AP with IPQ6018 chipset and QSDK build.

I am running a go program to create tunnels to other APs and am using Noise Protocol Framework for the encryption/decryption part (AEAD Cipher --> AES-256-GCM).

The cryptoapi module which supports gcm is already loaded -

cat /proc/crypto
name         : gcm(aes)
driver       : nss-gcm
module       : qca_nss_cfi_cryptoapi
priority     : 10000
refcnt       : 1
selftest     : passed
internal     : no
type         : aead
async        : yes
blocksize    : 16
ivsize       : 12
maxauthsize  : 16
geniv        : <none>

name         : seqiv(rfc4106(gcm(aes)))
driver       : nss-rfc4106-gcm
module       : qca_nss_cfi_cryptoapi
priority     : 10000
refcnt       : 1
selftest     : passed
internal     : no
type         : aead
async        : yes
blocksize    : 16
ivsize       : 8
maxauthsize  : 16
geniv        : <none>

name         : rfc4106(gcm(aes))
driver       : nss-rfc4106-gcm
module       : qca_nss_cfi_cryptoapi
priority     : 10000
refcnt       : 1
selftest     : passed
internal     : no
type         : aead
async        : yes
blocksize    : 16
ivsize       : 8
maxauthsize  : 16
geniv        : <none>

lsmod | grep qca_nss_cfi_cryptoapi
authenc                16384  1 qca_nss_cfi_cryptoapi
qca_nss_cfi_cryptoapi   53248  1 qca_nss_ipsecmgr

My question is, if the cryptoapi module is loaded, will the encryption-decryption part automatically be accelerated or would i have to do something ?

Your ‘go’ program is likely running in user space?

If so you will not get any benefit from the crypto cores. You’ll likely get worst performance as moving data from user to kernel space is slow. This is especially apparent if your payload is small. Better off using openssl that’s compiled with the -O3 flag.

If your tunnel is running in kernel space, then it’ll have speed up benefits.

I have read through this thread with a lot of interest.

Does anyone know if the vendor-provided firmware for the R7800 supports the NSS cores for offloading?

I think you missed some part then...

There are many NSS firmware and they need to be synced with the QSDK used. (the driver part)
So yes the vendor-provided firmware support NSS cores but use an ancient NSS firmware and it doesn't make sense to use that as we have more recent version that accomplish the same task but better code and feature.

Obviously I did. This is a long thread. Thanks for replying.