OpenWrt support for Xiaomi AX9000

TempestJunior · 2023-07-30T11:05:14.321Z

I wouldn't be surprised with your observation.

I run 2 of these devices as AP, IoT radio never worked on one despite flashing same fw on both. An attempt to start IoT radio forces the router to restart.

On stock fw, IoT radio seems to be okay on both.

scr4tchy · 2023-07-30T16:48:30.808Z

Same with the latest snapshot. Raise it there to gain attention. Snapsbot worked well last week, no longer the case.

RobertP · 2023-07-30T18:38:43.002Z

It was working for me until I upgraded
The only difference, compared to the default image was: I used other firmware (ath10k-firmware-qca9887-ct-full-htt instead of ath10k-firmware-qca9887-ct)
@scr4tchy

robimarko · 2023-07-31T10:01:23.803Z

Well, I am following the issues but this one made it seem like it's a generic issue rather than an IPQ807x one.
It's not a generic issue but rather a PCI driver issue in the recent 6.1 point release due to the:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/pci/controller/dwc/pcie-qcom.c?h=v6.1.42&id=db962c7a711c3393a80a18219960cd54fb33c53d

There is a pending fix upstream that fixes the issue:
https://patchwork.kernel.org/project/linux-arm-msm/patch/20230724063429.3980462-1-quic_srichara@quicinc.com/

Il probably make a PR to add the patch until it gets backported upstream to 6.1 stable.

Please give this PR a go:

github.com/openwrt/openwrt

qualcommax: ipq807x: fix Gen2 PCIe port

openwrt:main ← robimarko:ipq807x-pcie-fix

opened 10:19AM - 31 Jul 23 UTC

robimarko

+44 -0

Gen2 PCIe port recently got broken on IPQ807x during update to 6.1.39 as upstrea…m backported: ("PCI: qcom: Remove PCIE20_ prefix from register definitions") [1] So, fix it by adding a pending upstream fix for it [2]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/pci/controller/dwc/pcie-qcom.c?h=v6.1.39&id=db962c7a711c3393a80a18219960cd54fb33c53d [2] https://patchwork.kernel.org/project/linux-arm-msm/patch/20230724063429.3980462-1-quic_srichara@quicinc.com/ Fixes: fec22f8375b4 ("kernel: bump 6.1 to 6.1.39")

seemebreakthis · 2023-08-01T13:51:39.399Z

Regarding your flash issue, wiki says to use squashfs but you need to use the initramfs image and then after successfully booted in, do a sysupgrade to commit to flash.

Lucky I came across this comment before doing anything, I just bought the AX9000 and avoided trouble by flashing https://downloads.openwrt.org/releases/23.05.0-rc2/targets/ipq807x/generic/openwrt-23.05.0-rc2-ipq807x-generic-xiaomi_ax9000-initramfs-factory.ubi instead of squashfs. Now successfully booted into OpenWrt.

(EDIT: I updated the Wiki to change squashfs to initramfs)

(Note: My AX9000 is a Chinese firmware model)

A couple of questions though after I logged into LuCI for the first time:

̶1̶.̶ ̶ ̶I̶n̶ ̶L̶u̶C̶I̶ ̶I̶ ̶a̶m̶ ̶n̶o̶t̶ ̶s̶e̶e̶i̶n̶g̶ ̶a̶n̶y̶ ̶w̶i̶r̶e̶l̶e̶s̶s̶ ̶i̶n̶t̶e̶r̶f̶a̶c̶e̶?̶ (Edit: Nevermind, after flashing the sysupgrade .bin file the wireless interfaces all show up)
2. The Wiki says if you want to flash both partitions with OpenWrt, you have to following this procedure after booting into OpenWrt:

Find the rootfs and rootfs_1 mtd indexes respectively again:
cat /proc/mtd

Please confirm if mtd20 and mtd21 are the correct indexes from above

If fw_printenv flag_boot_rootfs returns 0:
ubiformat /dev/mtd21 -y -f /tmp/openwrt-ipq807x-generic-xiaomi_ax9000-squashfs-factory.ubi && fw_setenv flag_boot_rootfs 1 && fw_setenv flag_last_success 1

Otherwise:
ubiformat /dev/mtd20 -y -f /tmp/openwrt-ipq807x-generic-xiaomi_ax9000-squashfs-factory.ubi && fw_setenv flag_boot_rootfs 0 && fw_setenv flag_last_success 0

But the cat /proc/mtd command returns the following:

