@Ansuel and @hnyman Test-DSA-kernel510-master-r16293-310b7f76e8-20210321 Boot Log
Power Adapter is
Netgear P/N 332-10762-01;
Model No. MU42-3120350-A1 (U.S.A. pin);
Input: AC 100-240V, 50/60Hz, 1.5A;
Output: DC 12V, 3.5A
I also got gibberish initially in Putty both in Windows 10 and Linux. I had to swap TX and RX pins to get proper output.
Not quite, IMHO.
Here's how I do it:
-
Install the actual firmware
-
Upload the ath10k driver to /tmp via scp (WinSCP or whatever tool you want)
---- the driver is the file located in the same Dropbox folder as the firmware, ie. for the current owrt2102-r15915-31bca5f256-20210319 version, the non-ct driver would be this one:
ath10k-mainline-owrt2102-r15915-31bca5f256-20210319-2150.ipk -
Upload the ath10k blob to /tmp via scp
Blobs are located here: https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/base/
Look for the non-ct version of the qca9984, usually the last one in the list, ie:
ath10k-firmware-qca9984-ct-full-htt_2020-11-08-1_arm_cortex-a15_neon-vfpv4.ipk
ath10k-firmware-qca9984-ct-htt_2020-11-08-1_arm_cortex-a15_neon-vfpv4.ipk
ath10k-firmware-qca9984-ct_2020-11-08-1_arm_cortex-a15_neon-vfpv4.ipk
ath10k-firmware-qca9984_20201118-3_arm_cortex-a15_neon-vfpv4.ipk -
remove the -ct variant:
opkg remove kmod-ath10k-ct -
remove the -ct blob:
opkg remove ath10k-firmware-qca9984-ct -
install the non-ct firmware:
opkg install /tmp/ath10k-mainline-blabla*.ipk -
install the blob:
opkg install /tmp/ath10k-firmware-blabla*.ipk -
reboot
That's it. That's how I do it. Works every time.
3 Likes
Thank you. It seems that the only difference between this and mine actions is that for some reason my resulting installed blob is older (ath10k-firmware-qca9984 20190416-1). Maybe Luci installs something that's more appropriate for my version of OpenWRT? (I downgraded to 19.07 again).
You came here to bash good Devs. free time efforts but you're struggling to install a package even with clear instructions!!! LOL!!! Just go back on crapy manufacturer firmware!!!
The package definitions are separate for each branch. The wifi drivers and wifi firmware blobs offered for in the ancient releases (like 19.07) have not been updated regularly...
19.07 offers older blob than master, like you have noticed.
https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/base/
https://downloads.openwrt.org/releases/packages-19.07/arm_cortex-a15_neon-vfpv4/base/
You need to use the respective driver targeting the respective OpenWrt branch, but you might be better off by loading a newer ath10k firmware blob from master, even for 19.07. I haven't tested it myself, but to my understanding the ath10k blobs have no direct link to a specific driver version. (QCA even has several concurrent variants with separate versioning)
The whole ath10k driver system is pretty confusing with several wifi chip firmware blob variants, mainline/ct driver variants etc.. You are free to try to find the best combination for your client hardware. Sadly none of the blobs or drivers are perfect.
(But situation is still better than with the abandoned mvebu mwlwifi...)
3 Likes
Just wanted to say Thank You for your work on the R7800 and OpenWRT. Bought a pair of these routers fairly recently, and found your build for them. Grateful to all the OpenWRT contributors, and certainly to you for sticking with this router. Haven't had any issues, myself, with the ath -ct driver/firmware, but radio related stuff has always been the hangup for me, using non-vendor firmware.
Can't believe how involved building a new firmware is these days- did a make menuconfig just to take a peak... WOW.
Anyway, just wanted to say that there are some of us using your build scripts/patches. I've got some tweaks I need for my own situation, so I've been looking at your posted build environment, and using it. Pretty easy getting the old ath10k stuff built/installed with your patches. 
Sure hope you keep your R7800 for a bit. I'm not up to speed at all. Again, thanks for your work.
1 Like
I would like to ask that the current version has two more ipk files. If I just upgrade the bin file and don’t know how to install the ipk file, is it not very effective for the r7800?
Fun story. Everything was working fine in 19.07 when I installed the 2019 non-ct blob via Luci interface (after following previous instructions on the driver itself).
Then I decided to uninstall the 2019 blob and installed the 2020 blob from https://downloads.openwrt.org/snapshots/packages/arm_cortex-a15_neon-vfpv4/base/ .
It asked for corresponding ath10k-board 9984 blob too, so I installed that first.
Finally it installed.
Since then my 2.4ghz frequency became very weird. My phone refuses to initialize WiFi Calling mode (switching clean from Airplane mode on/off) under moderate conditions ("Poor signal").
When on the same floor as router, it does initialize, but then every SMS I received from my friend today was a copy of the first SMS he sent!
I have 9 of these identical SMS and I thought he was making fun of me.
Note that this condition persisted after I uninstalled the 2020 blob and the "board" file, and went back to Luci to install the appropriately-listed 2019 blob (and restarted).
I switched to 5ghz and suddenly I got all the correct SMSes from my friend in bulk, but 2.4ghz remains fucked.
I'll have to reflash 19.07 now. Whatever blob Luci is listing there, however old, is a good one for 19.07. Don't install the newer ones.
UPDATE: flashed 19.07 again, installed the 2019 blob via Luci, WiFi calling initializes even when the phone is on the table. QED.
Just stay away from this. It's just overloading some users.
March 2021: CPU frequency scaling settings configurable via
/etc/init.d/cpufreq, applied at boot
In the last few builds, I have set the CPU frequency scaling options via a startup script, instead of patching the kernel sources like earlier. I had already earlier made the CPU scaling moderately more aggressive, but the main recent change in the last few days is the elimination of the lowest 384 MHz frequency from the CPU speed table by setting 600 MHz as the lowest speed used in the scaling.
The 384M step had visible negative impact in speed testing (with "flent").
In the charts below, I tested the default "ondemand" frequency governor with the default 384M step enabled, then 600M set as the scaling_min_freq, and finally with the performance governor (=always top frequency).
There is not much difference between "performance" (right) and the "ondemand" with 600M minimum (middle), but the 384M min (left) lets lots of bandwidth unused. SQM is used.
Eliminating the 384M CPU speed decreased latency from 33 to 27 ms, while visibly increasing the throughput. Using "performance" still improves things, but at least for my personal usage, really needing the top speeds is rare.
Current script:
--- /dev/null
+++ b/target/linux/ipq806x/base-files/etc/init.d/cpufreq
@@ -0,0 +1,16 @@
+#!/bin/sh /etc/rc.common
+
+START=15
+
+boot() {
+ # Select 'ondemand'=scaling or 'performance'=always max freq
+ echo ondemand > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
+ echo ondemand > /sys/devices/system/cpu/cpufreq/policy1/scaling_governor
+
+ # Effective only with ondemand
+ echo 600000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
+ echo 600000 > /sys/devices/system/cpu/cpufreq/policy1/scaling_min_freq
+ echo 20 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
+ echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
+}
+
After my flent testing, Ansuel gave me the idea about using the startup script in the kernel 5.10 discussion, and I tested it. Works nicely. My current script is above. Ansuel is now trying to get this elimination of the 384M into the main OpenWrt via a PR 
- discussion starting from [PR] ipq806x: kernel 5.10 bump code propose - #75 by hnyman
- PR https://github.com/openwrt/openwrt/pull/4033
5 Likes
In the past there was talk about frequencies under 800MHz causing problems. When I run ondemand I set the minimum at 800, but these days I run performance all the time at 1.7 without any problems, heat/temperature are fine about 1-2C higher than ondemand.
1 Like
What problem?
I think the comments here:
https://source.codeaurora.org/quic/qsdk/oss/system/openwrt/tree/target/linux/ipq806x/base-files/etc/init.d/powerctl
1 Like
This is actually interesting
CPU1 min frequency also has to be increased because there is a hardware constraint
# kraits cannot operate at 384MHz when L2 is at 1GHz.
This appears to be coming full circle back to something like the startup script I commented out because people in this thread said it was outdated. I am just going to go ahead and uncomment it again in my 19.07 hnyman firmware.
echo ondemand > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
echo ondemand > /sys/devices/system/cpu/cpufreq/policy1/scaling_governor
echo 800000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
echo 800000 > /sys/devices/system/cpu/cpufreq/policy1/scaling_min_freq
echo 75 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo 10 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
1 Like
please can someone give me step by step instructions/ a video on how to install hnyman build using the tftp method. I have been reading and I still don't get how to install the .img on to my r7800
Download a *-factory.img image and then install it following this guide
(tftp client needs to be enabled in the Programs and Features menu in windows).
I clicked this guide but your link took me to https://kb.netgear.com/app/error//error_id/1 and then it redirected to https://www.netgear.com/support/
You should be able to flash directly from the Netgear GUI.
The TFTP flashing mode should not be needed, but in case you later need it, it is well documented in wiki and here in the forum:
1 Like