Adding OpenWrt support for Xiaomi AX3600 (Part 1)

They did not document it, but I looked at the board-2.bin with a hex editor.
You can clearly read the board-id= in ASCII

Good point, the dmesg from your device shows board_id as 0xff ? (but that is pre loading caldata) so may be normal.

Edit : that is the same as what we used to see on 5.4

I added a print to here https://elixir.bootlin.com/linux/latest/source/drivers/net/wireless/ath/ath11k/core.c#L53

And we get:
boot using board name bus=ahb,qmi-chip-id=0,qmi-board-id=255

There was no need for this as 0xff=255

Like I said, that should be incorrect as stock FW prints:

[   31.970892] cnss: QMI WLFW service connected, state: 0x1
[   31.978748] cnss: device_id : 0xfffe mem mode : [1]
[   31.999096] cnss: Boardid from dts:292,FW:ff
[   32.006861] cnss: BDF location : 0x000000004b0c0000
[   32.006889] cnss: BDF IPQ8074/bdwlan.b292 size 131072
[   32.012648] cnss: BDF download response , result: 0, err: 0x0
[   32.016117] cnss: per device BDF location : 0x000000004b0e0000
[   32.023348] cnss: CALDATA IPQ8074/caldata.bin size 131072 offset 0x20000
[   32.029452] cnss: BDF download response , result: 0, err: 0x0

Ohh woow and that is in board-2 ... nice

Ahh dam, sorry i didn't see what you where saying (its probably not detecting the board-id correctly, but just so happens to be in board-2.bin)

Been a long week for me :smiley:

I guess the AX3600 may be missing the board id burned onto on the wifi hw and its just reporting some defaults. (and qcom added 255 to the upstream firmware to add some basic support for this)

Possibly, as they poll the FW usign QMI for the ID.

Does the ath11k radio work with your current tree ? (i could never get a station to come up + no VHT support listed regardless of the board file used)

Haven't tried it.
I only have one notebook with 802.11ax support and no smartphones that support it so I can't really test it properly, even worse I have really limited time to work on this.
But I tested the VHT80 ac mode and it simply throws every ten seconds:
ath11k c000000.wifi: bss channel survey timed out

I also tested the older 2.1.0.1 FW but it has the same issue, AP does not work at all.

Also, OpenWrt is currently using kernel 5.8 wireless drivers, for ath11k that is really old.

I added support for PDM9655 PMIC regulators and SPMI.
These will be needed later for scaling, UBI cores as well as SD/eMMC support.

Unfortunately, I will be having much less time in the following days so any help with the massive amounts of work needed for IPQ807x would be great.

1 Like

I should have more time Friday and over the weekend.

Last time I checked mainline ath11k it had exactly the same issue. But it could scan and list local ssid

Not really sure how to debug that but I'll give if a go.

Thanks.
I mean it makes no sense to see the amount of work on ath11k and for it not have a working AP.
If they only had some docs.

I mean, even in the PR for ath11k they wrote that it support AP, mesh and station modes.

It's could always be this HW that's slightly odd but it should be supported.

Its a shame there isn't much more accessible ipq807X hardware around to validate on (better yet a development board)

I dont think that its odd, its basically AC01 reference board.

I have been trying to get a HK01 development board, but I cant get it at work and its way too expensive for me.
Heck, every other IPQ807x board is too expensive for me.

Ok, I tested and confirmed that we need the board.bin from the stock FW for the QCA9889 radio.
Otherwise, it advertises the 5G band which it cant do.

UPDATE: Misinformation from my side, it still advertises both bands even after I packaged the board.bin
So, this thing could be potentially usefull.
As far as I can tell the stock FW also advertises both bands for it.

I also gave the ath11k radios a go, and with the board file pulled from stock FW it will start a AP and broadcast it with NOHT htmode

11 Likes

Thanks for checking the ath11k radios with the stock board file, I have tested the same this morning. At lest ath11k seems to be working as expected.

I will have a look around for the eth / switch drivers, unsure if any work has happened upstream for that.

Will also have a look at the warning around gcc_usb1_master_clk (that has been on every non qcom kernel I have seen)

EDIT: odd to see VHT seems to be disabled / not detected, don't think this is a reg issue tho

From iw list
Supported Channel Width: neither 160 nor 80+80
VHT TX highest supported: 0 Mbps

1 Like

Yeah, I think I said that it only works with NOHT as VHT is not advertised at all.
Even though it kind of works in non HT legacy channels its not correct as it constantly throws BSS survey errors.
So its either a bug in ath11k as ID-s it reads are really weird or some other combination of issues.
I would personally love to try this on 5.10 instead of 5.8 WLAN driver stack.

I think that those USB clocks cant be disabled from SW, I took a look at QCA driver and they have some kind of HW_MANAGED flags on that AHB master clock writing that RGCR is not SW controllable.
This flag does not exist upstream, I dont think that those warnings really matter as USB clocks being on really dont conflict with anything.

1 Like

@robimarko sorry for OT... You said you are using usb to ttl serial with no selector for 1.8v. (I think we have the same adapter that have only 3.3 and 5v (pcb red)). Could you confirm that I can use it for the ax3600 without any additional device?

Yes, I am using a red FT232RL based clone with nothing else but voltage set to 3.3V using the jumper.

1 Like

Anyway brought the router.. will join the party asap ahahha (estimated ship 16 nov)

2 Likes

Awesome, we really need some help as this is all test and trial.
Heck, we dont even have CPU scaling supported as that requires another set of regulator drivers and PLL clock driver(This one should be easy)

1 Like