mtd20: 03800000 00020000 "ubi_kernel"
mtd21: 0b680000 00020000 "rootfs"

I do not see any rootfs_1 anywhere.

So is it still safe to flash to mtd20...??? Or should I not continue with flashing the other partition?

scr4tchy · 2023-08-01T16:58:49.947Z

After first boot on initramfs, you can run:

uci set system.@system[0].compat_version="1.0"
uci commit system
cd /tmp
wget https://downloads.openwrt.org/releases/23.05.0-rc2/targets/ipq807x/generic/openwrt-23.05.0-rc2-ipq807x-generic-xiaomi_ax9000-squashfs-sysupgrade.bin
sysupgrade -n -p -F openwrt-23.05.0-rc2-ipq807x-generic-xiaomi_ax9000-squashfs-sysupgrade.bin

seemebreakthis · 2023-08-01T21:58:20.585Z

Yeah did that already, does this mean both partitions now contain Openwrt instead of stock firmware?

Edit: The answer seems to be 'YES'. Before running @scr4tchy's code, I can boot back to stock firmware by doing this:

fw_setenv flag_boot_rootfs 0 && fw_setenv flag_last_success 0 && reboot

But after running, I can no longer do so. Setting flag_boot_rootfs to either 0 or 1 will still get me back to Openwrt.

seemebreakthis · 2023-08-02T06:10:39.333Z

3rd day into owning my new AX9000 router, and have been making progress after glancing through the wiki and some of the more recent comments in this post.

Using 23.05.0-rc2 right now. Have applied the "BDF" patch. Have two questions / issues:

First I am seeing 4 radios instead of 3:

Screenshot 2023-08-02 1402161432×934 218 KB

Radio1 doesn't seem to work at all. The other 3 radio are emitting signals. So I just deleted the SSID for radio1 before taking the snapshot. My question is - is having 4 radios there normal?

(Edit: The 2nd question has been deleted entirely. It turned out to be a problem specific to the device I was using to test the router. So leaving the question here would only serve to confuse others)

seemebreakthis · 2023-08-02T06:26:20.066Z

Hi, I am going down the same path of getting a new ax9000 to run Openwrt. Basically try this and see if it works for you (note I have a Chinese version of ax9000 so YMMV especially if you own an international version)

Wiki seems to be a pretty good guide. I followed it and got pretty far in my setup process with that alone.
Use 23.05.0-rc2 initramfs to do the first move from stock firmware to Openwrt, then follow this by @scr4tchy to install the version of firmware you will be using going forward.
Apply the "BDF" patch mentioned in Wiki to get Radio3 to work

That's pretty much it. I am still struggling with some strange issues so take my advice with a grain of salt, but eventually I will aim to get my AX9000 routers to work with a wirless mesh backbone, and 2.4G/5G all lumped under the same network with DAWN and 802.11r running to kick clients to the strongest signal....

RobertP · 2023-08-02T12:26:06.770Z

seemebreakthis:

First I am seeing 4 radios instead of 3:

That is correct, but take a look at radio0 - it is an IoT AC/Wifi 5 wireless
Some people keep it enabled, some disable it - it is up to you and your circumstances (additionally you can change its operating band 2.4GHz/5GHz)
Three other radios are **AX/Wifi 6 **
radio1 is "an upper half" 5Ghz AX/Wifi 6 device (sorry for simplification but effectively it means you can use channels 100 or higher)
radio2 is a 2.4Ghz AX/Wifi 6 device
radio3 is "a lower half" 5Ghz AX/Wifi 6 device (available channels 32-68; with the BDF hack this device shows upper channels as well, but it is not recommended and I never managed to bring this device with higher band channel )

seemebreakthis:

but with this router I am running into a strange problem where there is only 'one way traffic' - I can ping from the router to the wireless device, but not the other way around.

This might depend on how your OpenWRT Firewall is configured (enabled or not masquerading, input/output/forward or ... simply connected LAN/WAN socket)

RobertP · 2023-08-02T14:09:24.669Z

Thanks for the PR - problem now is solved

seemebreakthis · 2023-08-02T16:43:42.942Z

"RobertP:

That is correct, but take a look at radio0 - it is an IoT AC/Wifi 5 wireless
Some people keep it enabled, some disable it - it is up to you and your circumstances (additionally you can change its operating band 2.4GHz/5GHz)
Three other radios are **AX/Wifi 6 **
radio1 is "an upper half" 5Ghz AX/Wifi 6 device (sorry for simplification but effectively it means you can use channels 100 or higher)
radio2 is a 2.4Ghz AX/Wifi 6 device
radio3 is "a lower half" 5Ghz AX/Wifi 6 device (available channels 32-68; with the BDF hack this device shows upper channels as well, but it is not recommended and I never managed to bring this device with higher band channel )

