My Linksys E8450 has been kissed by Death and I may have borked it more when trying to fix it

My router appears to have fallen victim to the OKOD (OpenWRT Kiss of Death). It was power cycled, but did not boot — no lights came on. I tried following this guide, but I, unfortunately, can't get it to work, and I'm not entirely sure what I am doing wrong. The following is what I have done so far, and what I observed:

  1. I downloaded mtk_uartboot.
  2. I downloaded the bl2-for-mtk_uartboot.bin file.
  3. I downloaded the .fip file.
    • This is where I ran into some trouble. I couldn't remember if I ran the v1.1.1 UBI installer. The guide mentioned that there were two versions of the file, one for having ran the installer, and one for having not ran the installer. As I was unsure, I just went for the one where I hadn't ran the installer, i.e. the release version.
  4. I disassembled the router to gain access to the JTAG port, and I wired up a USB to serial converter as was specified.
  5. I ran the following command in one terminal:
# ./mtk_uartboot -a -p bl2-for-mtk_uartboot.bin -f *uboot.fip && screen /dev/ttyUSB0 115200
  1. I turned on the router, and I observed the following output in the terminal:
mtk_uartboot - 0.1.1
Using serial port: /dev/ttyUSB0
Handshake...
hw code: 0x7622
hw sub code: 0x8a00
hw ver: 0xcb00
sw ver: 0x100
Baud rate set to 460800
sending payload to 0x201000...
Checksum: 0xdac6
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
NOTICE:  BL2: Built : 19:21:54, Mar  1 2024
NOTICE:  WDT: Cold boot
NOTICE:  CPU: MT7622
NOTICE:  WDT: disabled
NOTICE:  Starting UART download handshake ...
==================================
BL2 UART DL version: 0x10
Baudrate set to: 921600
FIP sent.
==================================
NOTICE:  Received FIP 0xf914c @ 0x40400000 ...
==================================
[screen is terminating]
  1. As soon as that command finished, I immediately opened up a separate terminal and ran
# screen /dev/ttyUSB0 115200
  1. Now seeing the U-Boot menu, I immediately hit the down arrow to prevent a boot, and scrolled down to 0. U-Boot console
  2. I type in mtd read fip $loadaddr 0x0 0x140000 && mtd write fip $loadaddr 0x0 0x140000 and hit enter.
  3. I then type boot and hit enter. The router boots.
  4. I hit enter to show the TTY.
  5. Thinking that the issue is fixed, I then type reboot. The device starts to reboot.
  6. I observe the following output:
root@OpenWrt:/# reboot
root@OpenWrt:/# [   93.975595] device lan1 left promiscuous mode
[   93.980075] br-lan: port 1(lan1) entered disabled state
[   94.008616] device lan2 left promiscuous mode
[   94.013228] br-lan: port 2(lan2) entered disabled state
[   94.058641] device lan3 left promiscuous mode
[   94.063228] br-lan: port 3(lan3) entered disabled state
[   94.119123] device lan4 left promiscuous mode
[   94.123667] br-lan: port 4(lan4) entered disabled state
[   94.173309] device eth0 left promiscuous mode
[   94.311181] mtk_soc_eth 1b100000.ethernet eth0: Link is Down
[   98.482278] reboot: Restarting system

F0: 102B 0000
F6: 0000 0000
V0: 0000 0000 [0001]
00: 0000 0000
BP: 0400 0041 [0000]
G0: 1190 0000
T0: 0000 02D7 [000F]
Jump to BL

NOTICE:  BL2: v2.9(release):OpenWrt v2023-07-24-00ac6db3-2 (mt7622-snand-1ddr)
NOTICE:  BL2: Built : 21:45:35, Oct  9 2023
NOTICE:  CPU: MT7622
NOTICE:  WDT: [40000000] Software reset (reboot)
NOTICE:  SPI-NAND: FM35Q1GA (128MB)
ERROR:   BL2: Failed to load image id 3 (-2)
  1. Thinking that I flashed the wrong .fip file, I redo steps 3-8 after having downloaded the snapshot version.
  2. In the U-Boot console, I type in the following
ubi remove rootfs_data ; ubi read $loadaddr fip && ubi write $loadaddr fip $filesize
  1. I observe the following output:
Remove UBI volume rootfs_data (id 5)
Volume fip not found!
  1. A reboot shows the same issue:
F0: 102B 0000
F6: 0000 0000
V0: 0000 0000 [0001]
00: 0000 0000
BP: 0400 0041 [0000]
G0: 1190 0000
T0: 0000 02D7 [000F]
Jump to BL

