OpenWrt support for Xiaomi AX9000

well...read the community thread & this forum.. the ax9000 doesn't behave with any other nss pbuf profile than 500mb... due to the three radios the pci and ahb have limited frequencies (pci lower 5ghz and ahb higher).

I think with all the info around you will do well and of course the community support :wink:

At the very top of this thread you can see Robi's info - maybe one of the outstanding topics could be your cadidate?

PS
I fully agree AX9000 is a great device, even without NSS which in the current form and shape will probably never be merged into the official OpenWRT release

Hello guys! Could anyone please update https://openwrt.org/toh/xiaomi/ax9000#potential_issueslimitations section with fresh entire command link in the lower 5 GHz band radio issue subsection?
Looks like current link is not working anymore. Cant find this instructions elsewhere.

@rmandrad just to check, which other values have you tried? I was just doing some data collection on the official firmware 3.0.40, it seems that there's a significant deadzone in the higher values. The fan starts working with PWM duty cycle set to 13. 0-12 does not enable the fan, but the RPM reading is always at least 960. From 13 to around 25 the RPM reading is not too reliable, with reported speed fluctuating slightly above 960.
Setting the duty cycle to 164 or more sets the fan to the maximum (reported) speed of around 3310 RPM. Anything above that won't affect the fan speed anymore.

As for the fan control binary (/usr/sbin/mitempcontrol), it uses the /usr/sbin/fancycle script to set the duty cycle to one of the 21 states based on the temperature reading. It's triggered by crontab every 3 minutes (seems like a very rough fan control granularity, at least temporally). 61 deg. C or more is the first step, from 0 to 1, which writes 13 to /sys/devices/platform/soc/78ba000.i2c/i2c-1/1-002f/pwm1 (i2cset is not used).

Step 13 (duty cycle 166) already sets the fan to the highest speed, so I'm not sure if they're using the rest of the PWM range just as a buffer to spin the fan at 100% for a large range of temps, or is it just lazy programming... Anyhow, it's also interesting that the max fan speed denoted in the fancycle script is 2500RPM, while the i2c chip reports 960 for disabled and 3310 for max... 3310-960=2350 so I guess it's just some reading offset... Who knows.

I still haven't built the image myself. If anyone has some time to check these vales at some point, please do.

PWM Value PWM (Hex) Fan Speed (RPM) Notes
0-12 0x00-0x0C 0 (960 reported) Fan is off, 960 RPM is a false reading
13 0x0D ~967 Minimum operational speed
14-25 0x0E-0x19 ~960 Fan running, but sensor reading is unreliable
38 0x26 1220
51 0x33 1460
63 0x3F 1670
76 0x4C 1885
89 0x59 2090
102 0x66 2286
114 0x72 2450
127 0x7F 2635
140 0x8C 2800
153 0x99 2974
162 0xA2 ~3196
163 0xA3 ~3292
164 0xA4 ~3308 Maximum effective speed
165-255 0xA5-0xFF ~3308 No further increase in speed

/usr/sbin/fancycle:

#!/bin/sh

# EMC2301, connected to GSBI1 I2C
HWMON_SYSFS=/sys/devices/platform/soc/78ba000.i2c/i2c-1/1-002f
MAXRPM=2500

if [ "$#" -ne 1 ]; then
	echo "error param"
	exit 255
fi

if [ ! -d $HWMON_SYSFS/hwmon ]; then
	echo "Fan controller is not present."
	exit 1
fi

case $1 in
	[0-9]*)
		if [ $1 -gt 20 ]; then
			echo "fan cycle 0-20"
			exit 255
		fi
		;;
	*)
		echo "fan cycle 0-20"
		exit 255
		;;
esac
duty5p=$1
echo 1 > $HWMON_SYSFS/pwm1_enable
echo $((255 * duty5p / 20)) > $HWMON_SYSFS/pwm1
echo "fan cycle - $((duty5p * MAXRPM / 20))" >&2

