I also bricked my E8450 with same error message like m1tchll's. What happened to me is I tried to upgrade to a image I built, I got image version warning like
The device is supported, but this image is incompatible for sysupgrade based on the image version (1.1->2.0)
I checked force update and got bricked.
@daniel the only method to fix this is through JTAG?
@m1tchll, could you let me know where you bought the adapter? I need it too.
You left out the explanatory part of the shown message:
"SPI-NAND flash layout changes require bootloader update"
@daniel
Could the warning message for the 1.1-->2.0 compatibility in mt7622.mk be clarified, so that it would additionally explain that you need to once run the UBI installer version 1.1.0+
"SPI-NAND flash layout changes require bootloader update. Please run the UBI installer version 1.1.0+ (unsigned) first."
@qosmio Try TFTP as described here: Linksys E8450 Bricked - How to open the device? - #3 by kprav33n
That warning was there to prevent this exact situation. Maybe it wasn't clear enough, however.
The reason the warning exists is because the partitioning layout changed late last year. The changes have been present in snapshot ever since, and a device that hasn't run the newer installer tool isn't capable of running the snapshot images anymore.
You might not have to go all the way back to JTAG. You definitely need the serial console, however.
With luck, you might still have access to u-boot and can replace the broken image via tftp. If you can't even access u-boot and get the dreaded BL2 error, you can follow the procedure here:
and can recover from a very bad flash using the serial console.
I used mtk_uartboot to boot the router and can login to busybox. What commands or steps I can use to fix the problem?
Thanks a lot!
Before we can launch into fixing the issues, we first need to see what damage has been done and what data and functions are available. Some of that information will show on boot without using the mtk_uartboot tool. For instance, if you can access the existing u-boot installation, then you might be able to skip over the steps of manually replacing the bootloader. I can't guarantee it's still there, but this becomes much easier if it is.
Also, a very important question: You did take a backup of the unit when you originally ran the OpenWRT installer, right? After all, the readme for the installer suggested it would be a good idea. If you did perform a backup and you do have access to the existing u-boot installation already on the device, then this process might be as simple as using tftp to replace and re-flash the damaged partitions with the known good copies.
If you didn't perform the backup or the onboard u-boot has been wiped out, then this is going to be a fair bit more complicated. First things first, you're going to want to review the rest of that topic in detail. Some other users have already posted the steps that they have followed to reload their devices and get them working properly again. Not all paths have yet resulted in success, but all of the information present is very valuable in knowing what to do and what not to do, and also how to get out of a jam if and when more mistakes get made.
This part of the process is still bleeding edge, and it probably isn't going to be a perfectly straight forward solution with one instruction guide that will fit all situations. Don't let yourself get overly frustrated by issues when they pop up. When it comes to finding the tips and tricks to get through and especially if you need help getting donor data in case your factory partition was wiped out, that other linked topic is going to be the best place to get help. There are a lot of talented people watching that topic, and they'll be able to review your screenshots and help you come to an answer.
Thanks @grauerfuchs and @daniel.
The good news is that I followed the steps for BL2 error you provided and succeeded making the router work again.
The bad news is when I tried to upgrade to the new layout using owrt-ubi-installer v1.1.1, I bricked it again. The possible reason is that I could flash the installer twice.
When I tried to fix it with above BL2 steps, I got fip not found error.
D:\R2>mtk_uartboot -p mt7622-2ddr3-bl2.bin -a -f openwrt-23.05.2-mediatek-mt7622-linksys_e8450-ubi-bl31-uboot.fip --brom-load-baudrate 115200 --bl2-load-baudrate 115200
mtk_uartboot - 0.1.1
Using serial port: COM3
Handshake...
hw code: 0x7622
hw sub code: 0x8a00
hw ver: 0xcb00
sw ver: 0x100
Baud rate set to 115200
sending payload to 0x201000...
Checksum: 0xce45
Setting baudrate back to 115200
Jumping to 0x201000 in aarch64...
Waiting for BL2. Message below:
==================================
NOTICE: BL2: v2.10.0 (release):v2.4-rc0-5845-gbacca82a8-dirty
NOTICE: BL2: Built : 20:10:09, Feb 2 2024
NOTICE: WDT: Cold boot
NOTICE: CPU: MT7622
ERROR: Cannot find any pass-window
ERROR: no DATLAT taps pass, DATLAT calibration fail!
ERROR: DATLAT calibration fail, write back to 20!
ERROR: EMI: complex R/W mem test failed: -2
NOTICE: WDT: disabled
NOTICE: Starting UART download handshake ...
==================================
BL2 UART DL version: 0x10
Baudrate set to: 115200
thread 'main' panicked at src\main.rs:122:10:
failed to open fip.: Os { code: 2, kind: NotFound, message: "The system cannot find the file specified." }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
I tried mtk_uartboot with uboot.fip from the snapshot and it can boot. After I got the Uboot menu, when I tried to flash the BL2, I got error
Error: ethernet@1b100000 No valid MAC address found.
Luckily, I can use mtk_uartboot to boot the router into recovery mode by holding reset button. During this mode, I can even login to the router through http and use winscp to upload files to the router.
https://raw.githubusercontent.com/CharlesMengCA/mpv-player-only/master/e8450/recover_mode.txt
Here is the debug information from bl2-for-debug-snand-issue.bin
Could you help me to solve the Error: ethernet@1b100000 No valid MAC address found. problem?
Or some manual steps to create/restore the those partitions before the v1.1.0 conversion?
Thans a lot. 
Ok, It looks like good news to me. It looks like it's recognizing the old partitioning scheme from the stable installation, so you may not have done any damage beyond the bad flashed .fip and the image itself. If you have http access to the recovery image, please use it to download a copy of your factory partition (mtd2?). You'll definitely want that in case things go bad again down the line.
Once you have your backup, you'll want to try using mtk_uartboot again but with the bl2 and .fip for the stable OpenWRT instead of the snapshot. The reason for this is that the newer bootloader and .fip expect the newer layout, and you don't yet have the updated layout. The other topic should have a link to the appropriate files you'll need to do so.
Once you have access to the u-boot console in a version compatible with the old layout, you'll need to use it to ensure the proper bootloader (this time from the stable, not snapshot) is flashed. You should then be able to use tftp to boot into the recovery for the stable OpenWRT. Assuming this goes through and it now has access to your factory partition (and MAC addresses), you should then be able to flash the 1.1.1 ubi installer and proceed as usual from there.
Thanks a million, @grauerfuchs.
I got it working again. Here are something I learned:
if we got this error
Error: ethernet@1b100000 No valid MAC address found.
We could choose console option from the menu, and on the console we can
setenv ethaddr 01:02:03:04:05:06
then run bootmenu to load the menu again to continue.
To catch the U-Boot menu, I used a batch file on windows to run mtk_uartboot and putty
@cls
mtk_uartboot -p bl2-mt7622-1ddr-ram.bin -a -f openwrt-mediatek-mt7622-linksys_e8450-ubi-bl31-uboot.fip --brom-load-baudrate 115200 --bl2-load-baudrate 115200
putty -load serial_config
Since I have to use the .fip from snapshot to work and I have the initial backup when I converted my router from factory to UBI, I tried to restore the factory firmware by following the instruction here: https://github.com/dangowrt/owrt-ubi-installer
ubidetach -d 0
insmod mtd-rw i_want_a_brick=1
mtd write /tmp/mtd0 /dev/mtd0
mtd write /tmp/mtd1 /dev/mtd1
mtd write /tmp/mtd2 /dev/mtd2
mtd write /tmp/mtd3 /dev/mtd3
mtd -p 0x200000 write /tmp/FW_E8450_1.0.01.101415_prod.img /dev/mtd3
This operation did not restore the router to its factory firmware but I could boot the router without using mtk_uartboot.
Now the U-Boot was from Linksys instead of OpenWRT. I chose to install the installer of v1.0.3 https://github.com/dangowrt/owrt-ubi-installer/releases/download/v1.0.3/openwrt-23.05.0-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery-installer.itb.
After loaded the file from tftp server and rebooted, the router finally can boot in to the recovery mode with the correct UBI layout.
And then, I flashed the regular sysupgrade.itb
After everything is OK, I followed the steps here to change to the new layout.
Step 1: Backup your configuration
Step 2: force flash https://github.com/dangowrt/owrt-ubi-installer/releases/download/v1.1.1/openwrt-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery-installer.itb
Step 3: flash sysupgrade image (no force needed)
Step 4: Restore configuration
I used v1.1.1 instead of v1.1.0 and didn't do the following step.
uci set system.@system[0].compat_version="2.0"
uci commit system
The router is working again with the latest snapshot.
Excellent. I'm glad all is well once more. However, one thing to keep in mind: The setenv ethaddr ... solution only works for as long as that u-boot environment remains. In other words, it's not exactly permanent. The original source of the MAC addresses is in the factory partition, along with radio calibration data and various other internal parameters. Therefore, the setenv is really a temporary and interim option until the factory partition can be restored. Your process restored that as well, so you should be good to go.
Do we need to apply that?
The only reason you'd need to apply that is if you have restored a config backup that was produced prior to the change of the compat_version, such as moving from 23.0x to today's snapshot. Although loading an older config would probably work in this situation with this device and with this specific change, you would do better to manually reconfigure as a matter of policy. After all, the compat_version flag usually changes as a result of updates that make the older configurations incompatible (such as when a device tree migrates to DSA).
You might need to apply that if you were using main/master snapshot and used the updated ubi installer 1.1.0+ to change partition structure, and have then restored your previous config.
(The restore has removed the compatibility string, so the next sysupgrade might complain about incompatibility.)
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.