Hi, Comi7!
I reread the entire thread and especially the posts where you installed the firmware. I'm glad you managed to do it and are now happy with the router.
I have to do this too. I already have a Xiaomi 1200 PC04 version. I connected it to the computer via a COM port and saw the traffic. The next step is editing the SPI memory. But the CH341A programmer has not arrived yet. I figured out how to fix the dump and enable boot_wait=on. But I also realized that even after this there may be difficulties.
I would be grateful to you and other forum participants for help.
What firmware are you using, having already had experience using it?
How should I fix the stock dump of my router to get a working firmware with all the additional modules?
So, I have made progress. I managed to unsolder-edit-solder the flash memory, install OpenWRT (there was a small quest, but I managed). I applied the openwrt-23.05.5-ramips-mt76x8-xiaomi_mi-ra75-initramfs-kernel firmware, and then openwrt-23.05.5-ramips-mt76x8-xiaomi_mi-ra75-squashfs-sysupgrade. The kmod-mt7663-firmware-sta and
kmod-mt7615-firmware packages are installed. But... RC04 does not assign an IP address from device 5G. The configurations are the same as device 2G.
Can anyone tell me what to do? I would be grateful for any thoughts.
Good day and good mood to all.
I managed to reflash and configure the RC04 model. It was not easy. I took the main ideas from this topic, for which special thanks to jdeisenh and tinamore.
I want to say that in my stock firmware, after editing the SPI memory, the device pauses and counts only once. If you did not flash it the first time you turned it on, you have to edit the flash memory again.
Hi,
I’m Glad that you did it.
I apologize for not responding sooner; I was unable to use my phone this week due to personal issues.
Above, I’ve provided instructions on how to stabilize the RC04 on the 5GHz band and how to enable it.
Hi, Comi7, thank you for answer!
I saw instructions on how to stabilize RC04, thanks. The router works, and as I need. But I have a question: the router assigns DHCP IP addresses not from its pool (192.168.1.ХХХ), but from the pool of the main home router (192.168.12.ХХХ). If you have the opportunity to show the Interfaces settings. I think you need to look there.
@xabolcs i have a question but its out of the topic of Mi extender ac1200 RC04.
Do you have telegram so i can contact there?
1 Like
Yes, but everything is fine for me now. Thank you.
1 Like
does mine also supports mine is different
I got the chinese model RA75 But the interface is english base on the box it produced in 2021
Hello everyone,
I managed to install openwrt on my RA75 but I have a problem that I have not been able to fix and that is that when I connect as a client to a 5G network and enable access from the same 5G network the speed is quite a bit lower... I have an RC04 with the original firmware and when I perform a speed test I exceeded 100MB/s but with the RA75 and openwrt I cannot get past 50MB/s
Is there any configuration that I should check to equalize the performance of the original fw vs openwrt???
attentive and thanks in advance,
Roman
I recently ordered what I thought was the last RA75 but got a brand new RC04 instead, took it as a call to learn more about eeprom/nand flashing and got a CH341A.
Everything worked and I hex-edited boot_wait=off to boot_wait=on, erased and wrote the flash-image back and could enter the boot command line.
However none of the different alternatives to flash worked for me and I ended up in a bootloop everytime. I could boot initramfs, but if I tried a sysupgrade from there it said something like "Operation not permitted"
I took a look at 'printenv' in the boot console:
MT7628 # printenv
bootdelay=5
baudrate=115200
ethaddr="00:AA:BB:CC:DD:10"
model=RC04
boot_wait=on
uart_en=0
ssh_en=0
telnet_en=0
flag_boot_type=2
mode=Router
wl1_radio=1
CRC=bad
flag_try_sys1_failed=1
flag_boot_rootfs=1
bootcmd=bootm
bootfile=sysupgrade_RA75.bin
autostart=no
filesize=630331
fileaddr=80100000
ipaddr=192.168.1.1
serverip=192.168.1.25
restore_defaults=1
flag_try_sys2_failed=1
flag_ota_reboot=0
stdin=serial
stdout=serial
stderr=serial
(sysupgrade_RA75.bin is what I named my sysupgrade file to)
I tried these changes:
setenv restore_defaults 0
setenv flag_try_sys1_failed 0
setenv flag_try_sys2_failed 0
saveenv
reset
And after that, OpenWRT booted and everything seems to work.
My sysupgrade was 23.05 and I have updated to 24.10 with Luci and added packages for 5GHz without a problem 
I dont know if these settings are added in newer models of RC04 or even if I had to change all three of them, but it works for me and I thought that it might be good to know for others.
can someone dump a openwrt firmware for this Xiaomi RA75 aka MiWifi Range Extender AC1200
mine got damaged the uart header now the only way I can flash it view ch341a flasher
I already desolder the winbond 25q128jvsq chip and backup the original firmware now the problem is that no one has the dump file for openwrt, so please someone, send me the dump openwrt so I can flash it
If you explain to me how to do this, I will create a corresponding dump and upload it to you (but I won't disassemble the device again).
No needed, found already that someone uploaded in here thanks for the help anyway
heres where I get it
1 Like
I had RA75 RC04 for few months. It's the cheapest wall-plug AP with RJ-45 and WiFi 5 (and kind of OpenWrt-ready) in my region. HW is ok, but configurability & user experience via Xiaomi SW / app is dreadful.
I updated my RC04 to OpenWrt using different method then what people are suggesting here (i.e. u-boot env edit and TFTP flash). Maybe this will help someone.
My RC04 HW details:
- internal power supply provides 12V - consider external power supply when playing around (safer option)
- SPI NOR is GigaDevice GD25Q128ESIG (datasheet) - in the past Winbond W25Q128BV was used
HW for alternative flashing method:
- SBC with SPI on GPIO header (I had/used BeagleBone Black) or 3.3V SPI programmer
- SOP8 clip (I bought cheapest CH341A programmer with SOP8 clip I could find on aliexpress; it arrived with CH341B IC, but doesn't it matter)
- few wires; maybe breadboard
WARNING: Pretty much all cheap CH341 programmers use 5V VCC (at least without extra modifications). This will result in 5V on digital output pins - this can fry your 3.3V flash. If you need USB programmer, then look for one with CH347.
SBC (BeagleBone Black) setup:
- put some recent Debian image on microSD (https://rcn-ee.com/rootfs/)
- add device tree overlay that enables SPI0 with partitioned NOR flash:
BB-SPI0-NOR.dtso
/dts-v1/;
/plugin/;
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/pinctrl/am33xx.h>
/*
* Helper to show loaded overlays under: /proc/device-tree/chosen/overlays/
*/
&{/chosen} {
overlays {
BB-SPI0-NOR-00A0.kernel = __TIMESTAMP__;
};
};
/*
* Free up the pins used by the cape from the pinmux helpers.
*/
&ocp {
P9_17_pinmux { status = "disabled"; }; /* P9_17 (A16) spi0_cs0.spi0_cs0 */
P9_18_pinmux { status = "disabled"; }; /* P9_18 (B16) spi0_d1.spi0_d1 */
P9_21_pinmux { status = "disabled"; }; /* P9_21 (B17) spi0_d0.spi0_d0 */
P9_22_pinmux { status = "disabled"; }; /* P9_22 (A17) spi0_sclk.spi0_sclk */
};
&am33xx_pinmux {
bb_spi0_pins: pinmux_bb_spi0_pins {
pinctrl-single,pins = <
AM33XX_PADCONF(AM335X_PIN_SPI0_SCLK, PIN_INPUT, MUX_MODE0) /* P9_22 (A17) spi0_sclk.spi0_sclk */
AM33XX_PADCONF(AM335X_PIN_SPI0_D0, PIN_INPUT, MUX_MODE0) /* P9_21 (B17) spi0_d0.spi0_d0 */
AM33XX_PADCONF(AM335X_PIN_SPI0_D1, PIN_INPUT, MUX_MODE0) /* P9_18 (B16) spi0_d1.spi0_d1 */
AM33XX_PADCONF(AM335X_PIN_SPI0_CS0, PIN_INPUT, MUX_MODE0) /* P9_17 (A16) spi0_cs0.spi0_cs0 */
>;
};
};
&spi0 {
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&bb_spi0_pins>;
flash0: flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
spi-max-frequency = <10000000>;
partitions: partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
label = "bootloader";
reg = <0x0 0x20000>;
};
partition@20000 {
label = "config";
reg = <0x20000 0x10000>;
};
partition@30000 {
label = "factory";
reg = <0x30000 0x10000>;
nvmem-layout {
compatible = "fixed-layout";
#address-cells = <1>;
#size-cells = <1>;
eeprom_factory_0: eeprom@0 {
reg = <0x0 0x400>;
};
eeprom_factory_8000: eeprom@8000 {
reg = <0x8000 0x200>;
};
macaddr_factory_4: macaddr@4 {
compatible = "mac-base";
reg = <0x4 0x6>;
#nvmem-cell-cells = <1>;
};
macaddr_factory_28: macaddr@28 {
reg = <0x28 0x6>;
};
};
};
partition@40000 {
label = "crash";
reg = <0x40000 0x10000>;
};
partition@50000 {
label = "cfg_bak";
reg = <0x50000 0x10000>;
};
partition@60000 {
label = "overlay";
reg = <0x60000 0x100000>;
};
partition@160000 {
label = "firmware";
reg = <0x160000 0xea0000>;
compatible = "denx,uimage";
};
};
};
};
- compile, install and enable in u-boot this DT overlay
- install
mtd-utilsand download OpenWrt sysupgrade image for RA75 (https://firmware-selector.openwrt.org/) - shutdown and unplug SBC power
- wiring:
HINT: my RC04 consumes ~180mA in idle when injecting 3.3V via SOP8 clip; BeagleBone can do 250mA (little headroom), so to be on a safe side I decided to use cheap CH341 programmer only as a power source (on paper it can supply up to 1A); you need to share SBC and power source GND with such setup
- SOP8 pin 1 (CS#) - BBB P9_17 (SPI0_CS0)
- SOP8 pin 2 (SO) - BBB P9_21 (SPI0_D0)
- SOP8 pin 3 (WP#) - CH341 programmer 3.3V
- SOP8 pin 4 (VSS) - BBB P9_01/P9_02 + CH341 programmer GND
- SOP8 pin 5 (SI) - BBB P9_18 (SPI0_D1)
- SOP8 pin 6 (SCLK) - BBB P9_22 (SPI0_SCLK)
- SOP8 pin 7 (HOLD#/RESET#) - CH341 programmer 3.3V
- SOP8 pin 8 (VCC) - CH341 programmer 3.3V
HINT: GD25Q128ESIG datasheet says that unused WP# and HOLD# pins should be driven high (3.3V) - not floating
- connect SOP8 clip, turn on 3.3V supply, turn on SBC
- you should get something like this in SBC
dmesg:
[ 53.451186] Creating 7 MTD partitions on "spi0.0":
[ 53.686819] 0x000000160000-0x000001000000 : "firmware"
[ 54.029133] 0x000000060000-0x000000160000 : "overlay"
[ 54.406117] 0x000000050000-0x000000060000 : "cfg_bak"
[ 54.971226] 0x000000040000-0x000000050000 : "crash"
[ 55.105114] 0x000000030000-0x000000040000 : "factory"
[ 55.193991] 0x000000020000-0x000000030000 : "config"
[ 55.325058] 0x000000000000-0x000000020000 : "bootloader"
HINT: crash partition has kernel panic logs; it wasn't empty, so stock Xiaomi SW isn't really rock solid
- firmware for some reason in first partition, so it will be
/dev/mtd0when flashing:
$ sudo mtdinfo /dev/mtd0
mtd0
Name: firmware
Type: nor
Eraseblock size: 4096 bytes, 4.0 KiB
Amount of eraseblocks: 3744 (15335424 bytes, 14.6 MiB)
Minimum input/output unit size: 1 byte
Sub-page size: 1 byte
Character device major/minor: 90:0
Bad blocks are allowed: false
Device is writable: true
# optional /dev/mtd0 backup via dd:
# sudo dd if=/dev/mtd0 of=mtd0
$ sudo flashcp -v -A openwrt-24.10.2-ramips-mt76x8-xiaomi_mi-ra75-squashfs-sysupgrade.bin /dev/mtd0
Erasing blocks: 3744/3744 (100%)
Writing data: 5568k/5568k (100%)
Verifying data: 5568k/5568k (100%)
HINT: firmware partition (14.6MB) actually is divided into 2 banks: 1st starts at 0x0 and 2nd at 0x740000; you want to have 1st written and 2nd erased to force u-boot into booting only from 1st bank
- shutdown & disconnect everything
- OpenWrt should be good to go; connect to http://192.168.1.1/ over RJ-45, configure it and install 5G WiFi packages
Alternative method pros:
- if you have a SPI programmer, then write OpenWrt image directly to flash
- no soldering / UART / uboot env modding / custom image / TFTP needed (simpler?)
Alternative method cons:
- need to open the box
- need some HW (SBC or 3.3V SPI programmer), SOP8 clip, etc.
- can fry something if not paying attention
Problem
After flashing OpenWrt on my Xiaomi WiFi Extender RA75, the 5 GHz radio stopped working completely. (comi7-xiaomi-extender-ax1200-rc04-full-backup-prepared-with-openwrt-23.05.4-f9cf50339b10-ramips-mt76x8-xiaomi_mi-ra75-rc04-radio-squashfs-sysupgrade.bin)
In LuCI, only the 2.4 GHz band was active.
When the 5 GHz interface appeared, its transmit power was limited to just 3 dBm, and only the lower channels (36–40) were available.
Changing the country code or trying different mt76 driver versions didn’t help.
Even with several different OpenWrt dumps, the issue remained exactly the same.
After digging through the MTD layout, I found that the factory partition (usually /dev/mtd2) in the OpenWrt dump contained invalid calibration data.
This partition stores:
Wi-Fi chip calibration parameters (TX power, antenna gain, etc.)
Region/country info and allowed frequencies
The device’s MAC addresses
In short, this is where the radio’s EEPROM data lives.
When I flashed the official Xiaomi firmware dump, the exact same hardware worked perfectly — full TX power and full channel list.
So the issue wasn’t hardware; it was bad calibration data inside OpenWrt’s factory partition.
Here’s what I did to fix it:
-
SSH into the device.
-
Make a backup of your current factory partition:
dd if=/dev/mtd2 of=/tmp/fac-back.bin
(Keep this file safe — it’s your current calibration in case you ever need to revert.)
- From the original Xiaomi firmware dump (Original.bin — this is the full firmware image extracted from the stock device),
extract the factory partition section:
dd if=Original.bin of=fac-org.bin bs=1 skip=$((0x30000)) count=$((0x10000))
Original.bin here refers to the stock firmware dump (not OpenWrt).
We’re extracting 64 KB starting at offset 0x30000, which corresponds to the factory partition region.
-
Upload fac-org.bin to the router (e.g., via WinSCP into /tmp).
-
Overwrite the current factory partition with the original one:
mtd write /tmp/fac-org.bin factory
sync
reboot
- After the reboot, the 5 GHz radio immediately came back to life with full power.
Results
After restoring the original factory partition:
TX power increased from 3 dBm → 22 dBm
All 5 GHz channels up to 177 became available
Setting the country to United States unlocked full transmit power
Signal strength and coverage improved dramatically — even from long distances
2 Likes
Hi everyone,
I am using the Xiaomi Mi WiFi Range Extender AC1200 (Model RC04) which uses the MT7613BE chip for 5GHz and MT7628 for 2.4GHz.
I am currently running OpenWrt Stable 24.10.4.
The Problem:
I have restored the calibration data from a full flash backup (extracted 64KB from offset 0x30000) by writing it to the factory partition (/dev/mtd2).
While the 2.4GHz radio accepts this data perfectly, the 5GHz driver (mt76) ignores or rejects it.
1. 2.4GHz (MT7628) working perfectly
- MAC Address: Correct (Matches the sticker on the device: CC:D8:43...).
- Strong and stable signal.
- Works perfectly as both Client and AP.
- This confirms the factory partition is readable and the restored data file is valid.
2. 5GHz (MT7613BE) failing
- MAC Address: Random/Invalid on every boot.
- Log Output: dmesg reports: mt7615e 0000:01:00.0: Invalid MAC address, using random address...
- Performance: Because it fails to load the calibration data, the radio appears to be stuck in "Safe Mode" (Low Power). The signal is extremely weak compared to stock firmware (-75 dBm at close range).
- Client Mode: Unusable at normal distances: loops DEAUTH_LEAVING.
Steps Taken:
- Unlocked partition: insmod mtd-rw i_want_a_brick=1
- Wrote data: mtd write /tmp/factory.bin factory
- Verified write- hexdump confirms the data (and the correct MAC address) is physically present in /dev/mtd2.
- I have tried changing the Country Code to US, PA (Panama), and AU. While iw reg get confirms the change, the Transmit Power remains stuck at 3 dBm and the signal is still weak. This confirms the driver is stuck in a safety state due to the invalid EEPROM reading, regardless of the country setting.
Since the 2.4GHz driver reads the factory partition correctly but the 5GHz driver fails (reporting Invalid MAC), does the RC04 (MT7613BE) require a specific offset or header format different from the older RA75? Why is the driver failing to validate the EEPROM data despite it being physically present?
Thanks.
Fixed it, here it is :
https://github.com/openwrt/mt76/issues/1017
Hi everyone,
I managed to convert to openwrt two RC04’s in the past few days. I have a ch341a because I modified mi4a gigabit editions also in the past.
I desoldered the flash at the first one but i tried to reflash it in place with the second one and it’s worked.
Note: the factory firmware always disables back the boot_wait. I missed one the timeout and had to reflash aghain.
I used tftpd to load the initramfs image to ram, then downloaded the sysupgrade image after reboot and applied it.
I have to download the openwrt buildsystem to apply seaking100's factory data size patch, and I also created this new variant with the updated wifi module.
My original plan was to create a wds link with the master ap (which is a ax3000t running openwrt) but unfortunately the MT7613BE PHY doesn't supports wds packet format so I ended with
a mesh setup. The slow cpu will become a main bottleneck though.