I must be a masochist.
I was doing another test with WED, and I got soft bricked as expected.
This time I followed the "Development snapshot" step by step
Edit /etc/modules.conf and append this line: options mt7915e wed_enable=Y
This change requires a reboot
version 24.10 in this case.
the result: https://imgur.com/a/yh80iKh
So, on my devices I followed the wiki installation method, and it says to use 0 in these two variables.
nvram set ssh_en=1
nvram set uart_en=1
nvram set boot_wait=on
nvram set flag_boot_success=1
nvram set flag_try_sys1_failed=0
nvram set flag_try_sys2_failed=0
nvram commit
Did you enable HW offloading prior to that?
Never used it. I just set it higher than 7. Counters continue counting boots but never switches to another partition. You can change (just in case) boot address of second partition to be the same as the first one.
yes, is enable, and the package bridger is pre installed.
Don't know. Doesn't happen to me.
... but I have another, more serious problem, related to HW offloading 
=8 not =0
for this reason brick
Do you know which command replaces nvram in openwrt?
In version 24.10 this command does not exist.
And having to go back to the original FW to set
nvram set flag_try_sys1_failed=8
nvram set flag_try_sys2_failed=8
and then go back to openwrt, is a bit incoherent.
openWrt -ssh
opkg update && opkg install kmod-mtd-rw
insmod /lib/modules/$(uname -r)/mtd-rw.ko i_want_a_brick=1
fw_setenv boot_fw1 "run boot_rd_img;bootm"
fw_setenv flag_try_sys1_failed 8
fw_setenv flag_try_sys2_failed 8
fw_setenv flag_boot_rootfs 0
fw_setenv flag_boot_success 1
fw_setenv flag_last_success 1
reboot
So, I was looking through the old posts and this one from @remittor
It seems that the soft bricking problem was solved by activating WED.
and by forcing the power outage, the device did not go into soft bricking.
My tests were with version 24.10
I think it's a good time to gather the information here in the discussion area and redo the wiki page.
The information is missing there, and if you follow any of the instructions exactly, you can get the device into soft bricking.
Thanks, but after reading the old posts better, it seems I managed to adjust
If the "old" bootloader is before 2023, then there are no problems.
If "new", then the problem of 6 reboots turns the router into a brick, just like the AX3000t...
In order not to change the new bootloader to the old one, you need to enter these commands, or unbrick it each time after 6 reboots.
And it doesn’t matter how these reboots are done, by turning off the power, or through the Luci menu.
That's what's strange, the device simply entered brick mode immediately after 1 reboot.
Could it be because of flag_try_sys1_failed=0, which is recommended in the wiki?
This is not 1 reboot. Installed the firmware - reboot, updated the firmware - reboot, installed the package - reboot...
Is the logic clear?
And yes.
This is all because of the reboot counter.
The method described by me and found by you is 10000000000% working.
If you don't want to suffer further - do as written.
You yourself write that you don't have this problem on the old router? That means there is an old bootloader, and where there are new ones, you get bricks.
Enter
fw_printenv
and compare the bootloader creation dates of your routers.
Yes, the problem is the reboot count.
But thinking about it, my final process for the last brick.
I installed the original FW 1.0.71 via FTP - 1 reboot
Unlocked using XMiR-Patcher - without reboot
Direct installation of OpenWRT 24.10 customized from the FW selector with the pre-installed packages - 1 reboot
Returned the OpenWRT config bk file - 1 reboot
Config for WED - 1 reboot
Brick mode activated.
In other words, my device was entering brick mode after 4 reboots.
A revision of the wiki page is really necessary to include this information..
About the bootloader date:
The old device:
CountryCode=CN
Router_unconfigured=0
SN=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
arch=arm
autostart=yes
baudrate=115200
board=mt7622_evb
board_name=mt7622_evb
boot_auto=bootxq
boot_fw0=run boot_rd_img;bootm
boot_fw1=run boot_rd_img;bootm
boot_rd_img=nand read ${loadaddr} 0x2C0000 2000;image_blks 2048;nand read ${loadaddr} 0x2C0000 ${img_align_size}
boot_rd_img2=nand read ${loadaddr} 0x20C0000 2000;image_blks 2048;nand read ${loadaddr} 0x20C0000 ${img_align_size}
boot_wait=on
bootargs=console=ttyS0,115200n1 loglevel=8 swiotlb=512 rootfstype=squashfs firmware=1 uart_en=1
bootcmd=bootxq
bootdelay=5
bootmenu_0=1. Load firmware 0 and bootup.=run boot_fw0
bootmenu_1=2. Load firmware 1 and bootup.=run boot_fw1
bootmenu_2=3. Load firmware selected by Xiaoqiang and bootup.=run boot_auto
bootmenu_delay=30
color=100
cpu=armv7
ethact=mtk_eth
ethaddr=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
ethaddr_wan=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
fdt_high=0x6c000000
flag_boot_rootfs=1
flag_boot_success=1
flag_boot_type=2
flag_flash_permission=1
flag_last_success=1
flag_ota_reboot=0
flag_show_upgrade_info=1
flag_try_sys1_failed=0
flag_try_sys2_failed=0
invaild_env=no
ipaddr=192.168.31.1
loadaddr=0x4007FF28
miot_did=503588066
miot_key=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
mode=Router
model=RB03
no_wifi_dev_times=0
nv_sys_pwd=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
nv_wifi_enc=psk2
nv_wifi_enc1=psk2
nv_wifi_pwd=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
nv_wifi_pwd1=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
nv_wifi_ssid=Redmi_39A0
nv_wifi_ssid1=Redmi_39A0
restore_defaults=0
serverip=192.168.31.100
soc=mt7622
ssh_en=1
stderr=serial
stdin=serial
stdout=serial
telnet_en=0
uart_en=1
vendor=mediatek
wl0_radio=1
wl0_ssid=Xiaomi_5G
wl1_radio=1
wl1_ssid=Xiaomi
One of the newer devices:
CountryCode=BR
Router_unconfigured=0
SN=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
arch=arm
autostart=yes
baudrate=115200
board=mt7622_evb
board_name=mt7622_evb
boot_auto=bootxq
boot_fw0=run boot_rd_img;bootm
boot_fw1=run boot_rd_img;bootm
boot_rd_img=nand read ${loadaddr} 0x2C0000 2000;image_blks 2048;nand read ${load addr} 0x2C0000 ${img_align_size}
boot_rd_img2=nand read ${loadaddr} 0x20C0000 2000;image_blks 2048;nand read ${lo adaddr} 0x20C0000 ${img_align_size}
boot_wait=on
bootargs=console=ttyS0,115200n1 loglevel=8 swiotlb=512 rootfstype=squashfs firmw are=0 uart_en=1
bootcmd=bootxq
bootdelay=3
bootmenu_0=1. Load firmware 0 and bootup.=run boot_fw0
bootmenu_1=2. Load firmware 1 and bootup.=run boot_fw1
bootmenu_2=3. Load firmware selected by Xiaoqiang and bootup.=run boot_auto
bootmenu_delay=5
color=100
cpu=armv7
ethact=mtk_eth
ethaddr=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
ethaddr_wan=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
fdt_high=0x6c000000
flag_boot_rootfs=0
flag_boot_success=1
flag_boot_type=2
flag_last_success=1
flag_ota_reboot=0
flag_try_sys1_failed=10
flag_try_sys2_failed=8
invaild_env=no
ipaddr=192.168.31.1
loadaddr=0x4007FF28
miot_did=633868138
miot_key=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
mode=Router
model=RB01
no_wifi_dev_times=0
nv_sys_pwd=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
nv_wifi_enc=psk2
nv_wifi_enc1=psk2
nv_wifi_pwd=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
nv_wifi_pwd1=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
nv_wifi_ssid=Xiaomi_1B61
nv_wifi_ssid1=Xiaomi_1B61
restore_defaults=0
serverip=192.168.31.100
soc=mt7622
ssh_en=1
stderr=serial
stdin=serial
stdout=serial
telnet_en=1
uart_en=1
vendor=mediatek
wl0_radio=1
wl0_ssid=xiaomi-router-rb01_miap1b61_5G
wl1_radio=1
wl1_ssid=xiaomi-router-rb01_miap1b61
Upper parameter = 10
8+2=10 - 2 reboots.
It should be the same on "new bootloaders".
It doesn't matter what you think, what matters is what your router thinks.
flag_try_sys2_failed=8
and the parameter
flag_try_sys1_failed=...
increases by +1 with each reboot.
Without this edit =6 and a brick.
In custom firmware these nuances are taken into account and the code similar to the stock firmware code is implemented in them, but for some reason the official OpenWrt does not implement this. There are also no Uboot-mod bootloaders for this model, which leads to such consequences.
It seems that the comment on this commit in git, which occurred during the transition from 23.05.x to 24.10 on the ax3000/ax6s, makes sense now.
Xiaomi did crazy things with uboot, and with the size of the partitions on the flash.
What would save the situation would be a Uboot-mod, like they did on the Redmi AX6000.
But I think that this should not be worth implementing yet.
Just out of curiosity, I have a Redmi AX6000 since the initial development of OpenWrt for it, and since the release of uboot-mod, I also installed it. Literally 0 problems with it related to reboot, only with 5Ghz wifi with low signal clients that completely kills the radio, but this is already known in its discussion.
I previously tried WED on 23.05 with the WIKI steps. Soft/hardware offloading both enabled too. Rebooted and no problem, and it was working (considering the CPU load decreased when downloading/stpeed-testing)
But since I decided to keep SQM, i reverted back disabling wed and offloading.
I just had my router brick itself this morning, thanks to this infuriating issue. I thought this might be fixed in 24.10.1 but apparently not. Really ruined my day!
Can someone summarise the steps to mitigate this issue? Second time I've had to deal with this and I'm pretty tired of it.
Which issue are you referring to? Orange LED after 6 reboots? Come on, scroll up just few posts and read. It takes less time than downloading tools required for fixing soft brick.