You do? You can't just use the sysupgrade function?
I tried it but nothing happened, the router restarted back to 19.07.
Your MAC addresses are likely wrong or not working.
In 11-ath10k-caldata you're taking the MAC for 5G wifi out of the "info" partition, which doesn't exist in your .dts.
And in the .dts itself you're using <&uboot 0x1fc00> for eth0, but that's just some MAC every deco bootloader uses and not the MAC on the label on the bottom of your device.
wmac in the .dts doesn't have a MAC address at all.
Could it be that all of them start like this: 12-34-56-...?
This is important because end devices differenciate between different APs (that use the same SSID) by BSSID and that's usually the MAC of the used interface. And I'm guessing that all Decos running your firmware are going to have the same SSIDs.
Also having multiple wired devices with the same MAC in the same network is also going to create problems.
Thank you for your concern, I got my USB dongle from Adafruit for this purpose. It's the blue one with the Profilic PL2303 (I think it's a TA variant), the datasheet states, that the signal levels are 3.3v (CMOS) level not TTL. I think it will not blow up the Deco 
Since last time I have seen your conversation with @KinteLiX and read up on the subject. Am I right to assume that U-Boot is RSA locked? Then for complete support the RSA lock has to be disabled first, before we can flash any unsigned images via U-Boot recovery. Right now flashing anything on the device requires using the "leaked" developer firmware from @origami as it has the required signature and gives access to the device.
Anyway I was away for chistmas and I just got around to get my iron and cables. I will solder the UART tomorrow and try to collect information from serial.
Hi, I have a 21.02 port but the dts file was pretty bad on it (plus some other files), over the last couple of days I've improved it thanks to help from @bobthebuilder.
I've just pushed my latest dts file which has the firmware partition, which should fix sysupgrades (not sure, the verbose option didn't show any info that would help in finding the cause but that may have been it).
I think you still need to do the mtd method if going from 19.07 to mine because 19.07 lacks firmware partition.
From what I read up here our only option would be to find the RSA key, soldering or the leaked fw method. I'm not sure if disabling the RSA check in the bootloader is even possible.
Having a passing familiarity with RSA I doubt we could get the necessary private key to sign our own image (I will check the GPL pack from TP-Link for it, but it would have been a stupid mistake to leave it in there). The different parts of the image (kernel, rootfs, etc.) are individually hashed and signed, and these signatures are checked by U-Boot according to the documentation.
Interesting info, I also doubt you will find it there. In the meantime, I fetched and merged upstream changes (bumped Linux kernel version). I'm gonna use it to compile it and test sysupgrade.
Interesting, because RSA uses public and private keys, I wonder if the private key could be extracted from the router because the router's bootloader must check the image somehow, but I could be wrong so don't quote me on that. I don't think it would be legal to share it though.
And if you are already opening the device up and soldering wires to it, you could just flash OpenWrt to it without dealing with extracting keys.
Sysupgrade worked! Seems like the lack of firmware partition defined in dts was the issue.
Only the web-interface that is loaded by the bootloader if you press and hold the reset button during bootup is checking the RSA signature. Once you are in the command line of the bootloader (just type tpl multiple times during bootup) you could flash a jpeg of a horse to the flash memory and the bootloader wouldn't care.
So if you are soldering anyway then you don't need to worry about any RSA checks.
I have found this: U-Boot: Verified RSA Boot on ARM target (denx.de), gives some insight...
The Deco M4R V1 and V2 don't have an ARM SoC. The bootloader isn't checking what is in the flash. It only checks whatever you upload via the web interface before it flashes it.
I wonder if the private key could be extracted from the router because the router's bootloader must check the image somehow, but I could be wrong so don't quote me on that.
Yes, you are. Whatever is encoded with the private key can only be decoded with the public key and whatever is encoded with the public key can only be decoded with the private key.
So you will never find the private key on the router. That's just not how that works.
That's also how your bank does it with your online banking or how almost all websites these days do it with https. The server is the only one who knows the private key but it will gladly tell you the public key so you can encode messages with it that only the server can decode with its private key.
Sysupgrade worked! Seems like the lack of firmware partition defined in dts was the issue.
I'm betting that the label = "firmware"; is the important part here.
Did you upgrade from your second to last build to your last build or did you upgrade from my image?
I upgraded from my second to last build to my last build so it could work with 19.07 but I haven't tested that.
The second to last build still had kernel and rootfs as separate partitions in the .dts, right? Sounds good either way that it worked for you.
Are the MACs of the eth0 interface and of the first 2.4GHz SSID now the same as the one on the label on the bottom of the Deco? Is the first 5GHz MAC one less?
For instance if the MAC on the Label is E1:AA:BB:CC:DD:E0 then the first 5GHz SSID should have E1:AA:BB:CC:DD:DF (in Hex DF + 1 = E0, E0 + 1 = E1 and so on).
(OpenWrt will add 2 to the first byte of every following SSID so the second 2.4GHz SSID should have E3:AA:BB:CC:DD:E0 and the second 5GHz SSID should have E3:AA:BB:CC:DD:DF)
Actually no, my second to last build had kernel 5.4.163 and I upgraded to 5.4.168, both had firmware partitions defined, also I just tested it on my main deco which didn't have the firmware partition (I experimented on my secondary one) and it didn't work so you have to use mtd method to go to the image with the firmware partition defined.
I'll check this in a minute.
Edit: Yes, they are exactly how you said.
Hello everyone,
I've added another mirror for backup. Hope for the best !!
Link: https://www.androidfilehost.com/?fid=17825722713688258825
This is simply incorrect. RSA is asymmetric, the private key can only decode while the public key can only encode, I guess you didn't write that correctly.
My thinking was because the firmware image is encoded with the public key and the router checks it with its private key that is inside the bootloader, whether it would be possible to somehow extract it, but I guess it's not that simple.
Plus, I think it would make more sense to check whether the Web GUI does the RSA check or not.
Let's take this a little apart:
This is simply incorrect. RSA is asymmetric, the private key can only decode while the public key can only encode, I guess you didn't write that correctly.
The function of using RSA here is to only allow firmware signed by TP-Link to be installed on the device. In this case TP-Link uses their private key (of which we are not aware) to encrypt the hash generated from the different parts of the image and supply that signature along with the binaries (in the form of the DTS). The router calculates the hashes again, and uses the public key (it is in the image in some form, therefore it's public, it's there to see for everyone) to decrypt the hashes in the DTS and compares them with the calculated one). If they match, it's ok. If not, flushes the image down the drain.
The confusion arises from the usage of RSA which can be used for encryption (but then the content should be encrypted with the recipient's public key) or proof of authenticity aka signing (this is our case).
In that sense RSA is symmetric: something encrypted with the private key can only be decrypted by the public key and something encrypted with the public key can only be decrypted with the private key.
I think it would make more sense to check whether the Web GUI does the RSA check or not.
It is possible, but I doubt it. U-Boot has everything built-in to do the vaildation and requires only to some funtion to be called. If you do this in linux you would need to duplicate/replicate these functions and that doubles the risk of messing something up.
I suggest that we need an "unlocked" U-Boot with at least RSA-checking disabled. The U-Boot source is in the GPL pack, maybe it can be built from that and flashed from the "dev" firmware, but I definitely want to get an SPI flash reader/writer and dump the entire flash contents before I start messing around with U-Boot.
I stand corrected, thank you for this info.
I think someone could flash that leaked firmware and then try to flash an OpenWrt image in Web GUI and read logs in the telnet window to potentially see why the router was refusing to flash the OpenWrt image.
I think it would be possible to make a custom U-boot image with more recovery options, but that is outside of my scope of knowledge.
On second thought it might be possible to "debug" the running U-Boot code itself. If the images themselves are not encrypted, then their hash is known to us. If we could find the compare function in U-Boot and trace it, we could find the hash U-Boot expects and apply that to the DTS of our own image.