Some analysis of mitempcontrol based on strings /usr/sbin/mitempcontrol (probably not fully accurate):

  1. Libraries and Dependencies:

    • Uses musl libc
    • Links against libgcc_s.so.1 and libc.so
    • Compiled with GCC 5.5.0 for OpenWrt
  2. Standard C Functions Used:

    • File operations: fopen, fclose, fgets
    • String operations: strcat, sscanf, sprintf
    • Process operations: popen, pclose
    • Error handling: perror
    • Memory operations: memset
    • Other: puts, putchar, exit
  3. Fan Control:

    • Uses fancycle command
    • Reads fan speed: cat /sys/devices/platform/soc/78ba000.i2c/i2c-1/1-002f/fan1_input
    • Sets fan speed: echo %d > /sys/devices/platform/soc/78ba000.i2c/i2c-1/1-002f/pwm1
  4. Temperature Monitoring:

    • WiFi: Uses thermaltool for WiFi chips (wifi0, wifi1, wifi2)
    • CPU: Reads from thermal zones 4, 5, and 6
      cat /sys/devices/virtual/thermal/thermal_zone[4-6]/temp
  5. Configuration:

    • Uses a configuration file: /tmp/mitempcontrol.conf
    • Creates or updates: /tmp/temp_limit.conf
  6. Thermal Thresholds:

    • Sets specific thresholds for WiFi chips, e.g.:
      thermaltool -i wifi2 -set -hi0 108 -lo1 105 -hi1 113 -lo2 110 -hi2 118 -lo3 115 -hi3 123
  7. Operation Modes:

    • Checks device mode: cat /proc/xiaoqiang/ft_mode
  8. Error Handling and Logging:

    • Several status messages like "Set rotate default!", "Get wifi temperature default!", etc.
    • Error message for writing temp limit configuration
  9. Security Measures:

    • Uses stack protection (__stack_chk_fail, __stack_chk_guard)
3 Likes

@rmandrad
Why is driver kmod-hwmon-emc2305 not installed?

i haven't made default to my build ... but yes I could ...

good analysis... i spend sometime tweaking and porting what is on the rpi builds and honestly with not much knowledge of dts definitions ... but still the only way I can spin the fan is set to max ... if you anyone has knowledge pls feel free to improve the dts definitions

I'm surprised that the DTS for the AX9000 router contains so many additional options for the emc23xx driver.

Here's a quick addition of fan support for Xiaomi R3D: https://github.com/remittor-pr/openwrt/blob/r3d/target/linux/ipq806x/files-6.6/arch/arm/boot/dts/qcom/qcom-ipq8064-mi-router-hd.dts#L99-L105

And here is a utility for controlling fan speed:

3 Likes

Sorry for disturbance, script was working great for me.
Need to run it again after attended sysupgrade to latest official firmware.
Link to textbin.net is not valid anymore. Kindly ask to update link.

Kind regards,
Nikolay

1 Like

I didn't save the script, but I do have the archive: https://drive.google.com/file/d/18zqPfQMk2j6xugvtwWmetfiwcnkNChyn/view

1 Like

Thank you for sharing! Unfortunately 160MHz don't work for me with your board-2.bin on 23.05.4. None of the clients detect the network, here's my radio3 config from /etc/config/wireless:

config wifi-device 'radio3'
        option type 'mac80211'
        option path 'soc/20000000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
        option channel '44'
        option band '5g'
        option htmode 'HE160'
        option he_su_beamformee '1'
        option he_bss_color '33'
        option country 'DE'
        option cell_density '3'

As soon as I change htmode to 'HE80', it works. Any ideas?
Thanks!

Try changing your country code to US and wait for a few minutes

1 Like

Awesome, it worked! And I tried US country code before, looks like I was just being impatient, had to wait a bit :sweat_smile:

Hello!
Has anyone tried enabling Wifi 6E on the QCN9074 on AX9000?
I know this is probably a long shot, but maybe worth asking here?

https://www.reddit.com/r/homelab/comments/ymecyp/wifi_6e_softap_qcn9074_on_x86/

6 GHz is not available on this hardware, it's designed for the Chinese market, where 6 GHz is not allowed.

1 Like

I get this that 6Ghz is not allowed in China.
But given the ambiguity around fusing/board ID (0xa2 vs 0xff) and the fact it is QCN9074 after all, I am wondering if anyone has tried it?
Maybe this would work with some effort?

The ax9000 does NOT support 6 GHz, only low-band 5 GHz (ch36-64) and high-band 5 GHz (ch100-155). If you believe otherwise, the onus is on you.

1 Like

It is the QCN9024 chip, not the QCN9074: https://www.acwifi.net/13681.html

True - it is QCN9024 ...

I know - that's what I currently got :slight_smile:
But given the information that QCN9024 might be tri-band ... and what changes are needed to ath11k (board_id overrides) I am simply asking if anyone tried it?