Im so happy now, you saved my router daniel, super big thanks. <3
The factory partition was still ok.
3 Likes
Flip not sure what’s more impressive; the instructions or the following of them.
4 Likes
Thanks for your answer. Is there a written guide for re-running the installer somewhere?
Not sure if the instructions on Github is applicable to an existing OpenWrt installation 
1 Like
To move from OpenWrt v23.05.x or earlier to recent snapshots or the upcoming v24.10.0 release, you have to force-flash the unsigned v1.1.3 (or later) installer. If you want to keep your settings, keep a backup of your configuration as they are going to be lost when running the installer.
Either download https://github.com/dangowrt/owrt-ubi-installer/releases/download/v1.1.3/openwrt-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery-installer.itb and use that with the LuCI Firmware Upgrade UI. You will have to force-flash it and do not keep settings.
Alternatively you can also do this using SSH:
sysupgrade -n -F https://github.com/dangowrt/owrt-ubi-installer/releases/download/v1.1.3/openwrt-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery-installer.itb
After the installer has run, the device will boot into the recovery image and listen on 192.168.1.1. Now you can flash the snapshot sysupgrade.itb file.
If you restore your previous settings by replaying the configuration back file you need to make sure to also bump compat_version in order to be able to apply future sysupgrade:
uci set system.@system[0].compat_version='2.0'
uci commit system
13 Likes
Changing compat_version is enough meanwhile?
If, and only if (!), you did run the v1.1.3 (or later) installer and actually updated the bootloader. Then yes, that's all you need to do after replaying the config backup.
1 Like
First of all, thank you Daniel and Hnyman for your help. I was able to recovered 1 of the 2 OKD device via ssh. Now I bought a UART connector and wanted to recover the 2nd device. I am going over the Serial Recovery steps and also trying to get all the commands noted before I start the recovery process.
Just to recap and for my reference during the recovery process.
Step 1: Download https://downloads.openwrt.org/releases/22.03.0/targets/mediatek/mt7622/openwrt-22.03.0-mediatek-mt7622-linksys_e8450-ubi-preloader.bin
Step 2: Launch mtk_uartboot:
mtk_uartboot -s /dev/ttyUSB0 -p openwrt-22.03.0-mediatek-mt7622-linksys_e8450-ubi-preloader.bin -a ; screen /dev/ttyUSB0 115200
The above command seems to be for Linux. On macOS, should the below command be used instead?
./mtk_uartboot -a -p openwrt-22.03.0-mediatek-mt7622-linksys_e8450-ubi-preloader.bin -s /dev/cu.usbserial-B002EI6Z && screen /dev/cu.usbserial-B002EI6Z 115200
Step 3: Write correct bl2 image as described in the Wiki.
I assumed these are the steps?
-
Power on the RT3200 / E8450
-
mtk_uart should trigger a boot (if you never get past 'Handshake...' from mtk_uartboot, you have the wrong serial device selected, don't have a good serial connection, or - and this is the case for many people - your serial adapter may not be compatible and you should try another if your attempts fail repeatedly) and your screen / putty session should present you with a U-Boot menu. If you take no action for a number of seconds, your router will boot. To recover, you want to immediately press any key (like a down arrow) to interrupt the boot and stay on the boot menu.
-
From the boot menu, select the option
Load BL2 preloader via TFTP then write to flash.- Note that the current version automatically does the reflashing without further interaction, provided you have TFTP working. So, after the 4th “Writing 131072 byte(s) (64 page(s)) at offset 0x000600000” line everything should be ready. After reboot, the grep “(release)” /dev/mtd0ro command should give you v2.4 again.
Thank you so much.
Following on from this, I've now found what seems to be a backup on an old pc. What's my best way to restore this. I'm presuming it's a stock backup taken during install. Am I still best to hook it up to a serial console to see what's happening before trying this. The partitions below don't seem to line up with the before or after on the wiki though. Obviously this is a different type of bricke to the one people are generally trying to recover from. Thanks
These are the files I used, the git repo looks to have had the broken versions removed so I can't ID what version it was, I've still no idea what made it boot to stock either when I'm 90% sure I had flashed these files and used it on openwrt.
Why try to recover to stock rather than working OpenWrt?
Well I'm happy with either, I just wasn't sure if it was simpler to go back to stock than to OpenWRT and then start again given stocks the last thing that booted ok (although I'm still convinced I'd flashed and run ubi 23.05.0.
Now that the dust is settling on this issue, I wanted to get back to this post.
I'm a retired EE, PDE, PTA, blah, blah, blah from a Fortune 10. Most of my later career dealt with hardware or environmental issues and less with software. I think you have a valid concern here. I'm just playing with the e8450s as a solution to my need of DSA for VLAN transport for a house strung out across a mountain side. I only use these devices as WAP/VLAN behind a pfSense router. I picked up 8 or 9 of them, new still in the box and used. I currently have 4 in production and one more in the works. I've had pretty good luck but have seen some KOD/OKD and ONE that responded to the freezer trick. This suggested something else to me and not wanting to stir up any UL/FCC issues, I sat on it. Perhaps now is a good time to discuss my findings on this one unit. There is a significant amount of EMR emanating from these devices and depending on your environment, can lead to significant deposition tracking. This one freezer fix device had a significant amount of tracking. I have no idea of the source of this device (i didn't track my purchases that close) but safe to say it was a used item and not an NOS unit. Deposition of this sort can come from many sources - being near a Sea coast, cigarette or vaping in the house, wood burning stove smoke, construction (drywall/plaster deposits are especially nasty to electronic), even incense. I cleaned my boards with a grounded brush and isopropyl alcohol. I don't have ready access to the lab that was under my control anymore so I didn't test the residue. After cleaning, I used a polymeric conformal coating to alleviate any further chances of a deposition based failure. That unit went back into production and never had another KOD/OKD instance since July 3rd. I did not change any software or settings until this week. I did not try to go under the shield, I started here and saved that for the next instance.
That said, I have two units on my workbench that have full failure OKD witn no outward indication of power being turned on. Running a USB/TTL device I can see the devices are accepting power but getting the "Failed to load image id 5" output. I had pretty good luck doing 3 OKD recoveries with the old version of the recovery that is on the wiki but this new version with the TFTP service is kicking my ass. Does anyone have a copy of the older instructions? Or know another good write-up for OKD recovery?
Thanks for any help!
2 Likes
You bring up some really good points. It's fairly clear from my units that there was some residue left behind after soldering. No doubt there was some p**s-poor flux removal after assembly, and that definitely attracts a lot of unwanted deposits. The tracks in your image make it clear that someone in the factory didn't do a very good job in flushing the board clean of the residue after a very quick scrub.
As for the hardware issues, we did identify the underlying cause of it all. OKD itself was the logic bug in the software, but the logic bug became apparent due to a higher than expected rate of bit-flips on the NFI chip.
Sadly, you do need to get the repaired preloader to the device in order to fix the issue. However, there are a few options.
Troubleshooting and fixing the TFTP
First of all, the biggest issues I've noted with TFTP connections are to do with firewalls and with routing changes. Windows is notorious for it, but I've seen the problem on MacOS and Linux as well, especially if the network range happens to overlap with that provided by another interface. The easiest way around is to disconnect all other network connections, start the TFTP service, and then connect the affected router directly to the machine via any of the switch ports (1-4). If the router complains of an invalid MAC address, one can be provided via the U-Boot console with the command setenv ethaddr 01:23:45:67:89:AB where you substitute the real address for the one in the command.
Via serial + SSH
This method assumes the fip on flash is not corrupted. If too many bit flips have occurred, booting with this method may not work.
Although there's a specific payload described for use with the mtk_uartboot tool, you don't necessarily have to use that specific file. If you use the preloader from the OpenWRT firmware selector instead, it will effectively shim the broken boot component and then launch the FIP from the flash chip instead. Just make sure you select the proper preloader. In other words, if you're running 23.x, use the 22.x preloader. If you're running SNAPSHOT and all-in-UBI layout, you need the SNAPSHOT preloader. For this method, do not specify the -f {fip file} parameters to mtk_uartboot. Instead, allow OpenWRT to fully load and then proceed with replacing the preloader from a fully booted OpenWRT installation as listed on the wiki.
via serial + USB stick
Follow the instructions for 'Serial recovery' in the wiki up to the point of but not including selecting the 'Load BL2...' option in the boot menu. Instead, select the option to get to the U-Boot console.
Select a USB stick and format it as a single FAT32 partition.
Find the matching preloader file (from version 22.x for stable or SNAPSHOT for all-in-UBI) and place it on the root of the USB stick with the name openwrt-mediatek-mt7622-linksys_e8450-ubi-preloader.bin
Insert the USB stick directly into the router's USB port and issue the following commands:
usb start
fatload usb 0 $loadaddr $bootfile_bl2
run boot_write_bl2
Once you reset/reboot the router, it will automatically start up using the replaced boot preloader version.
2 Likes
Thanks, but the problem I am having is GETTING to the U-Boot console. I'm getting a full boot via the tftp load but the boot halt option isn't there long enough. I need to find the old version that just booted to the menu so you can select U-Boot console. Or, can I run the USB stick version from a full load and not from the U-Boot?
@daniel it may be nothing, but perhaps it's something. I recently picked up a couple brand new Linksys e8450's. The factory firmware is/was 1.1.x I believe. It was for sure less than 1.2.x as I used the unsigned installer to do the initial flash.
This morning, I am logging back into the unit for the first real time since converting it last night and I am following the steps to mount boot_backup, which I have already done and copied over the files. But, I only have 2 x files in there a mtd0 and mtd1, no 2 or 3. I searched this thread and did not see any other references to having just 2 files.
I used your script to build the installer, so I was using your latest 1.1.3 for the initial boot. Do you think I am fine to move forward with only 2 x files and call it a day, or perhaps there is something else at play? I have 5 x more units to convert eventually but will hold off until I hear back in the event something sounds out of place. In the meantime, I will leave the current unit up and running as it sits.
Thanks
Sadly, the OpenWRT versions always performed an autoboot on a short window. However, if you can do a full boot, you should be able to adjust the timing from OpenWRT using the fw_setenv command.
root@OpenWrt:~# fw_setenv bootdelay 10
root@OpenWrt:~# fw_setenv bootmenu_delay 10
Yes, you can load the file from the USB stick on a fully booted instance of OpenWRT, but you'll need to have the appropriate kernel modules for usb_storage and for the filesystem installed on the router to do so.
1 Like
Yes, you are all fine. The new version of the installer (and current OpenWrt snapshots as well as the upcoming v24.10 release) partition the flash chip in only two parts: bl2 and ubi. So all relevant flash areas previously covered by mtd0...3 are now covered only by mtd0...1. I have to update the instructions on the installer wiki to make that clear to everybody I guess...
1 Like
It can be tricky to get into the menu, but if you have the serial connected and your terminal program open before you turn it on, keep pressing and releasing the down arrow as fast as you can while you power-up using your other hand.
Also, if you're looking for older instructions on the wiki, you can browse through the previous versions using this link: https://openwrt.org/toh/linksys/e8450?do=revisions
Wasn't trying to be thick headed or anything 
Just wanted to check with you as I was coming in somewhat cold, so was going over your readme very carefully and that part stood out. I knew you did a lot of this work over the past few years, but didn't follow that close as I had none of these units until now.
The only other piece I guess I would add, and this part isn't your responsibility at all, but in the wiki portion of imagebuilder prereqs namely for Ubuntu, the latest versions of Ubuntu and Ubuntu variants are using Python 3.12 which is behaving quite differently from previous versions. Outside of having to delete a file to avoid having python as externally managed, the wiki also calls out to install python3-distutils as a prereq. This no longer exists in 3.12 and is instead replaced by a pip module setuptools.
Again, none of that has anything to do with you directly, but that was my only other head scratcher .
Thanks for the confirmation that mtd0 and mtd1 are expected moving forward and thanks for all the work you do!
Hans
1 Like
Thanks, that helped... but really didn't get me anywhere. The new version of the Serial fix using the tftp server borks something. With those changes, I would get the "Hit any key to stop autoboot:" but when I did, the screen went black and I got a green block cursor about 2/3 the way down the screen but not the menu. Never got the boot menu to select U-boot. Many seconds later it would pick up the full boot sequence in mid stream. Weird
I did find a screen print I had taken of the OLD recovery process without the TFTP server and was able get a better load via serial.
My issue with the full load is it was not fully working well on the network - wouldn't allow a connection to opkg for some reason. I spun up an opkg relay on my debian laptop and got the kmod-mtd-rw to load and then was able to rewrite the mtd0. All is well with that one, now onto the last one...
My last OKD'd device should be working, but it's not. It shows the TF-A as "v2.10.0 (release):OpenWrt v2024.01.17~bacca82a-3 (mt7622-snand-ubi-1ddr)"
but still won't show any signs of life on it's own. May go the same route as above.
Whoever is in charge of the wiki for the e8450 really should put the original process back up as it worked better for those of us who don't run full routers. Give folks a choice rather than assuming the TFTP option is best. Do you know who that is?
The problem with the original process is that it was purely a stop-gap. It didn't actually fix anything, but only re-wrote the section that had the flipped bits. As long as the data was still readable and correctable, it would temporarily allow the router to boot. The NFI chip would still eat another bit down the line and then it's back to the beginning again.
When you get the 'hit any key' message, do so. Sadly, it sounds like your terminal program wasn't properly handling or displaying the ANSI sequences that the menu is based upon. However, if you simply hit key '0' here, that is usually the command to bring you to the U-Boot console.
I suspect your opkg rejection might be due to the date and time causing the SSL certificate to be treated as invalid. I ran into that a number of times a while back while troubleshooting issues and performing bench tests. It's also possible that the router didn't have an internet-facing IP, default gateway, and/or DNS server applied and so it couldn't get the address at all.
Your last OKD'd device with v2.10.0 on it - That version was only ever officially released for SNAPSHOT / OpenWRT 24.10.x. If your router has the stable or older layout, that version wouldn't work unless custom compiled specifically for the stable layout. Either way, you should see something on the serial console that can point to where the problem is.
2 Likes