OpenWrt support for Xiaomi AX9000

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:

I figured out that Hungary is country code 348:

|uint16|REGULATORY_DB_SECTION.regDbAllCountries[66].country_code| 348 |
|---|---|---|
|uint16|REGULATORY_DB_SECTION.regDbAllCountries[66].reg_dmn_pair_id| 55 |
|uint8|REGULATORY_DB_SECTION.regDbAllCountries[66].alpha2[0]| 72 |
|uint8|REGULATORY_DB_SECTION.regDbAllCountries[66].alpha2[1]| 85 |
|uint8|REGULATORY_DB_SECTION.regDbAllCountries[66].alpha2[2]| 0 |
|uint8|REGULATORY_DB_SECTION.regDbAllCountries[66].alpha2_11d[0]| 72 |
|uint8|REGULATORY_DB_SECTION.regDbAllCountries[66].alpha2_11d[1]| 85 |
|uint8|REGULATORY_DB_SECTION.regDbAllCountries[66].alpha2_11d[2]| 0 |
|uint8|REGULATORY_DB_SECTION.regDbAllCountries[66].max_bw_2g| 40 |
|uint8|REGULATORY_DB_SECTION.regDbAllCountries[66].max_bw_5g| 160 |
|uint8|REGULATORY_DB_SECTION.regDbAllCountries[66].phymode_bitmap| 0 |
|uint8|REGULATORY_DB_SECTION.regDbAllCountries[66].pad| 0 |

and this is the corresponding regdomain par id:

|uint16|REGULATORY_DB_SECTION.regDbRegDmnPairs[16].reg_dmn_pair_id| 55 |
|---|---|---|
|uint8|REGULATORY_DB_SECTION.regDbRegDmnPairs[16].dmn_id_5g| 10 |
|uint8|REGULATORY_DB_SECTION.regDbRegDmnPairs[16].dmn_id_2g| 3 |

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

Is the source drop for the AVM Fritz Repeater 6000 interesting? It should be IPQ8074.
https://boxmatrix.info/wiki/FRITZ!Repeater_6000
Go down to source scans and click on the md5

Not really as the kernel and all of the stuff is already public.

@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.

[   10.563935] ath11k c000000.wifi: ipq8074 hw2.0
[   10.564150] remoteproc remoteproc0: powering up cd00000.q6v5_wcss
[   10.567374] remoteproc remoteproc0: Booting fw image IPQ8074/q6_fw.mdt, size 668
[   10.929695] remoteproc remoteproc0: remote processor cd00000.q6v5_wcss is now up
[   10.931465] ath11k c000000.wifi: qmi ignore invalid mem req type 3
[   10.936693] ath11k c000000.wifi: chip_id 0x0 chip_family 0x0 board_id 0x294 soc_id 0xffffffff
[   10.942175] ath11k c000000.wifi: fw_version 0x250684a5 fw_build_timestamp 2021-07-13 10:57 fw_build_id QC_IMAGE_VERSION_STRING=WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1
[   11.114858] remoteproc remoteproc0: stopped remote processor cd00000.q6v5_wcss
[   11.114898] remoteproc remoteproc0: powering up cd00000.q6v5_wcss
[   11.121077] remoteproc remoteproc0: Booting fw image IPQ8074/q6_fw.mdt, size 668
[   16.604994] qcom-q6v5-wcss-pil cd00000.q6v5_wcss: start timed out
[   16.605033] remoteproc remoteproc0: can't start rproc cd00000.q6v5_wcss: -110
[   16.610096] ath11k c000000.wifi: failed to boot the remote processor Q6

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.

2 Likes

Let me know when its done so I can give it a try :slight_smile:

I can see that Hauke is at 5.14 atm, he probably needs a bit of time to finish all the way to 5.15.

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.

2 Likes

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.

Don't get discouraged! You are making progress by tackling issues one by one!
You are our hero :slight_smile:
Please do not stop

1 Like

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.

1 Like

That would be nice, but as far as I know 5.15.x is not a LTS, right?

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

Unfortunately, that's not so fully clear yet.

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

Has anyone tested how ax9000 behaves with recent robimarko's developments?
If so, please share your observations

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.

Thank you, I have followed the SSDK/QNSS-DP path but I can't see anything obviously wrong nor missing either.
Ok with gzip compression it boots.

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.