Hi, I was just installing OpenWrt to a refurb Linksys E8450. It had vendor firmware 1.1.01.272918. It didn't like the unsigned installer-v1.1.3 firmware [1], it spun when trying to downgrade to FW_E8450_1.0.01.101415_prod.img [2], so I tried the signed installer v1.1.3 firmware [3]. However, when it rebooted, I get:
F0: 102B 0000
F6: 3800 00A1
F3: 4000 0036
F5: 480A 0031
F5: 480A 0031
00: 1005 0000
F6: 3800 00A1
F3: 4000 0036
F5: 480A 0031
F5: 480A 0031
01: 102A 0001
02: 1005 0000
BP: 0000 00C0 [0001]
T0: 0000 0664 [000F]
System halt!
and nothing else. I found the other forum thread (now closed): Need help with a bricked LinkSYS E8450, which will likely lead me to a JTAG solution. However, for now I'm putting it on a "recover later" pile. I just wanted to report this observation in case it helps someone else.
And if anyone has clues what went wrong, I'd welcome the input.
[1] sha256sum: 3cb5f040edf1bc330f31c4d414f1209760c4eb99f492f48b1494179b2885466f
[2] sha256sum: 013732d081e439a6ad030f5ebd031a6498c5ad3943a75fc322664186c0005427
[3] sha256sum: 0679ba15a461e13c45c20829d3450abf108f762ae03a03757a68aed5f65c1597
Here's the console log where things went sideways.
Whoops. Yes, that's pretty bad. What you're seeing is the output from the hard-burned BL1 stage of the boot process screaming in misery because it can't find the preloader (BL2) stage that is supposed to reside at the start of the flash chip.
The good news: You don't need JTAG. Thankfully, with the assistance of some excellent coders, you can recover this device with a simple USB to UART (3.3v) cable and a few pieces of software. Since you were planning on running OpenWRT, nearly all of the code you need is already available.
I'm going to go under the assumption and hope that the factory partition is intact, because it hopefully didn't get damaged when the code went wrong. Your pastebin log shows that the 1.1.3 installer did run, but it encountered some anomalies. Given the flash chip, it's not a surprise. I'm going to guess that a new bad block developed without detection at the worst possible time and in the worst possible place (the bl2 area).
You should be good to follow the 'serial recovery' instructions on the wiki for this device, and use that to replace the preloader (bl2) with a complete and intact copy. Once you've written the 24.10-compatible preloader, hopefully that's all this router will need.
The mtk_uartboot command line is getting me to a u-boot (i'm using files I downloaded and used back in August 21, 2024), but if I drop to a u-boot shell, I'm getting errors where u-boot thinks ubi lives on mtd2, but my mtd look like this:
MT7622> mtd list
List of MTD devices:
- spi-nand0
- device: snand@1100d000
- parent: root_driver
- driver: mtk-snand
- path: /snand@1100d000
- type: NAND flash
- block size: 0x20000 bytes
- min I/O: 0x800 bytes
- OOB size: 64 bytes
- OOB available: 28 bytes
- ECC strength: 4 bits
- ECC step size: 512 bytes
- bitflip threshold: 3 bits
- 0x000000000000-0x000008000000 : "spi-nand0"
- 0x000000000000-0x000000080000 : "bl2"
- 0x000000080000-0x000008000000 : "ubi"
and
MT7622> ubi list
Error, no UBI device selected!
MT7622> ubi part ubi
ubi0 error: ubi_early_get_peb: no free eraseblocks
ubi0 error: ubi_attach_mtd_dev: failed to attach mtd2, error -28
UBI error: cannot attach mtd2
UBI error: cannot initialize UBI, error -28
UBI init error 28
Please check, if the correct MTD partition is used (size big enough?)
Is it safe to tftp the preloader (openwrt-mediatek-mt7622-linksys_e8450-ubi-preloader.bin) and write it into mtd0 via the "Load BL2 preloader via TFTP then write to flash" menu?
Uh oh, hmm:
MT7622> tftpboot $loadaddr $bootfile_bl2
Error: ethernet@1b100000 No valid MAC address found.
Error: ethernet@1b100000 No valid MAC address found.
Error: ethernet@1b100000 No valid MAC address found.
Error: ethernet@1b100000 No valid MAC address found.
Error: ethernet@1b100000 No valid MAC address found.
Error: ethernet@1b100000 No valid MAC address found.
Error: ethernet@1b100000 No valid MAC address found.
Error: ethernet@1b100000 No valid MAC address found.
No ethernet found.
Error: ethernet@1b100000 No valid MAC address found.
Error: ethernet@1b100000 No valid MAC address found.
Looks like it's trying to load the macaddr from a partition that's already been moved to ubi, but ubi isn't working yet? Is there a way to override that from the u-boot command line?
I think you're using the wrong .fip file with mtk_uartboot. U-Boot doesn't actually know where the data lives; It relies on a mapping provided within the environment, and this data is also hard-coded into the compiled binary. If you are using a FIP containing U-Boot that was compiled for 23.05, it will have the wrong data.
Now if the installer did as the posted log suggests it has done, the data is no longer at the 23.05 offsets. Therefore, you need to use the FIP built for 24.10.0 instead. This updated FIP is available from the firmware selector.
MT7622> set ethaddr xx:xx:xx:xx:xx:xx
was the trick. But now, this looks like maybe my problem?
MT7622> run snand_write_bl2
Erasing 0x00000000 ... 0x0007ffff (4 eraseblock(s))
Skipping bad block at 0x00000000
Skipping bad block at 0x00020000
Skipping bad block at 0x00040000
Skipping bad block at 0x00060000
Writing 131072 byte(s) (64 page(s)) at offset 0x00000000
Oh, that's not good at all. The entire area defined for BL2 and its backups is marked bad. Your flash chip appears to be toast.
Sadly, this is a game-ender for most people. There are a few possible solutions still, but this gets deep into the weeds. It's possible to:
- Unmark the blocks, thereby allowing the device to try again.
- Custom compile OpenWRT, using different data offsets, thereby bypassing the bad blocks.
- Replace the flash chip.
Each option has big downsides.
To do option 1, you'll first need to offload and safeguard the factory data because it's unique to the router and cannot be replaced. You'll then need to wipe the whole chip, resetting the bad block flags, and then re-write all data in hopes that one or more of those bad sectors isn't really bad.
To do option 2 requires manual changes and manual recompilation and complete lack of compatibility with everyone else.
To do option 3 requires the same backup you need for option 1, and it also requires getting your hands on a compatible chip as well as performing the surface-mount soldering.
I tried all the fip's: the one I had from August 2024 (strings says "v2.10.0 (release):OpenWrt v2024.01.17~bacca82a-3 (mt7622-snand-ubi-1ddr)"), the current 24.10.1, and the snapshot from 2025-05-15. Same behavior.
At this point, the FIP no longer matters. It'll never get to that stage, since it needs the BL2 in order to load the FIP. Since there's nowhere to put the BL2, it can't boot.
Any pointers on option 1? And/or how to attach mtd1 as ubi instead of mtd2? That would make it easier to backup the data that's presumably already been stashed away.
Do not attempt any further writes to the device at this time. Because of the way bad blocks are handled (uses the next available block), trying to write could result in loss of data because it will overrun the partition markers. Sadly, it's possible the factory data is already lost. However, it may not be; It's going to take a bit more research to be sure. However, what I know is that you need the FIP for 24.10 because the router is in the 24.10 layout. Since the FIP contains the proper U-Boot, this will make sure it has the proper offsets for the partitions.
The process:
You'll need to use mtk_uartboot to bootstrap the device to reach a stage where you are able to verify the existence or lack thereof of the factory data in UBI, and then extract that data to an external medium if it's still intact.
Once the data has been safeguarded, you'll need to reboot back into U-Boot via mtk_uartboot and issue the command to erase the entire flash chip including bad blocks. You'll then need to retry the write of BL2 and then reconstruct the UBI partition, upload and create the FIP and Factory data volumes, and then do the same for the recovery and production firmwares.
The instructions:
This is going to take a bit of work to figure out the safest way to accomplish the tasks. I'll have to get back to you on this.
the fip for 24.10.1 (that is: https://downloads.openwrt.org/releases/24.10.1/targets/mediatek/mt7622/openwrt-24.10.1-mediatek-mt7622-linksys_e8450-ubi-bl31-uboot.fip), is still looking for mtd2 for some reason.
MT7622> ubi part ubi
ubi0 error: ubi_early_get_peb: no free eraseblocks
ubi0 error: ubi_attach_mtd_dev: failed to attach mtd2, error -28
UBI error: cannot attach mtd2
UBI error: cannot initialize UBI, error -28
UBI init error 28
Please check, if the correct MTD partition is used (size big enough?)
Also,
nand bad
gives me a prodigious list of addresses, something like 1024 blocks, times 128k per block. That sounds remarkably like every block. I just checked the wiki page for the device, and yeah, 128MB of nand flash.
This is not a terrifying loss. It was a refurb, only $35, and I have a stack of others. I guess the main thing that would still be good to know is how did it happen and how do I avoid it happening again?
This sounds like it's loaded a bad uboot environment ...which it shouldn't have been able to do because that data is on flash at a different offset between 23.05 and 24.10. I suspect something very weird is going on here. If I'm correct, then the data might still be intact and potentially even in the factory layout, protected because the blocks were marked as bad before things ever got updated.
I think it very unlikely that all of the blocks really have gone bad at the same time. It's possible the chip may be good even if it's suffering from a minor case of bit-rot, but the differences in the way bad blocks are handled and detected may be to blame here. If that's the case, then we can reset it and things will work once more afterward. First, we need to try to find and retrieve the factory data. Give me a little bit of time here; I need to come up with some tests and numbers that can be used regardless of what U-Boot thinks are the proper mtd partitions.
Ok. First, let's see if the factory data is still in its original position. From U-Boot, issue the command:
mtd dump spi-nand0 0x1C0000
This will read back the page of flash data at the original offset. If it's the factory data, the first line should start with 22 76 02 00 and then the MAC address of the 2.4GHz radio. If it's something else, please post the first few lines returned.
Thank you for your help. It's sleepy time and I may need to wait a couple days for another JST wiring harness to show up.
Understood. Pleasant dreams. May the future bring opportunity and not strife.
MT7622> mtd dump spi-nand0 0x1C0000
Reading 2048 byte(s) (1 page(s)) at offset 0x001c0000
And, that's all I get back. Seems to hang there indefinitely.
That's with bl2: "v2.10.0 (release):OpenWrt v2024.01.17~bacca82a-3 (mt7622-ram-1ddr)" and fip: "v2.10.0 (release):OpenWrt v2024.01.17~bacca82a-3 (mt7622-snand-ubi-1ddr)"
I now have a sufficient enough supply of uart pigtails, I shouldn't have to keep stealing the one out of this problematic device.
Modern Linksys routers have dual firmwares, did you try to boot into the other firmware first?
Heh. I do appreciate the helping spirit, but check the wiki page for the device and the installation instructions and then re-read the whole thread for a fuller understanding of the problem at hand.