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:
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.
I disassembled the router to gain access to the JTAG port, and I wired up a USB to serial converter as was specified.
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.
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?
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.
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:
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.
The recipient device may not perform as well as it had previously performed, since the calibration and tuning data are no longer correct.
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).
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.
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.
I hosed my RT3200. I think by running the upgrade twice. Stuck at ERROR: BL2: Failed to load image id 3 (-2)
When I run the mtk_uartboot -a -s COM51 -p mt7622-ram-1ddr-bl2.bin -f openwrt-23.05.3-mediatek-mt7622-linksys_e8450-ubi-bl31-uboot.fip && putty.exe -serial COM51 -sercfg 115200,8,n,1,N
I do not get a functional ethernet. So I have kermit and a lot of time....
mtk_uartboot is a command line program. It doesn't have a graphical interface. You'll need to run it from a command prompt window. If your computer is missing something the program needs, it should tell you what is missing in that command prompt window.
