Meh.
And I hoped you forgot answer because it's working now.
How are these variables look after a few reboot on stock? Or these are the ones? Before installing OpenWrt?
Meh.
And I hoped you forgot answer because it's working now.
How are these variables look after a few reboot on stock? Or these are the ones? Before installing OpenWrt?
No, these are the variables after flashing OpenWRT. I have just unbricked again via tftp, and rebooted twice on stock. These are the variables that I can see now on stock on the third boot:
flag_boot_rootfs=0
flag_boot_success=1
flag_boot_type=2
flag_last_success=0
flag_ota_reboot=0
flag_try_sys1_failed=0
flag_try_sys2_failed=0
and
boot_auto=bootxq
boot_fw0=run boot_rd_img;bootm
boot_fw1=run boot_rd_img2;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=off
bootargs=console=ttyS0,115200n1 loglevel=8 swiotlb=512 rootfstype=squashfs firmware=0 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
From what I can see, they are identical on stock and Openwrt.
Let me check my device's variables too later, but until then:
please reboot after setting flag_ota_reboot
to 1
!
And if they change in a meaningful way, try install OpenWrt again!
And here are mines (from a nicely working OpenWrt installations).
Device1
boot_auto=bootxq
boot_fw0=run boot_rd_img;bootm
boot_fw1=run boot_rd_img2;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
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
flag_boot_rootfs=0
flag_boot_success=1
flag_boot_type=2
flag_last_success=1
flag_ota_reboot=1
flag_try_sys1_failed=0
flag_try_sys2_failed=0
Device2
boot_auto=bootxq
boot_fw0=run boot_rd_img;bootm
boot_fw1=run boot_rd_img2;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
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
flag_boot_rootfs=0
flag_boot_success=1
flag_boot_type=2
flag_last_success=0
flag_ota_reboot=0
flag_try_sys1_failed=0
flag_try_sys2_failed=0
I don't know how flag_xxxx_success
should be interpreted, but in Redmi AX6000 wiki page:
here set
flag_last_success
=1 andflag_try_sys1_failed
>= 6 andflag_try_sys1_failed
>=6, to make it always boot from system 0
Wanna give a try?
fw_setenv boot_wait on fw_setenv uart_en 1 fw_setenv flag_boot_rootfs 0 fw_setenv flag_last_success 1 fw_setenv flag_boot_success 1 fw_setenv flag_try_sys1_failed 8 fw_setenv flag_try_sys2_failed 8
How interesting, my second device's values are the same as yours.
How about tgabor's serial access in comment #612?
Did you try sysupgrading on that very first OpenWrt boot?
For stock images:
boot_fw0=run boot_rd_img;bootm
boot_fw1=run boot_rd_img2;bootm
Recomended for OpenWRT image:
boot_fw0=run boot_rd_img;bootm
boot_fw1=run boot_rd_img;bootm
I forgot to clarify: The issue I am having is NOT it booting into the wrong slot. Eg, it doesn't boot the stock firmware like you would expect it to do if it's loading the wrong slot. What I am experiencing is that it does not boot at all, and simply boot loops. A debrick via tftp is needed to get it to work again. Which is super weird, since it does boot successfully once after flashing. It's just that each subsequent boot no longer works.
I have bought a second device and flashed this one with Openwrt as well via the exact same steps, and this one is working fine. So it looks like it's not that I am doing something wrong.
Yup, it's crystal clear to me. As you wrote, its super weird and I can't imagine whats wrong with that device!
There was a "fix hang on reboot on MT7622" commit, but that was for arm-trusted-firmware-mediatek
, and not a loop anyway.
In January there was a BMTv2 stuff for this (rincewind, #1399, more detail in that PR) but that was fixed too. And you are sti
So I hope you would have a serial access for this device!
Can't wait for the logs.
Yes, my ONT is plugged directly into the WAN port and my AX6S serves the network via PPPoE with DS-Lite. (I cannot tell you the model of the ONT as it's mounted inside a drawer, it was supplied by the ISP.) It has been running perfectly stable for half a year at this point.
I am still running snapshot 22.03.3 r20028-43d71ad93e as I didn't yet feel the need to upgrade. No Apple devices that would suffer from the wireless bug.
A question. I have unlocked easily another ax3200 with xmir patcher without other xiaomi in mesh.
when i upgraded from 23.03 to 23.05 i kept the setting but some setting was lost.
Is it better not to keep the settings and reset to default them?
Now you can get root access to 90% of Xiaomi routers using the oldest bug in the code.
XMiR-Patcher takes advantage of this.
Have same issue, had kernel panic router rebooted and suddenly firmware loaded up and 2ghz interface become up. Still unsure what could fixed it. Let see if I could reproduce it.
[ 6.820838] mt7622-wmac 18000000.wmac: HW/SW Version: 0x8a108a10, Build Time: 20190801210006a
[ 6.820838]
[ 6.904318] mtk-pcie 1a143000.pcie: msi#0 address_hi 0x0 address_lo 0x44d1d0c0
[ 6.924122] mt7622-wmac 18000000.wmac: N9 Firmware Version: _reserved_, Build Time: 20220630094834
Now mt7622 targets support pstore and ramoops.
After panic type this:
cat /sys/fs/pstore/dmesg-ramoops-0
cat /sys/fs/pstore/console-ramoops-0
Files doesn't exist, reason of crash wasn't kernel panic it seems, but memory leak in snmpd, as it already growing in mem consumption steadily. Still not sure how it made fix for firmware load bug
Please read another time what I wrote. The question is another.
Tried recent snapshot release r24194-e1aaa1defd
and its fixed issue with 2ghz not working due to mt7622-wmac 18000000.wmac: Failed to get patch semaphore
messages in dmesg.
So it appears to be issue is still there, but less common. When I enabled SQM and rebooted it appeared for me once again, but after disabling and enabling I couldn't reproduce so maybe something else. Feels like its some kind race condition
See this post:
According to the description, that is indeed the EU version of the AX3200 router: https://openwrt.org/toh/xiaomi/ax3200
If that is correct and the conversion rate is accurate, around 50 EURO is a really good price for that router.
It runs OpenWrt very well and you can even expect SQM QoS at 300+ Mbps