For the BSS survey warning, it looks to be timing out waiting for WMI_PDEV_BSS_CHAN_INFO_REQUEST_CMDID to come back via ath11k_pdev_bss_chan_info_event
I'm unsure if it's simply that we need to wait longer or more likely something broken ion the other side of WMI.
Does the same happen with CN set as the reg domain ? Won't have access to my device for a day or so now.
Yeah, it never reiceves the reply from FW about the BSS survey or basically background noise scan.
I doubt that the timeout is too small, it probably fails internally or something like that.
CN is set in their NVRAM which is a legacy thing that ath11k has no idea about, I can try setting the reg domain to CN via iw tommorow, but it will be so weird if thats the issue.
I just hope that there isnt magic GPIO for a RX filter or something like that hardcoded into the driver?
Ansuel
1446
hardcoded stuff in the firmware? and bss fails if it does detect a wrong reg? (and you already write my fear)
If we only had GPL sources of the thing, this kind of stuff would usually have comments like breadcrumbs for some magical workaround.
Also, it would be awesome to see whether the international FW ships with the same BDF.
Anybody have a link to that FW so I can extract it and try flashing?
Also, @Ansuel if you have some time can you try scanning with iw or iwinfo for AP-s from the AX3600?
As I have feeling that the issue is on RX end as TX output power is really good.
Ansuel
1448
there was a link let me use the search link. Could be that all these problem are related to cn rules being enforced?
Ansuel
1449
I mean the QSDK builds seemed to function OK for WiFi without extra patches (other than broken PCIE for the extra radio)
I doubt it's related to a missing patch from xiaomi
Could well be some FW incompatibility tho, but it's hard to test.
@Ansuel I meant scanning using iw or iwinfo on the AX3600 itself to see whether the RSSI matches that seen by a phone or a notebook next to it.
@Apache14 Honestly, I hope that it does not require some magical fixes for Xiaomi as well.
PCIE was most likely not working as AC04 reference board uses a different reset GPIO for PCIE from AX3600
Just compared the 292 board ID BDF-s and they are different as MD5 hash differs.
Chinese 1.1.15: f6f870569b712ba49663e0a8330b7287
International 3.0.22: 4964e64c87fbe5d9fb8963df80af5303
In both versions they are using ancient WLAN.HK.2.0-01792-QCAHKSWPL_SILICONZ-1.242686.10 v2 firmware version.
itay
1452
There is a major time difference between 1.1.15 and 3.0.22 release. Maybe they got some patches in this time. I think comparing with chinese 1.0.67 will give more accurate answer
https://cdn.cnbj1.fds.api.mi-img.com/xiaoqiang/rom/r3600/miwifi_r3600_firmware_f7f3e_1.0.67.bin
Ansuel
1453
is 3.0.22 the latest int firmware?
itay
1454
Yes. But it was released very long time ago
Anybody got a link to 1.0.67?
I maybe have it somewhere on my desktop, but I am now on my notebook
itay
1456
That one again has a different BDF used with MD5: 131dcb827df00c0af5685d1e003a213f
I am looking at the QCA ath11k BDF repo, and it could be that 292 was in hex like in the DTS so it would be 658 in decimal as that thing exists in their board-2.bin.
Since we are kind of hitting the wall, I can try using that BDF instead of the one shipped in the stock FW.
Also, they are sorted per ath11k FW version in the repo?
1 Like
Ansuel
1458
anyway about the wifi scan... windows reports very minimal stats and it's a bit late to run a live disto... will provide it tomorrow sorry
@robimarko random idea since the nss driver is what is needed and nothing about their part... a random driver that only load the drv shouldn't be too hard to write... could be an idea to try to have this usable and be accepted by openwrt... (but now that i think about this... we still have the problem with ssdk)
Honestly, no point in rewriting since there is dependency on NSS-DP and SSDK as well
Ansuel
1460
you are right... propose the support of the qca package on openwrt will be very hard IMHO
at least the kernel doesn't need to be patched like it's needed for something like ecm
I have hope as without it there will be no support for IPQ807x, IPQ60xx and probably for IPQ50xx as well.
And not having those means not supporting a large portion of 802.11ax boards, and since a rather small amount of kernel patching is required I see no point in refusing these.
Ansuel
1462
we just need to present them in a good way 