See the Soft Factory Reset and Hard Factory Reset options in this wiki article.
First thing I'd try is use sysupgrade to install the sysupgrade image of the same version OpenWrt. It's unlikely to change anything but worth trying.
In the past (on other, but similar models) this inability to format the jffs filesystem has happened after TP-Link switched production to a different brand of flash chip, and the OpenWrt driver was not set up to write to the new type of chip.
Here is the boot log of my A7v5 on 21.02.1 detecting the flash chip.
Tue Nov 9 01:55:08 2021 kern.info kernel: [ 0.350831] spi-nor spi0.0: w25q128 (16384 Kbytes)
Tue Nov 9 01:55:08 2021 kern.notice kernel: [ 0.355854] 7 fixed-partitions partitions found on MTD device spi0.0
Tue Nov 9 01:55:08 2021 kern.notice kernel: [ 0.362424] Creating 7 MTD partitions on "spi0.0":
Tue Nov 9 01:55:08 2021 kern.notice kernel: [ 0.367393] 0x000000000000-0x000000020000 : "factory-uboot"
TIf you see a chip type other than w25q128 and/or an error message that may be the problem.
TFTP recovery occurs entirely in the bootloader. OpenWrt does not change the bootloader, so a history of installing any version of OpenWrt would not affect TFTP recovery capability. Installing different versions of factory firmware may replace the bootloader.
Thanks, I'll look over those in more detail and see if I can figure something out there. I did previously try failsafe mode and then firstboot to see if it fixes things, but didn't.
Thanks for the response and some references to compare. I feared also this was an issue with an unknown flash chip change among different batches, but luckily the flash chip appears to still be the same (or at least the router thinks it's the same).
Sun Oct 24 09:01:47 2021 kern.info kernel: [ 0.350599] spi-nor spi0.0: w25q128 (16384 Kbytes)
Sun Oct 24 09:01:47 2021 kern.notice kernel: [ 0.355630] 7 fixed-partitions partitions found on MTD device spi0.0
Sun Oct 24 09:01:47 2021 kern.notice kernel: [ 0.362201] Creating 7 MTD partitions on "spi0.0":
Sun Oct 24 09:01:47 2021 kern.notice kernel: [ 0.367169] 0x000000000000-0x000000020000 : "factory-uboot"
Sun Oct 24 09:01:47 2021 kern.notice kernel: [ 0.373807] 0x000000020000-0x000000040000 : "u-boot"
Sun Oct 24 09:01:47 2021 kern.notice kernel: [ 0.379818] 0x000000040000-0x000000f00000 : "firmware"
Sun Oct 24 09:01:47 2021 kern.notice kernel: [ 0.388540] 2 uimage-fw partitions found on MTD device firmware
Sun Oct 24 09:01:47 2021 kern.notice kernel: [ 0.394696] Creating 2 MTD partitions on "firmware":
Sun Oct 24 09:01:47 2021 kern.notice kernel: [ 0.399842] 0x000000000000-0x000000200000 : "kernel"
Sun Oct 24 09:01:47 2021 kern.notice kernel: [ 0.405764] 0x000000200000-0x000000ec0000 : "rootfs"
Sun Oct 24 09:01:47 2021 kern.notice kernel: [ 0.411756] mtd: device 4 (rootfs) set to be root filesystem
Sun Oct 24 09:01:47 2021 kern.notice kernel: [ 0.419386] 1 squashfs-split partitions found on MTD device rootfs
Sun Oct 24 09:01:47 2021 kern.notice kernel: [ 0.425828] 0x000000570000-0x000000ec0000 : "rootfs_data"
Sun Oct 24 09:01:47 2021 kern.notice kernel: [ 0.432275] 0x000000f40000-0x000000f60000 : "info"
Sun Oct 24 09:01:47 2021 kern.notice kernel: [ 0.438103] 0x000000f60000-0x000000fb0000 : "config"
Sun Oct 24 09:01:47 2021 kern.notice kernel: [ 0.444133] 0x000000fc0000-0x000000fd0000 : "partition-table"
Sun Oct 24 09:01:47 2021 kern.notice kernel: [ 0.451057] 0x000000ff0000-0x000001000000 : "art"
As for bootloader being changed, the thing I fear is that using the TP-Link factory UI to install OpenWRT does change the bootloader, making this irreversible using TFTP (basically it can only load things into ram every time). I'll try maybe some more versions of stock firmware and see if I can get any version to stick (maybe going from oldest one in 2019 all the way down the list, luckily internet archive keeps a record of the links).
If that doesn't work, I'll try to do some more research into mtd partitions and try to figure something.
Did you also update via the TP-Link UI? Do you remember what stock version you updated from?
As an update, I tried TFTP on all the versions of stock firmware I can find using internet archive (from 190403 all the way to newest 211022, total 11 versions). The same problem persists (TFTP succeeds, but update not installed).
From a long search, the Archer C7 page has a section that talks about product_id and product_ver comparison that may be done during TFTP and may be the issue. I will next be trying to install some older versions of Openwrt and if that doesn't work, will try to figure how to modify those fields in the firmware files.
I also tried erasing the jffs2 partition and it shows in the kernel log the same Newly-erased block contained word errors mentioned in OP.
umount /rom/overlay
mtd erase /dev/mtd5
Worried it may be a kernel bug like below, in which case not sure how to fix:
https://forum.openwrt.org/t/19-07-2-mount-root-failed-cp-a-tmp-root-rom-overlay-not-a-tty/61980/3
For what it's worth, as an update I did try hex editing the factory 190403 firmware file, changing the field that shows 6D 00 00 80 and the 4 bytes right after which appears to be the product id and product ver, but neither setting all to FF or 00 helps.
I opened the other brand new A7 v5 I had, hoping to SSH or Telnet into it to get mtd backups of a stock router, but found there is no way to do so on TP-link stock. Router came with version 20200721 (a bit older than the version the first one came with).
Later on this second router, I just TFTP stock 190403 (oldest stock version available) which went fine. Then TFTP OpenWrt 19.07.7 (given I know it worked fine in previous router and I don't dare try 21.02.1 again) and that went fine also. I then set a password and tried reboot to verify everything working fine (also logs don't show the same errors about "Newly-erased block contained word"). Then as a sanity check, I TFTP stock 190403 again and it went fine also (interesting thing is it retains the password, doesn't ask me to set password). I TFTP OpenWrt 19.07.7 and it appears password is reset, but setting it and rebooting it is retained, so everything seems to be working fine.
I notice when TFTP successfully installs firmware, it takes a much longer time to turn off the WPS light (proportional to image size, OpenWRT at only 4MB was faster) and reboot, although upload takes the same amount of time (almost instantaneous). This at least verifies there is absolutely nothing wrong with the TFTP process I am using, there is simply something that went wrong with the first router by installing 21.02.1 via TP-Link UI version 201029. Still trying to figure how to proceed on first router.
As an update, I tried hex editing 201029, still can't get it to take.
I also tried the mtd commands. I copied all the mtd images from the working router. The factory-uboot and uboot are different in the working router (checked with hex editor). It could be possible they were both different from factory, but also possible the 21.02.1 update via TP-Link UI changed things.
I tried using mtd commands to write the various files to mtd2 (firmware partition). It doesn't seem to take at all. Also tried unlocking and kmod-mtd-rw to overwrite mtd0 and mtd1 using bins from the working router, and it doesn't seem to take (no errors in command line but no change to partition).
So still no progress on this.
Sounds like the next step is probably a serial recovery.
I tried serial recovery and it doesn't work either. I didn't want to do serial recovery because it was invasive, but figured a way to make secure temporary connections without soldering. Basically taping a L shaped piece of solder I made flat with pliers to bridge the R24/R27 connections to the RX pin. For the connections to the 3 pins, I use the male dupont wires included with my CP2102 angled, I taped down wires so there is pressure and it keeps the wires angled for a secure connection.
Looking at the serial output during tftp recovery, the tftp progress seems to go ok, it's just it seems for some reason it doesn't actually write to the chip.
Firmware downloaded... filesize = 0xec2313 fileaddr = 0x80060000.
Firmware Recovery file length : 15475475
Firmware process id 2.
handle_fw_cloud 138
Image verify OK!
Firmware file Verify ok!
[Error]sysmgr_proinfo_buildStruct(): 659 @ unknown id(device_name), skip it.
[Error]sysmgr_proinfo_buildStruct(): 659 @ unknown id(country), skip it.
[Error]sysmgr_proinfo_buildStruct(): 659 @ unknown id(hw_ver), skip it.
[Error]sysmgr_cfg_checkSupportList(): 1023 @ specialId 45550000 NOT Match.
Firmware supports, check OK.
(curFw_ver, newFw_ver) == (1.0, 1.0)
Firmware Recovery check ok!
set integer flag to 0.
######################################################################
######################################################################
######################################################################
#################################
Done.
set integer flag to 1.
Firmware Recovery Success!
All Done!
now restart...▒
I tried to manually do serial recovery using a sysupgrade image, but although the commands all complete successfully, it keeps booting back to the same image. It seems like the flash chip is working like it is read only. I tried commands like "protect off all" but it seems the serial console does not support that, so not sure what is going on.
ath> tftp 0x81000000 sysupgrade.bin
Trying eth0
dup 1 speed 1000
Using eth0 device
TFTP from server 192.168.0.10; our IP address is 192.168.0.2
Download Filename 'sysupgrade.bin'.
Download to address: 0x81000000
Loading: ################################
################################
################################
################################
################################
################################
################################
################################
################################
################################
################################
################################
#####
done
Bytes transferred = 5701945 (570139 hex)
ath> erase 0x9f040000 +800000
Erasing flash...
First 0x4 last 0x83 sector size 0x10000 131
Erased 128 sectors
ath> erase 0x9f040000 +800000
Erasing flash...
First 0x4 last 0x83 sector size 0x10000 131
Erased 128 sectors
ath> cp.b 0x81000000 0x9f040000 0x800000
Copy to Flash... write addr: 9f040000
done
ath> bootm 0x9f040000
I also tried loading a initramfs version of 19.07.7 into RAM and doing a sysupgrade from that, but although again everything seems to go fine, nothing changes after reboot.
For a serial recovery, you should be using the squashfs-factory image.
This doesn't make much sense. Make sure you're using A7 builds not C7 as the partitioning is different.
Try TFTP booting the snapshot initramfs. Once that is running you should back up the important partitions:
cat /dev/mtd0 > /tmp/factory-uboot.bin
cat /dev/mtd1 > /tmp/u-boot.bin
cat /dev/mtd9 > /tmp/art.bin
(check partition numbers with cat /proc/mtd, it should have a table with these names and numbers.) If you have an interest in returning to factory, also get mtd2, which is the firmware. scp these files to your PC then scp up the 21.02 sysupgrade and install it with sysupgrade.
I used the sysupgrade version given this thread uses it:
Plus I have been examining the hex and binwalk of a bunch of files already and the factory ones have some extra headers in it that makes it not match the firmware header in the mtd2, while the sysupgrade one seems to match what is expected of a firmware image.
Anyways, I tried the squashfs-factory images (both 19.07.7 and 21.02.1) and there is no difference. Also doesn't matter if I erase the exact size of the files or if I erase more. It doesn't seem to matter, what seems to be happening is the flash isn't getting erased/written to.
Yes, I am using A7 builds, not C7. I have backed up all the files already a while ago, mtd0 all the way to mtd9. Did it because I tried mtd -write and it doesn't seem to work (the flash doesn't seem to be written to).
I have done the procedure of booting initramfs the 19.07.7 version, and doing a sysupgrade. Just tried the snapshot initramfs, and a sysupgrade to 19.07.7. There are no errors, but again, after reboot, everything is back to the same (still stuck on 21.02.1, no settings are saved).
Watchdog handover: fd=3
- watchdog -
Watchdog did not previously reset the system
Wed Jan 12 04:50:56 UTC 2022 upgrade: Sending TERM to remaining processes ...
Wed Jan 12 04:51:00 UTC 2022 upgrade: Sending KILL to remaining processes ...
[ 461.292102] stage2 (2483): drop_caches: 3
Wed Jan 12 04:51:06 UTC 2022 upgrade: Switching to ramdisk...
Wed Jan 12 04:51:08 UTC 2022 upgrade: Performing system upgrade...
[ 463.546428] do_stage2 (2483): drop_caches: 3
Unlocking firmware ...
Writing from <stdin> to firmware ...
Wed Jan 12 04:51:11 UTC 2022 upgrade: Upgrade completed
Wed Jan 12 04:51:12 UTC 2022 upgrade: Rebooting system...
umount: can't unmount /dev: Resource busy
umount: can't unmount /tmp: Resource [ 467.214193] reboot: Restarting system
It's possible they've changed the flash chip and OpenWrt driver doesn't support it. I have an older A7 (US) and never had problems like this.
When you boot the intrd you should have a line like this:
Tue Dec 7 00:34:44 2021 kern.info kernel: [ 0.378377] spi-nor spi0.0: w25q128 (16384 Kbytes)
If spi-nor reports "unknown JEDEC" or similar, there is a problem.
Edit: I see you already checked this.
In the bootloader you can use md.b address to show the contents of a flash block. After manually erasing, it should be all FF. If you erase one of the kernel blocks like 0x9f040000, it will definitely brick. The next reboot would say "bad magic number" and fail to launch Linux.
Let me check that. The weird thing is that erase doesn't appear to work either in the serial console, which doesn't make a whole lot of sense given presumably in the serial mode it is still running the factory U-boot.
It appears installing 21.02.1 factory via the TP-link UI with a later version like 20201029 puts the router in a state that the flash can't be written into. If this is true, there needs to be a clear warning in the Archer A7 v5 wiki, as there was an entry that suggest to use TP-Link UI to install Open-WRT 21.02.0 that I fell trap to (as well as it seems another person)..
My only guess is perhaps the update process puts the flash in a "protected" mode and Open-wrt doesn't have a way to put it back into unprotected. The serial console doesn't seem to support the "protect off" command, so can't really test that theory.
I just tried it and the header is as expected (given it boots, this is not a surprise). Then I erased a block, and read it again and it stayed the same, so the erase command isn't successfully erasing the block.
ath> md.b 0x9f040000
9f040000: 27 05 19 56 6f ad c0 0b 61 75 20 ef 00 1f 3e db '..Vo...au ...>.
9f040010: 80 06 00 00 80 06 00 00 53 5e 5b 85 05 05 02 03 ........S^[.....
9f040020: 4d 49 50 53 20 4f 70 65 6e 57 72 74 20 4c 69 6e MIPS OpenWrt Lin
9f040030: 75 78 2d 35 2e 34 2e 31 35 34 00 00 00 00 00 00 ux-5.4.154......
ath> erase 0x9f040000 +10000
Erasing flash...
First 0x4 last 0x4 sector size 0x10000 4
Erased 1 sectors
ath> md.b 0x9f040000
Unknown command 'md.b' - try 'help'
ath> md.b 0x9f040000
9f040000: 27 05 19 56 6f ad c0 0b 61 75 20 ef 00 1f 3e db '..Vo...au ...>.
9f040010: 80 06 00 00 80 06 00 00 53 5e 5b 85 05 05 02 03 ........S^[.....
9f040020: 4d 49 50 53 20 4f 70 65 6e 57 72 74 20 4c 69 6e MIPS OpenWrt Lin
9f040030: 75 78 2d 35 2e 34 2e 31 35 34 00 00 00 00 00 00 ux-5.4.154......
ath> help
? - alias for 'help'
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootm - boot application image from memory
cp - memory copy
erase - erase FLASH memory
fm - flash read, memory write
fwrecov - TP-Link Firmware Recovery Tools
go - start application at address 'addr'
help - print online help
start www server for firmware recovery
mct - simple RAM test
md - memory display
mm - memory modify (auto-incrementing)
mtest - simple RAM test
mw - memory write (fill)
nm - memory modify (constant address)
ping - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
progmac - Set ethernet MAC addresses
progmac2 - Set ethernet MAC addresses
reset - Perform RESET of the CPU
run - run commands in an environment variable
setenv - set environment variables
tftpboot- boot image via network using TFTP protocol
uploadtftp - download or upload image via network using TFTP protocol
version - print monitor version
There appears there be other commands like fwrecov or start, I'm going to try those given there doesn't seem to be much other options.
Edit: it seems httpd starts a tp-link html based recovery page. I'm going to try a few images on it. Tried 20190403 but it didn't take. However the process does seems to work longer than the TFTP one so seems to be doing more.
As last resort, I guess I will have to return the router (I'm still within return window given holiday extended returns, this is why I had to make sure serial recovery process did not involve any hardware mods), but I wanted to avoid this if at all possible.
Just an update on this. Tried the httpd command, tried a few firmware images (old and new) and the install process seems to go fine but afterwards still no change.
Then I tried the mw command, which did seem to successfully overwrite the memory (results in bad magic number), but it seems only temporary. As soon as I run the erase command, it seems to revert back, also doesn't seem to survive a reboot. So it's like it's acting like it's writing to somewhere temporary, not permanent.
I also tried loading a uboot image from a working router, but it seems to give a "wrong image type" error and bootm command refuses to boot it. Looks like it only allows booting a kernel image. Also tried booting a tp-link firmware from 0x81000000, but there is a kernel panic, I guess it's not designed to boot purely from ram.
Well I'm throwing up the white flag and returning the router for a new one. I have exhausted trying all the relevant commands in the serial console (even tried fwrecov command which apparently does a firmware recovery process using an image in memory, again everything seems to work but nothing changes).
Does any one have wiki editing access? I just wanted an entry to be added that updating 1.0.16 Build 20201029 rel.43238(5553)
to 21.02.0 via the TP-Link GUI caused a router to become read-only.
https://openwrt.org/toh/tp-link/archer_a7_v5
Just hoping there is an entry there that may help someone else avoid ruining their router also. Completely regret not just sticking to TFTP. Would have saved a lot of headaches.
As a final update, I got my replacement router. It's a bit newer and came with 1.1.2 Build 20210125 rel.39623(5553). Wasn't able to install using TFTP any older TP link firmware other than 1.1.0 Build 20201120 rel.50399(5553), perhaps because it is no longer a 1.0 version.
Saw in forums people were able to install the 19.07.x versions of OpenWrt on either of those versions using TFTP, so did install 19.07.7 no problem. Didn't dare to use TP-Link UI.