Does it have pushbutton recovery? Try holding down the WPS button while powering up.
I tried holding down buttons, didn't do anything 
Luckily I have another device of the same hardware revision that is still stock, so I'm working on getting flashrom working so I can dump an image and then flash it.
However there is supposedly calibration data somewhere in flash, how would I retain that for this device I wonder? I only need the location so I can grab it from a dump and insert it into the file before flashing...
I'm sure it would work if I just transplanted the whole flash from another device, but I'm sure it'd hurt performance
Looking at the flash partition layouts, I'm guessing that what I need to preserve (at least) is:
Partition Base Size OpenWrt Dev
radio 0x7f0000 0x10000 mtd6 “radio”This looks like 64kb of data at the very end (or maybe not, see later). That seems reasonable enough. In fact, I probably should only flash the first three partitions up to 0x730000 as nothing past that should have been modified.
However, as I said in my first post, I'm fairly rusty when it comes to flashing, and at first glance it seems I'm missing something important.
Because according to the "Flash Layout" on the wiki, the flash ends with the radio partition at hex 0x7f0000 + 0x10000 = 0x800000. But that's decimal 585728, which is nowhere near 8Mb (it's an 8Mb flash chip, and the factory flash is 8Mb as well).
So the base addressing isn't bytes (and the config partition is not 64kb after all?), so I am not confident on what I can leave in the flash. Sure, I can just make a backup and then start flashing the stock image from the working device, add 128kb increments until it starts booting and then flash stock and I should be golden. But that'll take a lot of time and I'd prefer to know what I'm doing 
My first thought was the base address is expressed in erase blocks of some size, but then I'm unsure why the radio partition is this nice 64*1024 value, and 8192*1024=8388608 and when I divide that by 585728 I get 14,322, which doesn't seem anything like a sane "erase block" or "page" size.
Can anyone nudge me in the right direction here? TIA!
Your number is wrong. 585728 = 0x8f000. 0x800000 is 8388608 = 8 Mi.
Atheros systems almost always have the radio calibration in the last block of the flash, but back up the entire flash chip before writing to it.
Haha, right you are Shows how rusty I am, the ratio coming out as 14 and a bit and this being hex/base 14 should have rung a bell but it didn't...
Yes, I'll dump the flash first and only write the first 0x732000 bytes to start with, then when it boots re-flash stock and I should be OK. Because the partition layout suggests the device-unique MAC address is at 0x732000, and I assume the default password and SSID name (derived from the MAC) printed on the label on the case and the like is somewhere after that as well.
Hi raphidae,
I've also tried upgrading from 3.0.1 and bricked my device - any advice or known ways to unbrick it?
Damn, I thought v3 would be a lot simpler to support than v2. 
I'll put a warning for now on the Wiki page to avoid flashing when using v3.0.1 until this is fixed.
Either something in the boot process has changed with v3.0.1, or there is different unsupported hardware in the new units (e.g. new flash modules).
I'll test out flashing from v3.0.1 on my own unit in a few days.
@raphidae, if it's handy, could you upload the full console output from OEM v3.0.1 and bricked v3.0.1 + OpenWrt? Does installing from v3.0.0 work for you?
On a working OpenWrt install, when it finds the flash module, you should see these lines:
[ 0.990803] spi-nor spi0.0: XM25QH64A (8192 Kbytes)
[ 1.000637] 4 fixed-partitions partitions found on MTD device spi0.0
Hopefully this can be fixed, otherwise we might have to tell people not to upgrade to v3.0.1+.
The layout for v3.0.1 is identical to the earlier versions. When I saw the release a few months ago I only checked that and assumed it was OK without testing.
grep -ao "partition .*$" wpa8631pv3_eu-up-ver3-0-0-P1-20210514-rel45003-APPLC.bin | md5sum
0771948573fffa726b8927ca6259ea16 -
grep -ao "partition .*$" wpa8631pv3_eu-up-ver3-0-1-P1-20220330-rel52768-APPLC.bin | md5sum
0771948573fffa726b8927ca6259ea16 -
I see wpa8631pv3_eu-up-ver3-0-1-P1-20220330-rel52768-APPLC.bin also includes a new fs-uboot, so it's possible something changed there that is interfering with the OpenWrt boot process (e.g. different uboot environment or kernel cmdline). But once the kernel is in the same place, usually it doesn't matter for OpenWrt.
What was the uboot command you used to boot that initramfs file? I'll put that into the wiki. That will be an easier way to test and possibly recover than SPI flashing (assuming the OpenWrt kernel can see the flash).
This could be a sign of unsupported flash. Did you see anything like this? (taken from the working OpenWrt bootlog on the wiki):
[ 0.978401] spi-mt7621 1e000b00.spi: sys_freq: 220000000
[ 0.990803] spi-nor spi0.0: XM25QH64A (8192 Kbytes)
[ 1.000637] 4 fixed-partitions partitions found on MTD device spi0.0
[ 1.013348] Creating 4 MTD partitions on "spi0.0":
[ 1.022876] 0x000000000000-0x000000020000 : "u-boot"
[ 1.033935] 0x000000020000-0x000000730000 : "firmware"
[ 1.045578] 2 tplink-fw partitions found on MTD device firmware
[ 1.057444] Creating 2 MTD partitions on "firmware":
[ 1.067355] 0x000000000000-0x00000029c12b : "kernel"
[ 1.077244] mtd: partition "kernel" doesn't end on an erase/write block -- force read-only
[ 1.094740] 0x00000029c12b-0x000000710000 : "rootfs"
[ 1.104689] mtd: partition "rootfs" doesn't start on an erase/write block boundary -- force read-only
[ 1.124048] mtd: device 3 (rootfs) set to be root filesystem
[ 1.135554] 1 squashfs-split partitions found on MTD device rootfs
[ 1.147949] 0x000000690000-0x000000710000 : "rootfs_data"
[ 1.159830] 0x000000730000-0x0000007f0000 : "config"
[ 1.170912] 0x0000007f0000-0x000000800000 : "radio"
Edit: Sorry, I misunderstood the part where you said it flashed OK. Do you mean using uboot flash commands, or using sysupgrade from inside the booted initramfs image?
You should be able to recover from the uboot console. For that you'll need a 3.3v USB FTDI serial cable. I can provide some recovery instructions in a few days time, if no-one has some tested ones already.
The alternative is using an SPI flash programmer as documented in the v2 wiki page, and a backup flash dump. However the v3 PCB is much more delicate.
Serial recovery should be easier, so long as you dont override your bootloader with junk by accident!
1 Like
Same Problem here, cant even load the TP-LINK stock FW, Image to big
When I load openwrt 22.03 via tftp, boot stops @ Starting kernel ...
with all LEDs off.
Edit: also get LZMA ERROR 1 when i try to boot via tftpboot.
Edit2: according to binwalk the stock fw package from TP-link also contains the U-boot partition. I guess that uboot tries flash that image with its own offset so that it doesnt overide itself on the flash--> not enought space.
Waitting for RX_DMA_BUSY status Start... done
ETH_STATE_ACTIVE!!
TFTP from server 192.168.0.184; our IP address is 192.168.0.254
Filename 'test.bin'.
TIMEOUT_COUNT=10,Load address: 0x80100000
Loading: checksum bad
checksum bad
checksum bad
checksum bad
checksum bad
checksum bad
checksum bad
Got ARP REPLY, set server/gtwy eth addr (80:fa:5b:52:cc:75)
Got it
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
##############################################
done
Bytes transferred = 8554153 (8286a9 hex)
NetBootFileXferSize= 008286a9
Abort: image size larger than 8257536!
## Booting image at bfc20000 ...
text base: 7a697365
entry point: 39363d65
Uncompressing Kernel Image ... OK
No initrd
## Transferring control to Linux (at address 39363d65) ...
## Giving linux memsize in MB, 64
Starting kernel ...Hi, I'm sorry, I had to drop this because of life
At the moment I don't have working u-boot anymore, however I do have another working device that's still on stock. So my current course of action is going to be to dump flash from the working device, dump flash from the broken one, put the last few blocks of the flash from the broken into the file from the working to retain calibration data and re-flash. That should work, no?
I tried to do this a few days ago, but I'm having a problem with my CH341A flasher where it only reads FF. As I don't believe I did something where the flash actually contains only FF's, I'm sure there's something wrong with my flasher, so I busted out my Saleae logic analyzer to debug what is happening, and that's where I left it. As this is a cheap Chinese flasher I ordered a replacement that should arrive tomorrow, just in case.
Funny how these projects have a tendency to mushroom out LOL. But at least I get to freshen up my skills in this area.
The openwrt-22.03.3-ramips-mt7621-tplink_tl-wpa8631p-v3-initramfs-kernel.bin did boot, I put it as test.bin on a tftp server and booted using tftpboot/bootm from u-boot.
I could flash the sysupgrade OpenWRT binary from the initramfs image, but then I would just go back to the original boot loop that I got when installing OpenWRT from the stock firmware upgrade route (see my first post). Unfortunately I didn't save the whole console output, but the snippet of the log in my first post is the only thing that indicated any errors as I would have included anything that would have indicated a problem. I don't remember any output on console relating to partitions, I think I would have remembered that.
My guess is that the bootloader was changed in 3.0.1 and is now incompatible somehow.
PS. If someone would care to link me to a dump of a working device that will save me opening the second device, so that'd be appreciated.
Got it. pulled master from git. compiled the wpa8631p with kernel 5.10 instead of 5.15. loaded image via u-boot option 2 tftp to flash. booted and works.
I sent you a mail re: a backup copy for SOIC-8 flashing. That has an earlier OEM version. If you can install OpenWrt on that, but not on v3.0.1, it would suggest the issue is due to boot environment changes, not hardware.
Yep just as a warning to others in the thread, that using uboot to overwrite your flash can result in loosing uboot at the start. You can only flash the raw partition contents to the flash. Flasing the OEM upgrade images or Openwrt factory/sysupgrade images to 0x0 - 0x8 MiB will overwrite your bootloader MIPS instructions with the upgrade file headers and brick the device. Unless you have an SOIC-8 flash programmer and a backup to recover, you should avoid experimenting with the uboot flash commands and wait for a well-tested guide.
You should be able to safely tftp boot from RAM.
V2 had an OEM firmware recovery web server in 2nd stage fs-uboot (httpd command?) but I'm not sure yet how to activate it.
Edit: v3 has only one stage uboot, so that web recovery doesn't seem to be included.
What model SPI flash chip shows in your snapshot build kernel log? If you tftp boot from memory to OpenWrt 22.03.3 initramfs image, does it still find the flash device and partitions?
Out of interest, would it be possible to upgrade/down grade uboot by writing a bootloader image to 0x0 - 0x8 MiB?
Could this be done from within uboot and/or openwrt (using mtd write)?
Default kernel for me was 5.15 for ramips in snap. For some reason 5.10 works.
Initram and sysupgrade/factory works.
./openwrt/target/linux/ramips/Makefile
Kernel Version 5.15 --> 5.10. Compile. Upload via ubootloader option 2 ( tftp to flash ).
--> openwrt boots normal.
Yes, you would need a copy from an earlier firmware. All images seems to include it.
You can extract them with tplink-safeloader -x, or this script.
Only do this if you have an SOIC-8 flash programmer on standby, as if it doesn't work it will break your uboot. Its also unconfirmed if the newer uboot build is the cause, there may not actually be any functional changes in it.
What model flash shows in your working kernel output? Does it detect the flash partitions?
I.e. the lines like this:
[ 0.990803] spi-nor spi0.0: XM25QH64A (8192 Kbytes)
[ 1.000637] 4 fixed-partitions partitions found on MTD device spi0.0
Do those similar lines show on the 22.03.3 initramfs image?
If you need to know, mine has this SPI flash (that doesn't seem to be in any flashrom or AsProgrammer database incidentally): https://www.xmcwh.com/uploads/442/XM25QH64C.pdf
Can I just use some other xx25Q64xx chip's setting, like the GigaDevice GD25Q64B you think? Datasheets seem similar enough when I skimmed them...
Or is this the cause for the flasher returning only FF's perhaps?
Ch341a should be able to read this
Google helped me find this link which has an updated version of flashrom, it specifically lists XM25QH64C as a supported chip.