Recovering non-bootable Linksys E8450 OEM OS / OpenWRT without installer

Installing and Using OpenWrt
1

I'm working on a Linksys E8450 that I just opened the package. Unfortunately it's not able to boot to the OEM Linksys OS, so I haven't been able to run the OpenWRT installer. Looking at the boot log via UART, I see:

SQUASHFS error: xz decompression failed, data probably corrupt

Followed by an endless loop of stack dumps. I've tried booting to both the main and secondary boot options in the UBoot menu, and both result in similar boot failures.

I was also trying to make a full dump of the nand chip before installing OpenWRT, using this process (the OEM Uboot is very restrictive so this is the only option):

# Zero the memory area
MT7622> mw.b $loadaddr 0x00 0x8001000
# Read nand into memory
MT7622> nand read $loadaddr 0x0 0x8000000
# Dump memory to log file captured by terminal program
MT7622> md.b $loadaddr 0x8000000

I'm able to convert the dumped log back into a binary with post-processing scripts, and have done this before with other devices.

However, on this device I get these errors (which I don't understand) when reading the nand chip. I'm also not sure if it's actually completing the read, or if I can bypass this using read.raw:

MT7622> nand read $loadaddr 0x0 0x8000000
NAND read: device 0 whole chip
[mtk_snand_check_bch_error] ECC-U, PA=5564, S=3
NFI, flag byte: ff NFI, flag byte: ff NFI, This page is empty!
[mtk_nand_exec_read_page]mtk_snand_check_bch_error() FAIL!!!
[mtk_snand_check_bch_error] ECC-U, PA=12928, S=3
NFI, flag byte: ff NFI, flag byte: ff NFI, This page is empty!
[mtk_nand_exec_read_page]mtk_snand_check_bch_error() FAIL!!!
[mtk_snand_check_bch_error] ECC-U, PA=20202, S=3
NFI, flag byte: ff NFI, flag byte: ff NFI, This page is empty!
[mtk_nand_exec_read_page]mtk_snand_check_bch_error() FAIL!!!
[mtk_snand_check_bch_error] ECC-U, PA=21370, S=3
NFI, flag byte: ff NFI, flag byte: ff NFI, This page is empty!
[mtk_nand_exec_read_page]mtk_snand_check_bch_error() FAIL!!!
[mtk_snand_check_bch_error] ECC-U, PA=21935, S=3
NFI, flag byte: ff NFI, flag byte: ff NFI, This page is empty!
[mtk_nand_exec_read_page]mtk_snand_check_bch_error() FAIL!!!
NAND read from offset 0 failed -74
 0 bytes read: ERROR

Both of these issues seem to point to corruption somewhere.

One thought I had was to extract the Factory partition and then manually install an OpenWRT image through mtk_uartboot. The OEM bootlog shows this location for the Factory data:

0x0000001c0000-0x0000002c0000 : "Factory

So I ran a dump and converted it to binary (luckily it's not in the corrupted area):

# Read flash into RAM
MT7622> nand read $loadaddr 0x1c0000 0x100000
# Dump RAM to screen (save to log)
MT7622> md.b $loadaddr 0x100000

Comparing it to another device factory dump (mtd2), it seems to be correct as there are only minor differences between the files (MAC address, etc.).

I'm hoping to get some input on whether I'm going in the right direction, or do the above errors point to this device being already beyond repair? Or do you have some other ideas on how to recover it?

2

You're headed in the right direction. It definitely looks like the chip has hard-failed in at least a few pages, but the fact that you're getting a good read back on the region of the factory data suggests you might be able to recover. You may only need to replace the recovery and production firmware images. This is easily handled via the U-Boot boot menu, where all you'll need to do is set up a TFTP server to pass the proper images to the device.

3

Is it unusual that these blocks don't show as bad in u-boot?

MT7622> nand bad
Device 0 bad blocks:

Would it make sense to manually mark them as bad using nand markbad?

Is there a way to tell what address should be marked bad from the error message? I'm assuming the PA= number is probably the bad address.

It looks like this error is coming from https://android.googlesource.com/kernel/mediatek/+/android-mediatek-pike-3.10-marshmallow-mr1-wear-release/drivers/misc/mediatek/nand/mt2601/mtk_snand_k.c line 1134, which seems to uphold that theory. However, does the page address need to be multiplied by the page size (2048) to get the correct offset address for nand markbad?

My goal is to get this to a working OEM installation before then installing OpenWRT.

4

It could still be a number of things going on, but I've had a few ideas since the initial post. If I recall correctly, there was something said about this device not properly handling or managing ECC data. If so, then the errors could be bunk. You're right, the OEM U-Boot is quite restrictive. However, there's a slim possibility if you're willing to take a few risks.

I had compiled a version of U-Boot for this device compatible with OpenWRT 23.05 and configured to not initialize the UBI area or automatically boot. Since the data layout between 23.05 is partially compatible with stock and it was built with debugging and recovery in mind, it gives you a few more options. I think I enabled the TFTP put option, but I know it has fatload and fatwrite enabled so it can utilize USB flash drives. I don't have a guide for doing this and I haven't used this method to do so, but it could potentially be used in combination with mtk_uartboot and the flash offsets to back up the data from the stock partitions. I've included the list from what I was able to decode below.

https://github.com/grauerfuchs/owrt_device_support/raw/refs/heads/main/linksys-e8450-foxed-for-openwrt-23.05-noinit.fip

part____name________start_______end_____________length__________________
mtd0    Preloader   0x00000000  0x0007FFFF      0x00080000 (512KiB)
mtd1    ATF         0x00080000  0x000BFFFF      0x00040000 (256KiB)
mtd2    Bootloader  0x000C0000  0x0013FFFF      0x00080000 (512KiB)
mtd3    Config      0x00140000  0x001BFFFF      0x00080000 (512KiB)
mtd4    Factory     0x001C0000  0x002BFFFF      0x00100000 (  1MiB)
----    reserved   
mtd5    Devinfo     0x00300000  0x0031FFFF      0x00020000 (128KiB)
mtd6    senv        0x00320000  0x0033FFFF      0x00020000 (128KiB)
----    reserved
mtd7    bootseq     0x00360000  0x0037FFFF      0x00020000 (128KiB)
----    reserved
mtd8    Kernel1     0x00500000  0x022FFFFF      0x01E00000 ( 30MiB)
mtd12   Kernel2     0x02300000  0x042FFFFF      0x02000000 ( 32MiB)
----    reserved
mtd13   mfg         0x05A00000  0x079FFFFF      0x02000000 ( 32MiB)
-----------------------------------------------------------------------
SNAND   WHOLEFLASH  0x00000000  0x08000000      0x08000000 (128MiB)