Adding OpenWrt support for Xiaomi AX3600 (Part 1)

I'm running the latest build (own build) for a few days now with kind a "normal" setup without any issues in terms of crash or speed issues. But I only have a 250 MBit line and I have the router from my service provider in front. So no heavy burden in terms of cpu usage (like gigabit or pppoe).

setup:

  • 2 networks vlan aware.
  • 2 wifi ssids for each band (QCA9887 disabled), wpa3 only (each connected to its own vlan aware network).
  • for the wifi I've enabled 802.11r including band steering (plain without usteer and only for the ap itself not interacting with other aps). working good with my phones.
  • irqbalance (with proper assignment) and packet steering enabled.
  • cpu scaling govenor "ondemand". my personal (subjective) impression is it's running more responsive compared to shedutil.
  • main test devices (wpa3 only): samsung s20 (ac/ax, the phone is undecided sometimes), xiaomi m10t pro (ax every time), notebook with intel ac-9260 (ac only, linux machine no windows tested).

Big thanks and compliment to the developers here!

One thing I've observed is that if I connect e. g. an older switch 100MBps only to a lan port the autosensing (or what ever) is not working properly. This problem I've observed with the stock firmware (xiaomi) in the past also (with 2 different ax3600 devices now). The switch is working on other gigabit routers flawlessly. So it might be the hardware itself.

@K900 @Crect

At the moment, there is a suspect in regards of the AX6.

Every other unit (AX3600, AX6000, AX9000, Dynalink) has exactly the same front end module (FEM), except the AX6. I have no data about the QNAP 301w, if someone want to help, please take high res pictures of the Wifi area of the board, so we can confirm what FEMs they use.

Skyworks SKY85347 + SKY85755.

(That site can be snail slow to load sometimes, but they do high-res photos of teardowns.)

QNAP 301w details:

SKY85347-11 + SKY85755-11 FEM

Thanks! Did someone confirmed that the 301W and FW 2.7 does work together?

If it does, please send me the BDF and the CAL file.

I did not, maybe it's better to ask in the QNAP thread:

https://forum.openwrt.org/t/adding-openwrt-support-for-qnap-qhora-301w/

301W works with 2.7 like described.
Will send you BDF and caldata

2 Likes

just curious ... what are these SKY FEM chips for?

They are RF amplifiers

1 Like

bloody hell ! sorry for the rant :wink: and these chips are messing the latest firmware load !? what a big load of spaghetti code shit qualcomm is ! again sorry for the rant

Nobody knows yet, do not draw conclusions yet

1 Like

i totally missed this... there is a possibility the new fw doesn't support the rf amplifier o.o

Doubt it, that would be crazy even for QCA

If you look at the block diagrams for these front end modules, they are almost drop in replacements to each other, there are enable and bypass pinsplus a power detector part for power control and that is it. Actually I wanted to upgrade my AX6 with a better front end module, but the physical layout is different, although the pins are the same. I dont think these chips need any kind of "support" from the firmware.

Morning all, @robimarko i applied your ipq807x-5.15-pr-regdb repo against the dynalink and no issues found both with the WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICON and the regdb patch

I am going ahead and apply the same against the qnap

thank you

all fine with the qnap as well (apart from /lib/firmware/ath11k/IPQ8074/hw2.0/regdb.bin missing)

I copied a regdb from /qca/src/upstream-boardfile/ath12k-bdf-regdb/QCN9274/hw1.0/WLAN.WBE.1.0.r4/WLAN.WBE.1.0.r4-00118-QCAHKSWPL_SILICONZ-1/regdb.bin

and

iw reg get (for HU) unsure if the below looks good

global
country HU: DFS-ETSI
(2400 - 2483 @ 40), (N/A, 20), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
(5725 - 5875 @ 80), (N/A, 13), (N/A)
(5945 - 6425 @ 160), (N/A, 23), (N/A), NO-OUTDOOR
(57000 - 66000 @ 2160), (N/A, 40), (N/A)

phy#1 (self-managed)
country HU: DFS-ETSI
(2402 - 2472 @ 40), (N/A, 20), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5490 - 5590 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW
(5590 - 5650 @ 40), (N/A, 24), (600000 ms), DFS, AUTO-BW
(5650 - 5710 @ 40), (N/A, 24), (0 ms), DFS, AUTO-BW

phy#0 (self-managed)
country HU: DFS-ETSI
(2402 - 2472 @ 40), (N/A, 20), (N/A)
(5170 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
(5250 - 5330 @ 80), (N/A, 23), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
(5490 - 5590 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW
(5590 - 5650 @ 40), (N/A, 24), (600000 ms), DFS, AUTO-BW
(5650 - 5710 @ 40), (N/A, 24), (0 ms), DFS, AUTO-BW

And it wont chnage anything as BDF needs changes and you need the appropriate regdb.bin

1 Like

@kirdes Do you maybe have the branch with working nss-drv around?

Yes give the a moment....

Just WIP