Maybe I am saying something obvious and did in the past (sorry if I am naive) but we cannot write to , i.e., netgear? After all of these years, could "open" a little more the product... We are all buying it because it is a very good router and also because the great community and free support.
we already have full source of both qsdk and the source code of the firmware...
problem is qcom not providing documentation for its proprietary firmware blob.
1 Like
Was digging through and organizing the NSS commits. Any reason your cache scaling driver is not in master? Seems like if the cache is not scaling appropriately for our devices with the standard driver that we could get your driver implemented in master easily (this is just one of the commits, just to jog your memory):
there are multiple version of the cache scaling driver...
If you want I can give you a better version
Absolutely! I was trying to evaluate how critical the scaling was / if there was a better version
I think I can combine the NSS commits in to 4 commits:
- core Packages
- ipq806x patches and config changes
- .dts and dtsi changes
- wifi offloading
i would advice to split the ipq806x patches to more patches like
add missing reset for nss
add missing regulator for nss regulator
anyway @ACwifidude
This was the last patch i tried to post...
Check the second patch of the series to use the driver
1 Like
Many of the commits are working on the same parts of code (ex: 80211 offloading, nss frequency, and .dts files).
Iām going to simplify what we already have and then if there are recommended splits that might make parts of nss palatable for getting in to master we can further split. 
i think the point is that patches simply split along file/directory structure lines will not be accepted. the devs want each patch to represent a coherent fix/piece of functionality, so that it can be reverted if it laters turns out to cause a problem. notice how when some of the stuff in @Ansuel's branch wouldn't apply you could just revert that commit? how would you do that if he had just bunged all the changes for one file into a single commit, regardless of whether they related to each other?
3 Likes
does this need dtsi changes? at first glance it doesn't look like there's a single commit to revert in the kernel5.4-nss-qsdk10.0 branch and then apply this one?
yes you need to replace a patch and modify the dts to reflect the new changes... Also the fab scaling patch needs to be adapted.
qcom is qualcomm? May with involve them?
I have an issue, i just upgraded from OpenWrt SNAPSHOT r14749-472a06f707 to
OpenWrt SNAPSHOT r15469-425e392466 on one of my R7800s, but now 160MHz does not work anymore. Only 80MHz. Looking at the log this is because DFS fails and hence no 160MHz channels are allowed.
Any idea how to fix this? Or is actually better to install the latest stable? Anything vital missing in the stable?
Thanks,
Ramon
Mon Jan 11 17:15:33 2021 daemon.notice hostapd: wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
Mon Jan 11 17:15:33 2021 kern.info kernel: [69397.033696] br-lan: port 2(wlan0) entered disabled state
Mon Jan 11 17:15:33 2021 daemon.notice hostapd: ACS: Automatic channel selection started, this may take a bit
Mon Jan 11 17:15:33 2021 daemon.notice hostapd: wlan0: interface state COUNTRY_UPDATE->ACS
Mon Jan 11 17:15:33 2021 daemon.notice hostapd: wlan0: ACS-STARTED
Mon Jan 11 17:15:54 2021 daemon.notice hostapd: wlan0: ACS-COMPLETED freq=5500 channel=100
Mon Jan 11 17:15:54 2021 daemon.notice hostapd: wlan0: interface state ACS->HT_SCAN
Mon Jan 11 17:15:54 2021 daemon.notice hostapd: wlan0: interface state HT_SCAN->DFS
Mon Jan 11 17:15:54 2021 daemon.notice hostapd: wlan0: DFS-CAC-START freq=5500 chan=100 sec_chan=1, width=2, seg0=114, seg1=0, cac_time=60s
Mon Jan 11 17:15:54 2021 daemon.err hostapd: DFS start_dfs_cac() failed, -1
Mon Jan 11 17:15:54 2021 daemon.err hostapd: Interface initialization failed
Mon Jan 11 17:15:54 2021 daemon.notice hostapd: wlan0: interface state DFS->DISABLED
Mon Jan 11 17:15:54 2021 daemon.notice hostapd: wlan0: AP-DISABLED
Not really, I will most likely be busy for a two-three days until I can start poking.
1 Like
Does anyone know if there is a way to increase the maximum shaping throughput using cake/poc sqm? Really dislike losing over half my bandwidth just for more aggressive bufferbloat handling. I have a 460/23 coax line and the downstream is insanely latency sensitive after climbing over about 150-200Mbps without any sqm. Upwards of 1000ms delays and tons of re-transmits....
@Ansuel Do you have a test 5.10 tree that I can build off to avoid porting everything myself?
Also, I think we should move this discussion to a separate 5.10 IPQ806x thread?
I need to push it... Do you need it now?
No, I am done for the day anyway.
I should have some time tommorow midday/late night
1 Like
Ok will try to push it this night (do you mind if i push a very dirty tree? I manually added the 5.10 patches from the commits without cherry-pick the commits)