OpenWrt support for Xiaomi AX9000

yep the error is the same according to what firefox sees could be something not right with the location header.

the proxy maybe on the right track will have another go tonight.
tweaking maybe an issue will see.

Hi All,
My defective AX3600 has been replaced by an AX9000 and although I am glad to have received a model upgrade this makes it very difficult to install OpenWrt.
So is there any way to install it without having to open the router enclosure and void the warranty?
Better to sell it and aim for another model?

Thanks in advance.

Check this post for a non-invasive solution to access the UART through the underside grill.

1 Like

Thanks a lot!
Unfortunately i've already bricked the AX9000, led on top are orange and 2.5G Wan fixed green, tried to restart it with reset button press don't do anything, any way to restore stock firmware with UART?

Unless you managed to enable the UART RX then you won't be able to do anything other than read what's happening. Still would be a good idea to get a 1.8v UART adapter assuming you don't have one already and are still planning to run OpenWRT on this.

You can try the miwifi repair tool which hopefully can unbrick it.

Try the ax3600 wiki for the reset debrick method if uboot is ok it should work.

the file name is the same.

just found out there is a limit on new users in posts............

is there a way of changing the bdata file?

When i ran the exploit in mine i changed the region i think thats my issue.

the instruction i was following said it dosnt matter maybe it does.

Dont have a working password.

How ever i have a working serial connection. The exploit did do its job .

Im using a pl2303 that is supposed to do 1.8 the jumpers are for 5v or 3.3. No jumper it uses the target board for power in this case 1.8v but all 4 wires are connected.......

just need to get openwrt in safely.


Many thanks to everyone who has contributed to converting this router to openwrt.

the ax9000 global is running good here.

Thank you.

1 Like

I have been able to install OpenWrt SNAPSHOT (r23375-cdfcac6e24) in the ax9000 global version using the needles method not opening the case, thanks a lot to @rdlvm for the great contribution.

Just some notes on the process that can help someone trying to do the same:

  1. Uploading the 1.bin, 2.bin and 3.bin files through the stock UI manual update gave me an "Couldn't update. An error occured or router storage is full" error in the UI and router restarted, but it worked, it seems event the UI shows this error the update completely worked.

  2. According to the wiki, a 1.8V UART is needed. I recommend to use It. I neither recommend what I did nor I take responsibility of anyone breaking his device for doing the same. I have no idea if this will work on another device, but in my case, I decided to take the risk and used a 3.3V UART connected to the device and I was able to successfully connect and trigger the tftp for u-boot.

Also I want to highlight some points they don't seem stable enough:

  1. I have not been able to make radio1 (IPQ8074 on 5.8GHz band) on 160Mhz with any combination. Do you know if it's possible to make it work on 160Mhz somehow? Or is it ax9000 limited to 80Mhz by design?

  2. Also radio1 cannot start neither on 40Mhz or 80Mhz if I configure my country 'ES', I need to switch to 'US' country to make it work. As far as I know is completely fine to emit on both 40Mhz or 80Mhz using channels here. And I'd swear Xiaomi stock firmware allowed it (I need to check to be sure). This are the logs I can see when I try to run it with 'ES' country code:

     Wed Nov 29 01:09:10 2023 daemon.notice hostapd: phy1-ap0: interface state UNINITIALIZED->COUNTRY_UPDATE
     Wed Nov 29 01:09:10 2023 daemon.notice hostapd: ACS: Automatic channel selection started, this may take a bit
     Wed Nov 29 01:09:10 2023 daemon.err hostapd: ACS: No available channels found
     Wed Nov 29 01:09:10 2023 daemon.warn hostapd: phy1-ap0: IEEE 802.11 Configured channel (0) or frequency (0) (secondary_channel=1) not found from the channel list of the current mode (2) IEEE 802.11a
     Wed Nov 29 01:09:10 2023 daemon.warn hostapd: phy1-ap0: IEEE 802.11 Hardware does not support configured channel
     Wed Nov 29 01:09:10 2023 daemon.err hostapd: Could not select hw_mode and channel. (-3)
     Wed Nov 29 01:09:10 2023 daemon.notice hostapd: phy1-ap0: interface state COUNTRY_UPDATE->DISABLED
     Wed Nov 29 01:09:10 2023 daemon.notice hostapd: phy1-ap0: AP-DISABLED
     Wed Nov 29 01:09:10 2023 daemon.err hostapd: phy1-ap0: Unable to setup interface.
     Wed Nov 29 01:09:10 2023 daemon.notice hostapd: nl80211: deinit ifname=phy1-ap0 disabled_11b_rates=0
     Wed Nov 29 01:09:10 2023 kernel: [105421.607743] device phy1-ap0 left promiscuous mode
     Wed Nov 29 01:09:10 2023 kernel: [105421.610791] br-lan: port 9(phy1-ap0) entered disabled state
     Wed Nov 29 01:09:10 2023 daemon.err hostapd: rmdir[ctrl_interface=/var/run/hostapd]: Permission denied
     Wed Nov 29 01:09:10 2023 daemon.notice hostapd: phy1-ap0: CTRL-EVENT-TERMINATING
     Wed Nov 29 01:09:10 2023 daemon.err hostapd: hostapd_free_hapd_data: Interface phy1-ap0 wasn't started
     Wed Nov 29 01:09:10 2023 daemon.notice netifd: radio1 (18496): Command failed: ubus call hostapd config_add {"iface":"phy1-ap0", "config":"/var/run/hostapd-phy1.conf"} (Invalid argument)
  3. For some reason radio1 and radio3 (the two 5Ghz bands) don't work if I don't manually specify option band '5g' on /etc/config/wireless. But LUCI keeps insisting in removing that option everytime I edit the configuration on the UI and I need to manually add it again.

    (Update: It seems this was happening because I was using an old snapshot version, with latest stable 23.05.2 this seems to be fixed)

  4. I don't fully understand What's the problem with QCN9024 (radio3) BDF, What is blocking merging the fixed version into stable release? Any possible solution we can work on?

Probably this is an engineering version (received under a NDA?)
But there is a simple trick - replace the file once and then add the following line to your Luci->System->Backup/Flash->Configuration:
This way this file will be preserved when upgrading firmware

The same with the UK - looks like driver/firmware was only tested and only works with US

The same here - Although if I am not mistaken someone a few weeks ago posted in this very thread links to a Github tool to make BDF changes and recons that after changing the BDF content he was able to get 160 MHz channel width on the higher 5Ghz band