Thanks for the info ! I did not even realize there is a 4th radio for IoT on this device !

With your information I tested radio1 once again. It seems I could only activate it properly when I set the channel width to be 80MHz, and the available channels (as seen on LuCI anyway) only goes between 149 and 165. Is this supposed to be the case? Or is there any trick to configuring 160MHz?
For radio 3, I can set it to 160MHz when I set the channel to 60 for instance.

Country is already set to 'US' for all radios. I think one of the comments said you need to set the country to 'US' for each of the radios before they will work. Am I right?

"RobertP:

This might depend on how your OpenWRT Firewall is configured (enabled or not masquerading, input/output/forward or ... simply connected LAN/WAN socket)

Sorry to have wasted your time there... turned out to be a problem specific to my wireless client. Nothing to do with the router. Now solved.

RobertP · 2023-08-02T17:33:36.260Z

as far as I remember you have a choice, with the US country:

80 MHz channel width, but with more txpower (If I remember correctly 30 dBm)
160 MHz channel width, but will relatively less transmitting power (24 or 23 dBm)
=========
Edit - I was wrong
You can run 160 MHz channel width on the channel 44 with the 30 dBm (when country = US)

rdlvm · 2023-08-03T12:20:44.211Z

How can this solution be applied manually to an already created build? thank you.

robimarko · 2023-08-03T12:28:08.692Z

It cannot, you either gotta rebuild yourself or just use an updated snapshot

seemebreakthis · 2023-08-03T12:31:39.714Z

Just to report back on the configurations that I can have with my AX9000. If something better can be attained, please let me know. (country code set to 'US' for all 4 radios)

Radio 0: AC, 80MHz width max, all channels available from 36 to 165 including the radar detection channels. For a list of maximum dBm on each channel refer to iw phy0 info. Varies from 23 to 30dBm.
Edit: Set it to "N" mode, and it becomes 2.4GHz with channels 1 to 11 available @ 40MHz channel width. 30dBm.
Edit 2: If you want to use the radar detection channels, better set 'channel' to 'auto', and 'channels' to '100-144' ('channels' only settable via uci or changing the wireless config file directly). Reason being it will detect unused radar channel before determining and activating an appropriate channel. You risk not having the radio at all if you don't do it like this.
Edit 3: "N" and "Legacy" mode both don't seem to be stable. See my update in one of the more recent comments by scrolling down.

Radio 1: AX, 80MHz width max (the 160MHz selection simply doesn't work), choice of channel 149, 153,157, and 161 (others don't work), 30dBm.

Radio 2: AX, 40MHz width max, all 11 channels available (from 1 to 11), 30dBm.

Radio 3: AX, 160MHz width max, channels 36 - 60 are available. 24dBm, but at least channel 44 will give you 30dBm like @RobertP said above. NOTE: takes a few minutes for radio to be up after configuration.

rdlvm · 2023-08-03T13:01:03.294Z

thanks, works fine.

seemebreakthis · 2023-08-03T17:17:15.947Z

scr4tchy:

The AX9000 has been stable for me, except for the fact that I cannot use 160MHz even with the patched BDF, and the fact that hardware offloading using the two dedicated NPUs is not supported.

Do you still enable software flow offloading? Will it still improve throughput somewhat?

scr4tchy · 2023-08-03T18:14:41.032Z

Hey! I've fixed the 160MHz radio3 by patching hostapd.. and NSS offloading you've gotta use this build, but it's mostly helpful on 10G ports - probably the 2.5G port too.. and it would be a big help to the 160MHz radio but wifi offloading is not supported atm in that build.

RobertP · 2023-08-04T10:34:46.221Z

Do you mind sharing the mentioned hostapd patch?
Or maybe even creating a PR for ipq807x?
Regarding NSS offloading, and its current shape & form, apparently there is 0% chance to get this merged into openWRT master, so you would need to keep it yourself.
However, there is much smaller need to have NSS offloading (compared to older devices like ipq806x), at least until a next wave of broadband speeds upgrades...
Having said that @robimarko had some ideas how to achieve this in a mergable-to-openwrt-master form and shape Probably it is still waiting for his free time?