No. My trx images writes to flash.
OK guys, now I'm really confused... @remittor I don't see a trx file for AX59U or AX4200 in your zip files in the repo at https://github.com/openwrt-xiaomi/builder/releases
So where is it? And if I'm maybe missing something, I'd also like to know what build version are they based on? From what branch, what date?
1 Like
24.10.1 is currently building, finally.
Hello.
I tried to install a self-builded firmware 24.10.1, but the result is the same - a brick. The same thing happened with 24.10.0.
However, if I flash the official firmware 24.10.1 or 24.10.0 from downloads.openwrt.org, everything works.
Sequence of actions:
- Update with the latest firmware from Asus. At the moment, this is RT-AX59U_3.0.0.4_388_33903-gf5cd6c5.trx
- Flash with the current intermediate firmware openwrt-24_rt-ax59u-initramfs.trx.
- From under it, I flash the final one - official openwrt image or my own.
In case of a brick, I roll back like this:
- Switch to rescue mode, flash asus_rt-ax59u-ubi-cleaner.trx
- Switch to rescue mode again, flash with the official firmware from Asus.
It's not hard for me to deliver the necessary packages to the official openwrt firmware, but it would be cooler to use my own, where they will all already be. I heard that there are problems due to too new uboot, but it is just not clear why this does not apply to the official openwrt firmware. Are there any tricky options in the config? I use everything default, only adding the packages I need. My config is here.
I have just flashed a new AX59U following similar steps to yours (my unit has the older U-Boot 2022.04-rc1). So the steps were:
- Upgrade the existing ASUS firmware 388_32702 (quite an old factory firmware from October 2023) to latest 388_33903 from March 2025.
- Flash in Web UI the latest intermediate v24 initramfs trx dated Apr 4 2025
- From it, flash a customized SNAPSHOT 29241 build created with https://firmware-selector.openwrt.org/?version=SNAPSHOT&target=mediatek%2Ffilogic&id=asus_rt-ax59u
No brick in my case, it seems to be working, apart from the annoying, known EEE bug causing link down/up issue on MT7530 switch: https://github.com/openwrt/openwrt/issues/17351 (also mentioned in the 24.10.1 release notes).
Yes, the official way works. I compile my firmware under Linux via buildroot - but they don't work, even in the default autogenerated config. But if I take this config, I get working images, although with a bunch of extra unnecessary firmware.
The main question is which of the options that is not in the autogenerated config, but is in config.buildinfo makes the image usable =)
Does anyone know why is the disk space only 95 MB instead of 128 MB, the actual NAND flash capacity of the AX59U? Here's a screenshot:
FYI, I've used the trx file openwrt-24_rt-ax59u-initramfs.trx from @remittor's drive https://drive.google.com/drive/folders/1A20QdjK7Udagu31FSszpWAk8-cGlCwsq to do the initial flash to openwrt 24, then sysupgraded to a recent snapshot.
Where is your router storing the boot loader + config, ART data, and Openwrt firmware ?
Read the top page info about flash space at https://openwrt.org/toh/start
@frollic Thanks for chiming in, but I've seen screenshots with much higher disk space. 95 MB free space means that the boot loader+config+ART + Openwrt takes up 33 MB? The OpenWrt image I flashed is only 10 MB. What's taking up the other 23 MB?
For your device, running vanilla Openwrt?
The vendor flash layout.
cat /proc/mtd
95 out of 128 is pretty damn good, IMHO.
@frollic This is what I get, please translate 
root@OpenWrt:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00400000 00020000 "u-boot"
mtd1: 07c00000 00020000 "UBI_DEV"
Anyone else who knows more about this?
try ubinfo -a instead.
Thanks, this is what I get:
root@OpenWrt:~# ubinfo -a
UBI version: 1
Count of UBI devices: 1
UBI control device major/minor: 10:127
Present UBI devices: ubi0
ubi0
Volumes count: 7
Logical eraseblock size: 126976 bytes, 124.0 KiB
Total amount of logical eraseblocks: 992 (125960192 bytes, 120.1 MiB)
Amount of available logical eraseblocks: 0 (0 bytes)
Maximum count of volumes 128
Count of bad physical eraseblocks: 0
Count of reserved physical eraseblocks: 20
Current maximum erase counter value: 6
Minimum input/output unit size: 2048 bytes
Character device major/minor: 250:0
Present volumes: 0, 1, 2, 3, 4, 5, 6
Volume ID: 0 (on ubi0)
Type: dynamic
Alignment: 1
Size: 1 LEBs (126976 bytes, 124.0 KiB)
State: OK
Name: nvram
Character device major/minor: 250:1
-----------------------------------
Volume ID: 1 (on ubi0)
Type: dynamic
Alignment: 1
Size: 8 LEBs (1015808 bytes, 992.0 KiB)
State: OK
Name: Factory
Character device major/minor: 250:2
-----------------------------------
Volume ID: 2 (on ubi0)
Type: dynamic
Alignment: 1
Size: 8 LEBs (1015808 bytes, 992.0 KiB)
State: OK
Name: Factory2
Character device major/minor: 250:3
-----------------------------------
Volume ID: 3 (on ubi0)
Type: dynamic
Alignment: 1
Size: 35 LEBs (4444160 bytes, 4.2 MiB)
State: OK
Name: linux
Character device major/minor: 250:4
-----------------------------------
Volume ID: 4 (on ubi0)
Type: dynamic
Alignment: 1
Size: 2 LEBs (253952 bytes, 248.0 KiB)
State: OK
Name: jffs2
Character device major/minor: 250:5
-----------------------------------
Volume ID: 5 (on ubi0)
Type: dynamic
Alignment: 1
Size: 44 LEBs (5586944 bytes, 5.3 MiB)
State: OK
Name: rootfs
Character device major/minor: 250:6
-----------------------------------
Volume ID: 6 (on ubi0)
Type: dynamic
Alignment: 1
Size: 868 LEBs (110215168 bytes, 105.1 MiB)
State: OK
Name: rootfs_data
Character device major/minor: 250:7
well, now you know ...
1 Like
Basically Volume 6 has 105 MB, on which the current snapshot image occupies 10 MB, so I'm left with 95 MB free space.
0x07c00000 = 124 MiB ==> UBIFS size
124 - 105 = 19 MiB ==> size of snapshot, nvram, factory and etc.
4 (uboot) + 124 (UBI_DEV) = 128 MiB
2 Likes