Belkin RT3200/Linksys E8450 WiFi AX discussion

[daniel]

@ghoffman

by reading the recent (2-3 weeks) flurry of actiivy about bricked/failed devices, this is a recent probelm related to the change ubi installer / mtd allocations..

The news is probably the new possibility (mtk_uartboot being published on March 1st) to unbrick devices -- no matter how long they have previously been sitting on a shelf waiting to be de-bricked via JTAG (which is more complicated which is why many users didn't do it).

@ghoffman

this is a recent probelm related to the change ubi installer / mtd allocations..

I deliberately waited until mtk_uartboot was available before working on the updated (and more robust!) flash layout and installer. So this is not a coincidence.

@ghoffman

i - and others - have searched these forums and there is clear series of posts that describes the steps which are necessary to recover, including which specific files and commands.

The files you need to use for recovery depend on which layout was used when the router turned into a brick.
In order to simply recover the device, you always need bl2-for-mtk_uartboot.bin

Regarding FIP file to use, there are only two options:

• device was running 23.05.x or snapshot before the v1.1.x installer
  => Use openwrt-23.05.2-mediatek-mt7622-linksys_e8450-ubi-bl31-uboot.fip

• device has already been converted to new flash layout using v1.1.x installer and yet turned into a brick already again (something which we should be able to prevent in the near future, I hope)
  => Use openwrt-mediatek-mt7622-linksys_e8450-ubi-bl31-uboot.fip

The syntax for mtk_uartboot is simple:

mtk_uartboot -d /dev/ttyUSB0 -a -p bl2-for-mtk_uartboot.bin -f *uboot.fip

This will allow you to boot the router once. You then have to re-write what ever was broken. As crazy as it sounds, but literally reading from the flash and writing back the read content fixes the issue. The most convenient way to do this is by starting a serial console right after mtk_uartboot and using U-Boot.

Again the two cases:

• pre v1.1.x
  => mtd read fip $loadaddr 0x0 0x140000 && mtd write fip $loadaddr 0x0 0x140000

• post v1.1.x
  => ubi remove rootfs_data ; ubi read $loadaddr fip && ubi write $loadaddr fip $filesize

Note that this applies of course only if what you are seeing is the infamous "OpenWrt Kiss of Death" issue with no other action taken and no other mess created by the user up to this point. Should there be more or other problems (such as overwritten/missing factory data which results in no MAC addresses and Wi-Fi calibration) you will also have to write that again. I've guided multiple users here already how to do this and I'm too tired now to go through it again. Contact me by PM and give access to the serial console e.g. using tmate, I'll fix it in few minutes after seeing what is actually broken.