NOTICE:  BL2: v2.9(release):OpenWrt v2023-07-24-00ac6db3-2 (mt7622-snand-1ddr)
NOTICE:  BL2: Built : 21:45:35, Oct  9 2023
NOTICE:  CPU: MT7622
NOTICE:  WDT: [40000000] Software reset (reboot)
NOTICE:  SPI-NAND: FM35Q1GA (128MB)
ERROR:   BL2: Failed to load image id 3 (-2)

I'm not entirely sure what else to do. I don't know what the exact problem is, and I'm not sure how else to troubleshoot it. The router is effectively bricked at the moment.

From the fact that it did boot after the first time around, it looks like you did have the stable version installed but it wasn't properly corrected by running the mtd commands.

Things went very wrong when you ran the wrong fip. Using the wrong fip effectively overwrites most of the router's flash when it attempts to establish a U-Boot environment partition. That means your calibration data and factory partition are gone, as is everything else on the router.

The good news: It's recoverable as long as you had previously taken a backup of the factory partition. As this data is not part of the standard OpenWRT backup, you would have had to take it separately. Since the UBI installer instructions strongly recommend doing so, I do hope you followed those instructions. Without the data in that partition, you'll only get a partial recovery.

Other users have gone through similar. One of those chains is present in the following topic: https://forum.openwrt.org/t/linksys-e8450-failed-to-boot-after-reboot/

That topic contains a record of diagnosis and steps to effectively re-write the router to the same level as is required here.

1 Like

From the fact that it did boot after the first time around, it looks like you did have the stable version installed but it wasn't properly corrected by running the mtd commands.

It's always able to boot, no matter what version I install — that is, if I run boot from the U-Boot console. It just doesn't boot if I run reboot from the router TTY (it shows that ERROR: BL2: Failed to load image id 3 (-2) message).


That means your calibration data and factory partition are gone, as is everything else on the router.

Ah, yeah, I expected as much. It's fine — I have no problem with starting fresh; I just want the router working again.


The good news: It's recoverable as long as you had previously taken a backup of the factory partition.

I do not. Or, if I do, I don't know where it would be. I don't recall making that backup. Perhaps I didn't think I was supposed to hang on to it (it's possible that I only thought that I had to hold on to it should the initial instillation of OpenWRT go sour).

When you say "recoverable" do you mean the previous data, or do you mean the entire router to a functioning state?


Other users have gone through similar. One of those chains is present in the following topic: https://forum.openwrt.org/t/linksys-e8450-failed-to-boot-after-reboot/

I did take a look through this thread, and it does seem to be quite involved. I'm not 100% sure where I am supposed to start.


Is it possible to simply flash it to a stock OpenWRT state? I don't mind if I lose all the configuration and data that is on the router. My primary interest, currently is to simply have the router functional again.

The factory partition content is unique to the device and it contains your MAC addresses and the wifi chip EEPROMs. Although it's possible to boot without a valid factory partition, the wifi will not work properly (maybe not at all), the MAC addresses are prone to changing after a reboot, and any attempt to run one of the UBI installers will once again result in trouble because they can't proceed without the partition being present and verified.

The steps in that thread start with assessing the state of the broken router, but all of the instructions for getting back to the stable OpenWRT are present. However, it still relies on you having and restoring the data from your factory partition.

In short, you need a TFTP server (U-Boot expects it to be at 192.168.1.254), the router must be connected to it (the router is 192.168.1.1 by default), and it requires the BL2, BL31-UBOOT, and KERNEL files shown in the OpenWRT firmware selector. The files must all be properly named and present on the TFTP server. The steps in that thread will bring you back to the stable UBI version, not the snapshot or non-UBI versions.

The restoration excluding factory partition is present at Linksys E8450 failed to boot after reboot - #68 by grauerfuchs

