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

I tried to reproduce the build (with CONFIG_ALL=y and IGNORE_ERRORS="n m") on the openwrt-21.02-nss-qsdk10.0 branch, and failed. The failed package is package/qca/qca-nss-clients, and it fails because it tries to include stuff from qca-ssdk which is not provided by any package. @ACwifidude looks like either a forgotten instruction to fully disable package/qca/qca-nss-clients, or a forgotten inclusion of qca-ssdk.

Why do you need to use CONFIG_ALL=y?

SSDK is not included in this for IPQ806X for now but it works fine without it.

CONFIG_ALL=y is needed so that I can build everything and sidestep the current breakage in the official repositories. See https://lists.openwrt.org/pipermail/openwrt-devel/2021-July/035741.html

Regarding the SSDK situation, OK, it is not included, but let me check my understanding.

Right now in the suggested minimal config (in the first comment, to be expanded by make defconfig), there is CONFIG_PACKAGE_kmod-qca-nss-drv-pppoe=y. This package comes from package/qca/qca-nss-clients, and the minimal config uses nothing else from there, but CONFIG_ALL sets them all to m.

If I understand the build system correctly, the Makefile tries to build exactly the modules that are requested in OpenWRT .config, but some of them fail because they have a #include <fal/fal_*.h> which is in SSDK. They are all m because of CONFIG_ALL=y, but IGNORE_ERRORS="n m" for some reason does not ignore this failure. It does successfully ignore failures in other packages that have no subcomponents set to y. So I have to explicitly disable CONFIG_PACKAGE_kmod-qca-nss-drv-capwapmgr, CONFIG_PACKAGE_kmod-qca-nss-drv-lag-mgr, and CONFIG_PACKAGE_kmod-qca-nss-drv-vlan-mgr.

Edit: there is also CONFIG_PACKAGE_kmod-qca-nss-drv-bridge-mgr, but the Makefile marks it as unavailable for IPQ806X via the DEPENDS clause. So maybe the whole issue is that all other SSDK-dependent modules do not have the proper DEPENDS clause which limits them to the same targets?

Right?

Possibly not a problem of this fork, please point me in the right direction if so.

I noticed that the builds I produce by running

./scripts/feeds update -a
./scripts/feeds install -a
cp diffconfig .config
make defconfig
make -j4 download
make -j4

Won't boot unless flashed via sysupgrade without clearing the settings on the router. Naturally, same thing happens if I flash via TFTP or do a factory reset after flashing via sysupgrade.

Other than this, the builds work fine bar some WiFi stability issues. Is there a step missing from the instructions to reproduce the builds? Is there something that needs to be done for the correct "factory defaults" to be included in the image?

Thank you @kong, sorry i did not know you had this on git..
Let's see if @ACwifidude can include this in the next build..
thanks!

2 Likes
speedtest-ookla
#!/bin/sh
ARCH="$1"
if [ -z "$ARCH" ]; then
	. /etc/openwrt_release
	case "$DISTRIB_ARCH" in
		aarch64_cortex-a72) ARCH="aarch64"; ;;
		arm_cortex-a15_neon-vfpv4) ARCH="armhf"; ;;
		x86_64) ARCH="x86_64"; ;;
	esac
fi
if [ -z "$ARCH" ]; then echo "$0 [x86_64|armhf|aarch64]"; exit 0; fi
case "$ARCH" in
	x86_64) oURL=https://install.speedtest.net/app/cli/ookla-speedtest-1.0.0-x86_64-linux.tgz; ;;
	armhf) oURL=https://install.speedtest.net/app/cli/ookla-speedtest-1.0.0-armhf-linux.tgz; ;;
	aarch64) oURL=https://install.speedtest.net/app/cli/ookla-speedtest-1.0.0-aarch64-linux.tgz; ;;
esac
mkdir /tmp/ookla && wget $oURL -O /tmp/ookla/ookla.tgz && \
(cd /tmp/ookla; tar -xzf *.tgz; mv speedtest /usr/bin/speedtest-ookla) && \
rm -rf /tmp/ookla
exit $?

@joelvdvoort NSS requires patches that several developers don’t think will make it in to master. Some of the newer devices are dependent on NSS drivers for certain functions so hopefully that will lead to NSS offloading in master eventually.

@patrakov I updated my diffconfig to look like this to exclude the NSS packages that do not compile correctly:

@pandasauce interesting. The build steps look right. There are always bugs that are introduced in to master, such is life with active development. It is probably a bug. I usually make clean my build environment then look through the devel mailing list, latest commits to master, and these forums to see what has changed that could be causing my issue. The clean often times is enough to fix several small issues as people redefine dependencies / packages / variables / match with upstream / etc.

1 Like

@ACwifidude cheers for the response. I am building the stable openwrt-21.02-nss-qsdk10.0 branch with feeds matched to feeds.buildinfo and I run make distclean between the builds, so it is particularly odd to see this behaviour. I'll check the mailing lists.

Updated both the 21.02 and master builds. Added some USB storage kmods for relevant file systems and added the essential storage crypto packages.

1 Like

Today after 10 days I suffered a reboot, very random, I was not doing anything in particular, I tried to access a computer locally. still, 10 days is already a very acceptable option.

So far so good - Code as of June 19 seems to have good performance and pretty good stability:

$ uptime
21:07:35 up 18 days, 5:53, load average: 1.00, 1.00, 1.00
$

1 Like

Uptime seems good, load average on mine is a lot less, more around 0.02/0.03.

Are you running additional services or software on yours?

with the restart I have put the last ACwifi image, kernel 5.4 with CT driver. I see this message repeated ad nauseam in syslog filling this up completely

Thu Jul 8 16:53:34 2021 daemon.err collectd[3370]: Available write targets:: [none]

the message is home less than 100ms seconds or so, constant.

on the other hand, the image goes very fast, the wifi very fast, thank you!

It seems that there is a problem with dropbear. After exiting the ssh session, it seems that the process stays stuck. After multiple ssh login/logout, the problem gets worse.
If I kill these processes, the load drops down to close to zero.

My R7500v2 was using a couple months old build, so I decided to update its firmware to the most recent one. First, I installed ath10k build to give it a spin and I noticed some of the connected WiFi clients couldn't transfer data higher than 30 Mbps, but some others were able to transfer at full line speed. After that, I installed the ath10k-ct build and now all clients are moving data at full speed.

I had noticed before this 30 Mbps WiFi cap on some clients, while testing a NSS build from another developer, which uses ath10k drivers.

Any ideas about this issue?

BTW, thanks a lot @ACwifidude for your work!!!

The ath10k encap offloading might be causing an issue. I can remove it on the next build.

1 Like
CONFIG_REGULATOR_NSS_VOLT
CONFIG_SHORTCUT_FE

set these up in config-5.4?

1 Like

no please don't!
i've just buildt and updated my R7800

Positive with new ath10k: 5G comes up also @160MHz (it stopped working some time ago)
Negative with ALL ath10k ever tried: performance @160MHz are rubbish.. in the 300Mbps, where @80.. well, you can see :slight_smile:

1 Like

Is the low throughput on 2.4ghz?