Prior to: ARM Trusted Firmware A v2.9(release)
3 Likes
This is my favorite theory at the moment.
2 Likes
Most likely booted into recovery mode, i.e, there were ramoops content stored in your router’s pstore file system. Power cycling clears it and bootloader then boots normally.
Just upgraded my 2 Belkin RT3200 to OpenWrt 23.05.3 using Attended Sysupgrade without issues.
I do have the following in my Local Startup:
# Prevent stuck at reboot due to too low frequency
echo 600000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
echo schedutil > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
Initial installation was done in 2021 using installer v0.6.1 and I didn't run the installer again afterwards.
2 Likes
OK your post tipped me over the edge and I likewise just pulled the trigger on my three trusty old RT3200's. Upgrade using the LuCi Attended Sysupgrade interface from 23.05.2 to 23.05.3 went just fine - install history as per:
These three devices, which I have connected via WDS, have been great performers and rock solid - a great OpenWrt success story. Hence I sincerely hope the OKD issue can be addressed.
3 Likes
Moving FIP to UBI was done mostly because of OKD happening. The messages I got from users with debug information kinda show that that didn't improve the situation, but it also shouldn't make it worse.
As the relevant part (patches for MediaTek SoCs, incl. die SPI-NAND driver and even UBI support) is all applied as downstream patches on top, none of that is covered in the ChangeLog file. You will have to use diff...
1 Like
Thank you for the debricking guide!
Just ordered this USB to TTL serial adapter, it's coming on Sunday.
Where in the recovery steps can I insert a step (and how do I use it) to record the debug info Daniel has requested below?
Also, I'm pretty sure I was on the 1.1.0 installer when I got OKD'd, should I run the 1.1.1 installer somehow during or after this recovery?
1 Like
My RT3200 bricked again ( third time ) after a power cycle.
I used the guide on openwrt.org to recover via serial adapter. I had to modify the command a bit to work with my flavor of Linux
sudo ./mtk_uartboot -a -p bl2-for-mtk_uartboot.bin -f openwrt-mediatek-mt7622-linksys_e8450-ubi-bl31-uboot.fip && sudo screen /dev/ttyUSB0 115200
Not sure how many more times this thing can be recovered!
1 Like
@daniel
I am pondering if it is possible to rewrite FIP from a normally running router.
(I have a router suffering from occasional OKD. I got it booted this time with the refrigerator trick. No serial attached yet, so am thinking about shortcuts...)
As FIP is now in ubi in the new scheme in main/master, we should be able to rewrite it via ubi commands, as FIP is not in active use or mounted during normal operations. Right?
This command verifies that "fip" is one of the ubi volumes, so my router is using the new partition scheme: (Name" is fip)
root@router4:~# ubinfo -d 0 -n 0
Volume ID: 0 (on ubi0)
Type: static
Alignment: 1
Size: 9 LEBs (1142784 bytes, 1.0 MiB)
Data bytes: 1019644 bytes (995.7 KiB)
State: OK
Name: fip
Character device major/minor: 251:1
root@router4:/tmp# ls -l openwrt-mediatek-mt7622-linksys_e8450-ubi-bl31-uboot.fip
-rw-r--r-- 1 root root 1012564 Apr 6 20:13 openwrt-mediatek-mt7622-linksys_e8450-ubi-bl31-uboot.fip
Your old advice regarding the recovery partition rewrite sounds pretty applicable to FIP with slight modifications: Belkin RT3200/Linksys E8450 WiFi AX discussion - #1318 by daniel
FIP image is standard-sized, so using ubiupdatevol should work without fearing of needing to reserve more space, right?
Would it work by just downloading the current FIP image and doing ubi volume update?
ubiupdatevol /dev/ubi0_0 openwrt-mediatek-mt7622-linksys_e8450-ubi-bl31-uboot.fip
There are no bad blocks yet, so ubi has its reserve intact:
root@router4:/tmp# ubinfo -d 0 | grep physical
Count of bad physical eraseblocks: 0
Count of reserved physical eraseblocks: 20
Despite that, if oversize risks are still feared, then booting into initramfs recovery and ubirmvol rootfs_data should take care of freeing enough space, right?
EDIT:
I actually did that: I updated my RT3200 with the current .fip file via ubiupdatevol while running normal OpenWrt. Router booted ok after that, and the size info of the volume has changed, so flash did happen:
root@router4:~# ubinfo -d 0 -n 0
Volume ID: 0 (on ubi0)
Type: static
Alignment: 1
Size: 9 LEBs (1142784 bytes, 1.0 MiB)
Data bytes: 1012564 bytes (988.8 KiB)
State: OK
Name: fip
Character device major/minor: 251:1
Curious to see if that helps against subsequent OKDs.
EDIT2:
The router also survived the next sysupgrade without OKD 
4 Likes
Is there any documentation on the mtk_uartboot handshake sequence anywhere?
I ask as I (like many others) have it sit at "Handshake..." and never proceed, however I have modified the code to print out the bytes that are coming in at power on time and I see a different sequence to what is expected.
The expected handshake is 0xA0 0x0A 0x50 0x05
What my device sends is different each time, for example:
1. 0xA0 0xF5 0xCF 0xB1 0xAB 0xBA
2. 0xA0 0x0A 0xAE 0xA0 0xF5 0xCF 0xAB 0xBA
3. 0xA0 0x0A 0xAE 0xA0 0xF4 0xA0 0xF4 0xF5 0xB1 0xAB 0xBA
4. 0xA0 0x0A 0xAE 0xF5 0xCF 0xB1 0xBA
But never the handshake sequence. 
The step "Run the mtk_uartboot program with your downloaded files, followed by an immediate screen or putty command. Below are some examples:", send the bl2-for-debug-snand-issue.bin as the payload instead. No need to try to start screen, putty, etc. after as this payload just causes a bunch of debug info to be dumped to console.
Pretty sure 1.1.0 and 1.1.1 are the same, just 1.1.1 adds the bl2.bin files. @daniel could perhaps confirm.
2 Likes
For me it was the serial adapter. I could never get the silicon labs serial adapter to work. But the FT232RNL adapter worked.
Interesting, I'm using a "Waveshare" FT232RNL here.
dmesg shows:
usb 1-1.4: Product: FT232R USB UART
usb 1-1.4: Manufacturer: FTDI
usb 1-1.4: SerialNumber: B001B2L2
ftdi_sio 1-1.4:1.0: FTDI USB Serial Device converter detected
usb 1-1.4: Detected FT232RL
usb 1-1.4: FTDI USB Serial Device converter now attached to ttyUSB0
Unbelievable. After what seemed like 100 cold boot attempts via the serial port, it finally worked and presented the uBoot menu. A quick mtd read ... and it's back up and working.
1 Like
That's the exact same USB to Serial adapter that I used!
Glad it finally worked for you!
My usb serial had to be removed and reinstalled then run mkt_uartboot before it would go past handshake.
Has anybody used a CP2102-based USB-to-TTL adapter?
I'm not getting past "Handshake..." despite double-checking the connections and there are singular red & blue LEDs lit up on the adapter (indicating TX and RX, I believe).
On Windows 11: mtk_uartboot -s COM3 --bl2-load-baudrate 115200 -a -p bl2-for-debug-snand-issue.bin -f NUL:
I'm also going crazy because I can't remember if the dang thing is POWERED ON or not (since there are no LED lights)... can somebody please confirm what is the "powered on" switch setting for an RT3200? Google says it's commonly I = on, O = off.
Check the grounding connection between both devices (laptop and router). if possible, try running the laptop from battery and without power supply connected during the procedure, that usually helps a lot and avoids potential ground-loop issues.
1 Like
Try setting both --brom-load-baudrate 115200 --bl2-load-baudrate 115200. If that also doesn't help, avoid ground-loop as mentioned in the post above.
The I pressed down means the device is powered-on.
1 Like
Added that and fussed with the wires some more and got it working!
1 Like