I thought maybe they are updating it, but as they stayed with the same 2.0 major version of wifi firmware, it seems the BDF is intact. If the AX6 or the AX3600 would ever receive an official update to 2.4, the BDF will likely change.
Anyway, I am trying to leg some logic to the regdb part:
The question is, how the hell this is mapped to RegRule2g ??
Line 103214: uint16 REGULATORY_DB_SECTION.regDbRegRule2g[0].start_freq 2402
Line 103215: uint16 REGULATORY_DB_SECTION.regDbRegRule2g[0].end_freq 2472
Line 103216: uint16 REGULATORY_DB_SECTION.regDbRegRule2g[0].max_bw 40
Line 103217: uint8 REGULATORY_DB_SECTION.regDbRegRule2g[0].reg_power 30
Line 103218: uint8 REGULATORY_DB_SECTION.regDbRegRule2g[0].pad 0
Line 103219: uint16 REGULATORY_DB_SECTION.regDbRegRule2g[0].flags 0
Line 103220: uint16 REGULATORY_DB_SECTION.regDbRegRule2g[1].start_freq 2402
Line 103221: uint16 REGULATORY_DB_SECTION.regDbRegRule2g[1].end_freq 2472
Line 103222: uint16 REGULATORY_DB_SECTION.regDbRegRule2g[1].max_bw 40
Line 103223: uint8 REGULATORY_DB_SECTION.regDbRegRule2g[1].reg_power 20
Line 103224: uint8 REGULATORY_DB_SECTION.regDbRegRule2g[1].pad 0
Line 103225: uint16 REGULATORY_DB_SECTION.regDbRegRule2g[1].flags 0
Where the channel and power data is mapped.
MOD: one more thing: I tried to convert the original BDF to text, then back to bin, and the two files differ....
Yeah, as long as the FW version is the same and the HW is the same I don't think they will update the BDF-s.
No idea how are they mapping regulatory stuff in the BDF, to me it's all black magic.
I suppose that the difference is due to templates, because if you have never BDF that has a field populated that is not in the template the its length is unknown
@dchard Using the new backports to built-in radios is becoming more and more of a pain, now it looks like coldboot calibration is working, however, after it's done it will reset the Q6 firmware by shutting the remoteproc down and then starting it up.
But it will stop it, then start it, stop it start it etc until it just gives up.
No idea why is it failing as the core even prints that it was able to start it.
If I disable coldboot calibration, then I got a kernel panic due to a NULL pointer in the spectral scan code that calls the relayfs relay_open.
Traced that down to changes in 5.11 kernel that it requires, thankfully those were easy to backport and now it doesn't crash due to that.
Anyway, I should hopefully debug this somehow so that people can test to see if the memory leak exists in 5.14 as well.
Well, it looks like it's gonna take some time as remoteproc core changed in regards to stop/start and stuff like that so I need to backport like 2 patches.
Yeah, he did 5.14 during the weekend, hopefully 5.15 will be done soon so I can backport the things that landed in 5.16 like survey dumps so we can drop the local patch pulled from QCA for that.
Has anybody managed to use xqrepack to remove most of the QCA crap?
I really don't want to have to jailbreak it again after flashing stock like it does by default.
I can do it manually, but not really in a mood to spend time on it.
I just want to copy caldata that it extract to compare.
@dchard Discovered one crazy thing, ath11k doesn't even request the caldata for QCN9074, that is why the MAC is completely incorrect as well as why the channel list is fully enabled.
This is crazy, like really crazy.
Now I got caldata loaded, it required more backporting.
But then that broke AHB radios, so all of this completely out of sync backporting is driving me crazy.
5.10 is just too old at this point.
The thing is that I am playing whack a mole here, essentially I need to backport a shitload of stuff that this has no resemblance to 5.10 kernel anymore.
I seriously hope that OpenWrt will be getting 5.15 soon.
Its most likely gonna be an LTS, as I don't think that 5.16 will make it this year.
And even if its not then the diff is way smaller to update to an LTS
What only a few know is that Linux 5.15 will be the last major kernel release of the year, which means that it could be the next LTS (Long-Term Support) series, supported for at least a couple of years. Of course, this information needs to be confirmed by Linux kernel developer Greg Kroah-Hartman.13 Sep 2021
Available memory still decreases at about the same rate as the previous versions. And I can't include the qcn9074 firmware, the initramfs image doesn't boot. But something may be incorrect in my .config.
The uplink is still limited to 100M. At least it operates in full duplex mode now.
It will get too large with the QCN9074 FW, you need to compress the initramfs.
Note that the PCI card doesn't work yet, the calibration loading is broken.
As far as the uplink goes, that's a SSDK/NSS-DP issue.
Thanks @flebourse
Is 100M affecting only QCA8081 (2.5Mbit) or all RJ45 ports?
Maybe when Hauke finishes backporting 5.15 the situation with memory leak will improve?
What do you think @robimarko?
As much as it seems, most of the much awaited part pf the ath11k driver update will only land in 5.16. Non the less as the leak might be somewhere else (like in the QRTR part) backporting can certainly help, and even if its not solving the bug directly, at least it would save a ton of time for Robi to backport only 5.16 --> 5.15.
Please keep in mind that for example the QRTR part is not part of Hauke's backport as he is only backporting the wireless part and not the complete kernel.