Thanks, it looks like only caldata is stored there.
@dchard Ok, I checked with someone that is more informed and they say that the FW is where the regulatory DB should be, and that BDF-s can ship regulatory info as well to use those.
But he doesn't have experience with QCN9074 but only IPQ8074 and they all have different formats.
Hmm, strange.
But xiaomi still uses qca-wifi, maybe qca-wifi doesn't need that information in the BDF?
And it is actually working if you use the BDF from the ath11k-bdf repo, right? (without channel limitation)
Did you check that firmware for included regdb?
And somehow ath11k is working with other PCI devices, like QCA6390.
No idea what the qca-wifi package even does.
Yes, if I just use the board-2.bin from ath11k-bdf It will work but the frequency range is not limited, powers are wrong, etc.
No, I didn't unpack that one but it's gotta have it, otherwise, ath11k would complain.
QCA6390 has nothing in common with the QCN9074 except for the driver, BDF format and FW are different.
All that ath11k does with BDF is pass it to the firmware, and it then makes calls to the firmware so they could implement stuff completely differently per IC.
I haven't found anything special regarding bdwlan in the extracted image.
They use the stock qsdk logic as far as i can see. No symlinking to other bdwlan etc.
The only thing they read from nvram is the country code (and ssids), they use it to set the country code for hostapd I assume.
@robimarko
Do you now why qsdk is extracting caldata_1 and caldata_2 from the art partition?
dd if=${mtdblock} of=${apdk}/qcn9000/caldata_1.bin bs=1 count=$FILESIZE skip=157696
dd if=${mtdblock} of=${apdk}/qcn9000/caldata_2.bin bs=1 count=$FILESIZE skip=311296
I dont think its extracting caldata_2 as there is only one QCN9024 card.
I the /tmp you will only find one, check out the ap-hk14 device caldata extraction, that is the AX9000 and it only fetches one caldata.
It even has a comment for the QCA9889 caldata
Yes, my bad.
caldata_2.bin is only there at the HK10.
OK, so the conclusion is (for at least IPQ8074) that the firmware (from Kalle's repo) should contain the correct regdb, which it does not, so we still think that the officially released firmware (2.5.0.1) has this issue?
No, IPQ8074 works fine.
Its the QCN9074(More precisely QCN9204 here) PCI card that is causing pains with regulatory, no idea if the FW is the issue.
The only thing I can confirm is that the FW built-in regulatory is really outdated.
OK, so the fact I am not able to set channel 13 on IPQ8074 relates to a very outdated regdb built into the firmware?
Looks like it
So it is still Kalle's problem to resolve, as we are using those firmwares 
Looks like it, honestly there is gotta be a way to workaround that as OEM-s do, especially since they are using ath11k firmware that ismuch older than 2.5.0.1
What do you think how soon can Hauke finish with the 5.15 backporting? I would assume 5.15 will be released in the next two weeks.
I kind of hope that he will finish it this weekend, but its really up to him.
That is a lot faster than I expected ath11k related modifications are already in linux-next, lets hope Hauke has some time this weekend.
He is fast once he gets to it, last time he did 5.13 and 5.14 in the same day.
Not sure if this belongs here, but in case someone's experimenting with OpenWrt on global AX9000 and needs to recover, there's a global firmware available:
{"code":"0","data":{"needUpgrade":true,"size":42069940,"changelogUrl":"https://cdn.awsde0-fusion.fds.api.mi-img.com/miwifi/133ae168-b278-428b-9d83-c6e4b9012ca5.html","toVersionName":"3.0.40","link":"http://cdn.awsde0-fusion.fds.api.mi-img.com/xiaoqiang/rom/ra70/miwifi_ra70_firmware_a79cd_3.0.40_INT.bin","description":"","weight":"1","upgradeId":"13930","hash":"87e950e9b8bdc97b3a45fadd659a79cd","toVersion":"3.0.40"}}
1 Like
Looks like that one has updated QSDK and WIFI FW as its using 2.4 instead of 2.3 and the BDF is updated.