Does the easy method do back ups of the factory boatloader etc?
Hello everyone!
I had flashed my AX3000T (RD23 with ESMT chip & 1.0.31 pre-installed) with "easy method" mentioned here. After setup of bol-van's zapret (DPI fooling software) I rebooted it with web-interface and it fell in some kind of bootloop (red led staying on 5 sec & off 2 sec) so I assume it's softbricked (bootloader is untouched)
How can I unbrick it with MacOS? I tried MiWiFiRepairTool with Whisky and Crossover but they do not seem to work properly.
As for me, only u-boot with web interface for emergency recovery is easy method.
E.g., U-Boot from MTK SDK and Breed has a web interface.
The best choice is u-boot from mtk sdk - a simple english interface and open source code.
For ax3000t mtk uboot you can try by the link as was there is:
(see 'mtk-uboot' folder, readme.txt file)
And, as @mamba wrote, he restored the brick and installed MTK U-boot and Openwrt 23.05.5 on the router with the new SPI NAND.
I don't have a router to investigate the issue with the new version of the of uboot from stock firmware (firmware for a new nand), and not sure, that there is issue with OpenWrt ubootmod.
I believe there is new algorithm for a new stock firmware (uboot) to restore after 5 fails (see variables in the nvram: flag_try_sys1_failed, flag_try_sys2_failed).
And maybe these changes not only for stock firmware for a new spi-nand.
How often do people need to use recovery methods anyway? I've been using both OpenWrt and Gargoyle since 2016/2017 and have never needed it.
The TFTP method from OpenWrt U-Boot is simple enough and consistent with the ones used by other manufacturers, like TP-Link, for the very rare occassion where you would need it.
You can also create scripts to automate the process for you with something like https://tftpy.sourceforge.net (which would make the process even easier than MiWiFiRepairTool).
Sure, you can't go back to stock firmware without first restoring the original bootloader, but unless you're on AN8855 (which is something you should've checked before even considering flashing OpenWrt), why would you go back to stock firmware anyway?
How long did you wait for the orange LED to turn blue? The behavior you described seems consistent with OpenWrt, it starts with the orange LED, which is then blinked as initialization of services start. Once /etc/init.d/done service is executed, the LED changes to blue.
If you've awaited long enough without a blue LED, try pressing the mesh button at the back of the device multiple times as soon as you power the device. Assuming OpenWrt is booting, this will tell it to reboot in failsafe mode (you know this worked if the LED started blinking faster).
Maybe it was already here...
AX3000T Global Version (GL) 1.0.31 (INT) , MT7531 switch + ESMT spi-nand.
Brick after the first restart of the OpenWrt firmware (and possibly, after updating OpenWrt settings).
The reason is the stock u-boot of the GL version, and only the stock u-boot from the CN version (1.0.47) or an alternative u-boot works with the current version of OpenWrt correctly.
(please be aware, after birck, also, factory partitons restore is nessacery)
UPD
hi, I believe the same as I described here.
Try this method with CN u-boot or alternative u-boot, or 'tftp' method if possible of course (haven't tested for this case)
1 Like
the MiWiFiRepairTool is just a tftp server. just deploy any native tftp server for mac os and host the original mi firmware. make sure you set your mac lan to the ip address as specified in the MiWiFIRepairTool manual as the boot loader specifically looks for that IP on boot.
1 Like
The firmware file name is also very important. It is specified in WIKI. Without it, nothing will work, or look at the TFTP log and you will see from which IP and with what name the router is waiting for the firmware.
1 Like
If I recall, the filename is just the client's (in this case the router) ip in hex +.bin
You could use this information to make the stock recovery process easier if one wishes. (Either by restricting what IP you hand out via DHCP, or your tftp server serving the correct file)
2 Likes
An addendum: MiWiFiRepairTool is a TFTP server and a DHCP server. I don't like to use MiWiFiRepairTool since it is Windows only and it triggers some anti-virus warnings (never confirmed if it is a false positive).
But it is possible to recover from a stock boot loader without MiWiFiRepairTool using standard tools. It took me a while to understand this (why my own TFTP server was not working to recover using Xiaomi stock loader), then I've read carefuly some recover instructions and they use dnsmasq to enable both a TFTP server and a DHCP server to recover a Xiaomi router. The image filename to be served via TFTP also needs a special name (at least for the Redmi AX6S it has to be named after the TFTP server IP address converted to hex. Example: 192.168.31.100 -> C0A81F64.img).
For this reason I am able to recover a Xiaomi router (with stock boot loader) from a Linux box quite easily without having to use MiWiFiRepairTool (see example using dnsmasq as TFTP and DHCP server here).
3 Likes
I just realised 160mhz does not seem to work, I'm running the latest snapshot.
Can someone confirm if setting 5ghz width to 160mhz works for you?
Basically on the status page the 5ghz radio shows 0 and will not enable.
Channel is set to auto
If I manually set the channel to 52 or 112 the radio turns on but shows its running at 6ghz which doesn't seem to be correct as the ax3000t only supports 2.4 or 5ghz.
And none of my devices can connect to it.
Setting it to 80mhz works.
Ah figured it out. I have not set a country code. It was set to default.
After setting country code it worked
Anyone tried to measure the 5 GHz CPU performance with WED enabled for this model yet?
But website says that UART is not the only possible way to flash RD23 models. Is that incorrect? Or did I have to flash u-boot to CN/OpenWrt/other after installing OpenWrt?
If yes, my plan is: restoring stock software via TFTP - flashing OpenWrt - flashing u-boot, right?
UART, as I know, is a low level dev method from mtk, so, no possible restrictions for vendors or models.
And this method is more situable for restore router with corrupted bl2 (preloaded) or (and) fip (loader) partitions.
And if your bootloader is working and can help your to restore brick - ok, no any restrictions to use 'tftp' method.
Upd
I tested this method on the rd03 model)
Have you heared anything about that? I know the soc is capable, but i dont think the pins are brought out somewhere? It would be seen in dmesg if its in the devicetree
The SoC datasheet mention usb2 and usb3.
no rocket science for implementing it
you need TX RX and some mosfet and coil to generate 5V.
i guess cloud and AI is the way of saying FU to local storage and consumers nowadays.
if the tracks from behind BGA are mapped on the board there is a chance, gotta investigate further.
I don't have it on as I just use the device as an AP so CPU consumption is not high, it doesn't do any routing or firewall services.
Right next to the device I get very good speeds on my pixel 7. I will test with my laptop later with an ax210 nic as i think i should be able to max it out to 2400Mbps if I am right next to it.
I've measured the following so far:
Wired
speedtest: 850-950 mbps (my contracted speed is 750 mbps)
waveform/bufferbloat: 850-950 mbps, crappy bufferbloat rating due to my HFC upload on 4 upstream channels lagging the connection after around 65 mbps ( capping between 70-100 mbps).
CPU usage: 1-2% with hardware flow offloading enabled, 70-75% with just software flow offloading.
WiFi 5 GHz WED disabled (single antenna Redmi Note 11)
speedtest and waveform/bufferbloat: 100-205 mbps, consistent with my Archer C6 v2 after 5GHz Low performance on TP-Link Archer C6 V2 - #103 by Cthulhu88
note: hardware flow offloading was acting weird here and often giving me sub-100 mbps results, likely due to fw4 adding phy1-ap0 to the flowtable. devices = { lan2, lan3, lan4, phy1-ap0, wan } vs devices = { br-lan, wan } with just software flow offloading.
Next I will be trying the same phone with WED enabled and a 2x2 antenna laptop via iperf3.
Hello!
I switched to ubootmod but fw_printenv still shows values from the stock bootloader.
seems to be wrong:
/etc/fw_env.config
/dev/mtd1 0x0 0x10000 0x20000
How can I fix this?
mtd
dev: size erasesize name
mtd0: 00100000 00020000 "BL2"
mtd1: 00040000 00020000 "Nvram"
mtd2: 00040000 00020000 "Bdata"
mtd3: 00200000 00020000 "Factory"
mtd4: 00200000 00020000 "FIP"
mtd5: 00040000 00020000 "crash"
mtd6: 00040000 00020000 "crash_log"
mtd7: 00040000 00020000 "KF"
mtd8: 07000000 00020000 "ubi"
ubinfo
UBI version: 1
Count of UBI devices: 1
UBI control device major/minor: 10:127
Present UBI devices: ubi0
ubi0
Volumes count: 5
Logical eraseblock size: 126976 bytes, 124.0 KiB
Total amount of logical eraseblocks: 896 (113770496 bytes, 108.5 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
Volume ID: 0 (on ubi0)
Type: dynamic
Alignment: 1
Size: 2 LEBs (253952 bytes, 248.0 KiB)
State: OK
Name: ubootenv
Character device major/minor: 250:1
Volume ID: 1 (on ubi0)
Type: dynamic
Alignment: 1
Size: 2 LEBs (253952 bytes, 248.0 KiB)
State: OK
Name: ubootenv2
Character device major/minor: 250:2
Volume ID: 2 (on ubi0)
Type: dynamic
Alignment: 1
Size: 83 LEBs (10539008 bytes, 10.0 MiB)
State: OK
Name: recovery
Character device major/minor: 250:3
Volume ID: 3 (on ubi0)
Type: dynamic
Alignment: 1
Size: 81 LEBs (10285056 bytes, 9.8 MiB)
State: OK
Name: fit
Character device major/minor: 250:4
Volume ID: 4 (on ubi0)
Type: dynamic
Alignment: 1
Size: 702 LEBs (89137152 bytes, 85.0 MiB)
State: OK
Name: rootfs_data
Character device major/minor: 250:5