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.baddress 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.