Recently a 1043nd of mine was debricked with TTL. I have used tftp before, but I am a little cautious whether I am able to setup a tftp connection after an unsuccesfull flash
The stock firmware image is a version 1.1 tp-link header with a new version number mktplinkfw does not know about yet. But there is another small header prepended, it looks rather simple with two more md5 hashes and some trivial fields.
I managed to create a valid firmware image using the make_header tool from one of their toolchains, and it starts flashing, yet stops. This is maybe a problem of the mtd layout of 1M for the kernel, where we are now at ~1.3M .
Anyone else other insights?
I do not have other insights regarding this. But is it possible to shrink the kernel to 1M to see if your assumption is correct?
I tried to compile a small kernel last week, but don't manage to get it below 1.1M .
New try: build a chimera with an old 2.6.31 kernel of 1M and a more recent filesystem with the appropriate tools.
Did you manage to get it working? And are you willing to share your build?
I did get it working to some part. I prepared a file system with telnetd enabled and the httpd without (presumably) "security" checks (option -f), and some flash tools (fw_printenv, flashcp) added.
This is a very crude try, but I can share the image if you want.
Where I'm stuck now is that uboot is using default environment settings, so I cannot change them as I planned (fw_printenv/fw_setenv). The httpd seems to stricktly check flash partition sizes, which we have at [...]1024k(uImage),6976k(rootfs)[...]
Here I'm stuck currently. Just flashing from uboot via tftp does not really help, as you would need to open the box and attach the serial console cable.
Next try is mangling the image to contain splitted lede build with 1024k 6976k fragments.
Sucess!!! A 17.01.4 flashed from the GUI.
[ 0.000000] Linux version 4.4.92 (buildbot@builds-02.infra.lede-project.org)
(gcc version 5.4.0 (LEDE GCC 5.4.0 r3101-bce140e) ) #0 Tue Oct 17 14:59:45 2017
[ 0.000000] MyLoader: sysp=5ddfff9d, boardp=bef753fd, parts=ffefffff
[ 0.000000] bootconsole [early0] enabled
[ 0.000000] CPU0 revision is: 00019750 (MIPS 74Kc)
[ 0.000000] SoC: Qualcomm Atheros QCA956X ver 1 rev 0
[ 0.586351] 5 tp-link-64k partitions found on MTD device spi0.0
[ 0.592510] Creating 5 MTD partitions on "spi0.0":
[ 0.597462] 0x000000000000-0x000000010000 : "u-boot"
[ 0.604147] 0x000000010000-0x000000143408 : "kernel"
[ 0.610639] 0x000000143408-0x0000007f0000 : "rootfs"
[ 0.617050] mtd: device 2 (rootfs) set to be root filesystem
[ 0.622973] 1 squashfs-split partitions found on MTD device rootfs
[ 0.629373] 0x0000003b0000-0x0000007f0000 : "rootfs_data"
[ 0.636256] 0x0000007f0000-0x000000800000 : "art"
[ 0.642477] 0x000000010000-0x0000007f0000 : "firmware"
Now I will check if my image is loaded on a fresh box as well, or if a two-step approach needs to be done.
1 Like
Sounds promising 
It works. So, I have an 17.01.4 image that can be flashed from an out-of-the-box TL-WPA8630, tested with 1.0.4 native firmware to start from.
That is really nice!!!
For everyone who wants to use it for TL-WPA8630 (without the P):
lede-17.01.4-ar71xx-generic-tl-wpa8630-squashfs-initial.bin
1 Like
What is different on the image linked by you compared to the officially available 17.01.4 download?
In short, the difference is that you can flash it from the native GUI whereas this does not work with the official images.
In long, there are three more headers and some size constraints on the image, that seem to be strictly checked by the native firmware:
The fragment sizes need to be exactly the flash partition sizes, as pointed out in one additional upfront tplink1.1 header (easy). But there is two more headers, 36 or 40 bytes with some length fields and an md5 checksum, plus another 20 bytes header (length+checksum), where I didn't manage to find the seed or the extent of checksummed data yet for these two; ie I'm using a tool from the tp-link sdk for creating these.
1 Like
Unfortunately I receive an error while trying to upgrade. The file extention is *.sit, rename to *.bin does not help.
Try a shorter file name, like factory.bin
Renamed tot factory.bin
I did it on a WPA8630 without the P, the model with external antennas and no power socket.
Just tried it on WPA8630P V1 and it fails. Will have a look at it, where the difference is in the image.
The TL-WPA8630P has a hardware ID of 0x86310001 instead of 0x86300001 ... that's why it does not flash. Give me 10 minutes ...
1 Like
Ok, this is the image for the TL-WPA8630P V1: http://www.netadair.de/lede/lede-17.01.4-ar71xx-generic-tl-wpa8630pv1-squashfs-initial.bin
BTW there is indeed a 64 character limit on the file name 
The TL-WPA8630P V2 is yet another story, but actually I don't have one to test.