If you can find a factory partition for this model router somewhere out there (I haven't seen one publicly posted), the instructions to restore and offsets for fixing the MAC addresses are also present in that thread, a few posts above the restoration of OpenWRT. Do not substitute a factory partition from a device of a different model. It has to be from the same model router.

The factory partition content is unique to the device and it contains your MAC addresses and the wifi chip EEPROMs.

Ah, so even if I were to buy another Linksys E8450, I wouldn't be able to use it's factory partition to replace the broken router's one (because you mentioned that it is unique to the device)? Or if I could use the factory partition from another device, I would guess that, since it's unique, only one can exist at a given time?


If you can find a factory partition for this model router somewhere out there (I haven't seen one publicly posted), the instructions to restore and offsets for fixing the MAC addresses are also present in that thread, a few posts above the restoration of OpenWRT. Do not substitute a factory partition from a device of a different model. It has to be from the same model router.

I'm somewhat confused now. Perhaps I am misunderstanding what you meant by "unique to the device". I was under the presumption that you meant that it's tied to the hardware that it came with from the factory.

Some of the data present in the factory partition and in the wifi eeproms are indeed specific to the device. However, that device-specific data is the MAC addresses, and the wifi tuning and calibration data. Although in many cases you can take a factory partition from a donor device and run it on the failed (recipient) device, there are some limitations:

  1. You must properly adjust the MAC addresses before loading the data onto the failed router, or you will have a MAC address conflict should you attempt to connect the donor and recipient devices both to the same network.
  2. The recipient device may not perform as well as it had previously performed, since the calibration and tuning data are no longer correct.
  3. The donor device and recipient device must use the exact same hardware configuration (i.e. be the same model device or another brand's exact equivalent such as the Linksys e8450 and Belkin RT-3200).
1 Like

From the fact that it did boot after the first time around, it looks like you did have the stable version installed but it wasn't properly corrected by running the mtd commands.

Out of curiosity, for my own future education, what information, exactly, lead you to the fact that I nuked the factory partition? How did you know that the first one didn't, but the second one did? You mentioned that it was because it booted, but it boots in both cases (If I run boot from the U-Boot command line). The only time that it doesn't boot, and, instead throws that error, is when I run reboot from the OpenWRT CLI. If I were to use the "release" version again, it would still boot from the U-Boot command line — it just never seems to be able to reboot from the OpenWRT CLI.

When running from mtk_uartboot, you provide a substitute BL2 and fip (includes BL31 and U-Boot). It also contains a reference to the mtd layout, and that is necessary for the device to know where to look in order to boot from the installed firmware image. Your set of steps shows that it booted properly with the stable layout, which means that the mtd lookup table was correct enough for it to find where the UBI section started, that it had the proper signature in the proper location, and that it had the proper volume from which to boot. When you ran the fip for the snapshot, it contains a different mtd layout. This becomes a problem because the U-Boot for this device is configured to use UBI for its environment.

When U-Boot starts, it immediately looks for the presence of its environment data. When you provided the wrong fip, the UBI offset is different. The UBI signature is not found, and therefore neither the environment volume nor its secondary environment volume are found. U-Boot then tries to create its environment volume, which triggers creation of the UBI data structures at the new offset, and that involves formatting the newly assigned flash area.

From past experience and past testing (including that topic thread already linked), review shows that when the wrong fip is used, the area that previously contained the factory partition now contains something else. You can verify this for yourself. First of all, run the command ubi list. If the 'factory' volume isn't listed there, it won't be accessible under the snapshot layout. Now, try mtd dump spi-nand0 0x1c0000. That command performs a direct read and display of the data starting at the address used for the MT7622 EEPROM under the stable firmware's e8450-UBI layout. An MT7622 EEPROM has its own signature, the first two bytes reading 22 76. The data layout for this device then has two more bytes (02 00 from the devices I've looked at) and then the MAC address for the 2.4G wifi radio. If the values differ, then the data has been corrupted or wiped out.

1 Like

When I run ubi list I see the following:

0: ubootenv
1: ubootenv2
2: recovery
3: boot_backup
4: fit
5: rootfs_data

Running mtd dump spi-nand0 0x1c0000 shows the following at 0x1c0000:

0x001c0000: 55 42 49 23 01 00 00 00 00 00 00 00 00 00 00 01

So yeah, it appears to be overwritten. Quite unfortunate.

It happened again for my unit. Background: switched off the router as we are going for holidays. When return and upon switch on the power there's no light activity in the router. This time around I recovered quite easily just with these couple of code.

mtk_uartboot -a -s COM3 -p bl2-for-mtk_uartboot.bin -f openwrt-23.05.3-mediatek-mt7622-linksys_e8450-ubi-bl31-uboot.fip && putty.exe -serial COM3 -sercfg 115200,8,n,1,N

mtd read fip $loadaddr 0x0 0x140000 && mtd write fip $loadaddr 0x0 0x140000

I think this issue probably contributed by power supply unit, same pattern previously. So I bought 12v, 2a power supply. Hope it doesn't happen again.