Support for TP-link RE205 v3

Sorry, I did not get any further.

I could not access the bootloader, which would be the safest way, and also an easy way to install openwrt. - Or at least to try to do so.

Next steps could be:

  • A couple of TP-Link devices seem to be able to receive updates over TFTP, that could also be a safe way that would allow unbricking if new firmware does not work.
  • Try to find the missing RX pin. - But I am afraid it has been disabled in the bootloader for production.
  • Get the sources from TP-Link and modify the Bootloader to enable the TX pin on TP1.
  • Try to install OpenWRT build for RE200. Hardware seems to be the same, except for the antennas. I guess signature would need to be modified for RE205. - This is a bit risky, as there would be no way to unbrick the device if this fails, and it could fail!
  • Access the FLASH chip directly. This might be the hardest way, but it would allow to do backups and restore original firmware if new firmware does not work. - This would require to either unsolder a chip, or to put pins of SoC into high-impadance state, which might be possible by pulling a reset pin.

But unfortunately this is some work without a guarantee to success and I do not have time to try it currently.

I guess you already read https://openwrt.org/toh/tp-link/re200#installation and https://openwrt.org/toh/tp-link/re305_v1#installation .
I tried to install using the serial interface as described in https://openwrt.org/toh/tp-link/re200#serial_v1_and_v2 , but I could not interrupt the bootloader as described in my first post.

Could you helps us on pointing us out with a picture where are the pinouts you used?

Ive tried several ones but haven't got luck yet, not even able to see the boot loader.


This is how I soldered a cable for a UART connection.
brown -> TP5 / ground
red -> TP1 (might be RX)
orange -> TP2 / TX (connect to RX of the serial interface.)
I think I used 38400, 56700 or 115200 baud. I cannot remember, but as RE200 seems to use 56700 baud you should start with that.

Mysteriously I have tried the exact pinouts with different baud rates, with no luck so far, not even getting an receiving output signal. Seems like they do disable the debug port, also for what I can see on you're picture I have some missing caps.

Since in this days I got COVID and Im forced to stay at home, Ive decided to take a look on this back again and I got some progress. I was finally able to find the UART details and they are as follow:

TP 1 - Tx
TP 2 - Rx
TP 5 - Gnd
TP 4 - Vcc
Connect with settings 57600 8N1. Signalling voltage is 3.3v.

The most likely in hardware device are the RE200 v3 and RE220 v1, since both of them uses the same SoC as the RE205 v3.
Given that Ive tried to load the only OpenWrt firmware supporting this hardware, the RE200 v3, Ive loaded it for testing (not writing to the flash) and was able to get to the prompt, both wifi signals 2.4 and 5 Ghz seems to work but Im not sure how stable would be the 5 Ghz since the R200 v3 has:
W1: MediaTek MT7628AN
W2: MediaTek MT7610E

Or so, that's what WikiDevi says, and what the RE205 v3 has:
W1: MediaTek MT7628AN, 2x2:2, bgn
W2: MediaTek MT7610EN, 1x1:1, an+ac
Flash Chip: XMC QH64AHIG, 8 Mb
RAM Chip: Winbond W9751G6KB-25, 64 Mb DDR2 SDRAM @ 800 MHz

May be the driver for MT610 works on both??
If this is true then, the only thing that is need to get it in the device support list is just to change the signature!

By the way I found also another device that more likely on the hardware side to the RE205 v3 and this is the Archer C20 v4 that has a supporting firmware on OpenWrt, but this firmware will put the only LAN port available as WAN making the device pretty much unusable since then, you can't proceed to make the required configurations out of the UART.

2 Likes

How did you load the OpenWrt firmware?
Did you manage to access the bootloader? (I was able to read output from the bootloader console, but I was not able to send any keys/characters/data to it. - Maybe I should try again...)

Did it work as described in https://openwrt.org/toh/tp-link/re200#serial_v1_and_v2 - Or did you do something else or in a different way?

Regarding MT7610E vs MT7610EN - I did not found any datasheet, but it is very likely that it is not a big difference.
For RE200 vs RE205, the (only) difference that I see is external antenna vs PCB antenna. - It might be necessary to adjust TX-power for different antenna gain or loss to fulfill regulatory requirements, but software-wise it should to work quit fine. (If this is the only difference.)

What TP-Link firmware and bootloader version is/was installed on your device?
As I wrote I had problems accessing the bootloader. I would like to check if I could unlock the bootloader by upgrading or downgrading to another software version.

Hi,

As you may see, we have a diferent bootloader since I didn't do any upgrades once I got it so its pretty much as it came to me from factory, as we all known newer updates may give you less chances for doing stuffs like this to the device.
Anyways, this is a capture that I did today:

U-Boot 1.1.3 (Aug 24 2022 - 10:39:45)

Board: Ralink APSoC DRAM: 64 MB
relocate_code Pointer at: 83fb8000
flash manufacture id: 20, device id 70 17
find flash: W25Q64BV
*** Warning - bad CRC, using default environment

============================================
Ralink UBoot Version: 4.1.0.0
--------------------------------------------
ASIC 7628_MP (Port5<->None)
DRAM component: 512 Mbits DDR, width 16
DRAM bus: 16 bit
Total memory: 64 MBytes
Flash component: SPI Flash
Date:Aug 24 2022 Time:10:39:45
============================================
icache: sets:512, ways:4, linesz:32 ,total:65536
dcache: sets:256, ways:4, linesz:32 ,total:32768

 ##### The CPU freq = 580 MHZ ####
 estimate memory size =64 Mbytes
RESET MT7628 PHY!!!!!!

Please choose the operation:
   1: Load system code to SDRAM via TFTP.
   2: Load system code then write to Flash via TFTP.
   3: Boot system code via Flash (default).
   4: Entr boot command line interface.
   7: Load Boot Loader code then write to Flash via Serial.
   9: Load Boot Loader code then write to Flash via TFTP.
default: 3

You choosed 1


1: System Load system code to SDRAM via TFTP
 Please Input new ones /or Ctrl-C to discard
        Input device IP (192.168.0.254) ==:192.168.0.254 
        Input server IP (192.168.0.184) ==:192.168.0.184
        Input Linux Kernel filename () ==:test.bin

 NetTxPacket = 0x83FE7840

 KSEG1ADDR(NetTxPacket) = 0xA3FE7840

 NetLoop,call eth_halt !

 NetLoop,call eth_init !
Trying Eth0 (10/100-M)

 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: 0x82000000
Loading: Got ARP REPLY, set server/gtwy eth addr (ac:22:2b:cb:56:e5)
Got it
#################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #####################################
done
Bytes transferred = 6509106 (635232 hex)
LoadAddr=82000000 NetBootFileXferSize= 00635232
**Erasing SPI Flash...**
**.**
**Writing to SPI Flash...**

done
Automatic boot of image at addr 0x82000000 ...
## Booting image at 82000000 ...
text base: 80000000
entry point: 80000000
   Uncompressing Kernel Image ... OK
No initrd
## Transferring control to Linux (at address 80000000) ...
## Giving linux memsize in MB, 64

Starting kernel ...

What IP should be using my computer for TFTP server I've first tried the RE200 v3 way without any luck then I realized as you may see on the output that the IP must be 192.168.0.184!!

Next thing Im thinking about is to purchase a flash reader/writer with the clamps so that way I don't have to desolder the chip then back it up to an image and try with writing the firmware to the chip via TFTP so that way I can bypass the factory firmware file checksum and if in some way I mess up the flash I can go back to do some more tests.

1 Like

Hello, The Bot, and slo, I also have a TP-Link RE205 that is ver3.6 rather than ver3.0, but I am guessing the differences are software-based rather than hardware. It seems both of you have given some effort to the beginnings of the RE205 potentially becomming a supported device. And it seems like this is a fairly popular device that many could benefit from having OpenWRT available and supported.

I am less than experienced as a developer per se, but I tinker and I would be curious to know; how might I start the process of altering firmware signatures to see if the OEM upgrade pathway can be made to accept a OpenWRT as a traditional update? Am I looking at putting together an entire OpenWRT linux-based development environment and learning to begin baking my own code? or is there a script, app, or service that can generate the firmware with altered signature? And what might the signature consist of? Is it a text file included in the image prior to compiling? I know it isn't file name based like some OEM upgrade gateways are, because I renamed the recent official ver3.6 2022 firmware to "_.bin" and it updated overtop of the same firmware with no problems. So could it be Sha256 based? Or an expected minimum filesize?

I am willing to give my effort toward moving this project along. I have a background in PCB assembly, minor coding expereince with websites, and I can log in to an ssh server with linux. I learn fast and I welcome your unfiltered advice, if or when you find time in this rapidly changing world we live in... :relieved:

Also, have either of you had an oppourtunity to make progress; if not, do you have any new ideas to share about what the next steps might be? I don't currently have any soldering or PCB test/development equipment anymore. But if there is a software solution I know we can find it!

Hope to hear from someone soon. :slightly_smiling_face:

The discussion on the RE220v1 may be helpful.

On that one the process was.
Solder serial connector.
Interrupt boot and install the re200-v3 initramfs firmware
(after everything tested ok), use sysupgrade to install the re200-v3 sysupgrade firmware
[warning may brick device]
test it some more.
do a build with the name changed from re200-v3 to re220-v1 in a few different places

There is a program called mktplinkfw.c that is part of the build process and it 'fixes' the firmware checksum.

@jedboy Thank you for sharing this info.
I don't have the necessary equipment or development environment yet to do much with what you've shared, but it is a highly motivating cornerstone of information. I also appreciate your direct approach.

You gave exactly what I requested. I have met many people and been on many forums where some have played complex social dynamic games prior to including any new people in the discussions. Surely that exists everywhere in varying degrees, but I'm encouraged by this first experience here. :smile: I'm more new to the subject of developing/adapting OpenWRT to currently unsupported devices than I may have let on, but I really do learn fast so I am excited to see where this leads.

As for your post, it seems you are suggesting that its necessary to test the current RE200 v3 firmware (which should more or less work for RE220 v1 and also RE205 v3 because of effectively identical hardware) by soldering serial connection, flashing the firmware, noting all functions that work or don't work, debug them with a new build (via an operational OpenWRT dev environment) then after a successful stable build is developed the last step is to use the mktplinkfw.c checksum modifier to "fill in the blanks" during the final build, which will cause the OEM web interface firmware upgrade to allow OpenWRT Factory bin files to be accepted. And then boom, we have the RE 220 v1 AND the RE205 v3 supported? Did I misunderstand you?

Yes, that sounds correct.
As far as RE200v3 being the same, I'm just going off of what was in this thread. That approach worked for the RE220v1.

It looks like TheBot got all the way to the step of booting RE200v3 initramfs file via TFTP.

@TheBot, did it boot successfully? What were the test results.

See also: FAQ on adding a device.

Ok, sorry to everyone for this long time not responding to the requests.
First, I though on @slo case, then I couldn't remember if I did something to the device or not, so I've checked it. Then Ive realized that I forgot to mention and maybe in part Ive said it earlier, the very first time Ive opened the device I saw some missing parts on the PCB around the UART interface and I was unable to get anything from it, I got really frustrated and leave it as it was. So the second time I've followed the traces checking for continuity, and found out that TP 1 trace has missing resistor or something like that and since I know that the trace ended in a pad I've just solder a jumper wire.
@jccg.jw I mostly do tests and I barely do some minor firmware mods, haven't got to that point yet on how to trick the manufacturer firmware update so a normal user can flash OpenWrt using this option, may be later I will try what @jedboy said.
What I can confirm is that RE200 v3 firmware tplink_re200-v3-initramfs-kernel.bin loads all the way and gets to the prompt, 5 Ghz works rock solid and so appears to be 2.4 Ghz, in all, works fairly stable to the point I got so far.
Also I've bought a flash chip reader/writer clamp but I haven't yet got a good read on the chip so I can't proceed to flash OpenWrt for once and for all the intramfs firmware (without a chance on maybe bricking the device, not that in sometimes I'm really tempted to do it!), once I got flashed the initramfs firmware then I will surely try the squashfs.

@TheBot It sounds like the Automated Optical Inspector(AOI), and also the lead QA Technician at the manufacturing plant your router/extender came from were both having an off day simultaneously, haha! Or maybe that was a - "well, it still works, and most people don't do development, let's ship it, they'll never know" - moment. "And come to think of it, maybe we should put in a request to finance to upgrade our AOI next year... " :joy:

That said, I know its frustrating to receive technology that is poorly assembled and less than 100% functional, and sorting out why it isn't 100% can really be a mess. Sometimes people come that way too it seems. Maybe that's part of why you got a bum router. But, you patched it up so now you can continue tinkering at your leisure!

No worries about slow responses. It's an increasingly busy world we live in. Thank you for taking the time to respond to us, I really appreciate it. This project serves as a welcome distraction from many difficulties we are all facing, for me.

Continuing from your recent post, it seems like you have the equipment to read/write/and test new firmware builds, and you are also a busy person. I am willing - if there is anything I could do to help you on the software side that would help alleviate some of your task load - to collaborate with you and figure out the proper build parameters based on your findings during test phases. Again, I know your busy and don't need any more pressure, so know that I am thinking of this as @slo moving process that could take months or more to sort through here and there.

It sounds like I could begin working on the tplink_re200-v3-initramfs-kernal.bin source code right away, sorting out the way to implement the mktplinkfw.c so at least the base firmware is supported. That will be one task crossed off the list soon I hope. I am also busy with many things. So I'll share if or when I have any meaningful findings. :smile:

Since you have the ability to directly read and write the chip in the event of soft bricking - when you resolve a way to establish a solid connection - would you be willing to try a bin file if I can figure out how to successfully - and competently - compile it?

On some devices the manufacture may disable the UART interface, so you can't poke around their devices.
I think this is, to hide some potential security issues that are unknown yet on their firmware and/or to prevent from modifying the device firmware mostly because they are almost the same as an greater version one, so that way the manufacture may force you to buy the "newer one" (for instance the RE205 v3 support OneMesh and some others don't, but nevertheless they are on the hardware side the same).
I'm 100% percent in on testing! Also I will try too (whenever I got some time).

Do you remember where you put that jumper wire?

As I still cannot access the bootloader, I finally modified the sources and successfully upgrade my devices using the web-interface.

I created pull requests to add official support to OpenWRT.

1 Like

Sorry @slo for responding so late, unfortunately I was making some progress on this device until I decided to create a full backup of the flash chip before reprogramming it with the indicated OpenWrt firmware, in this process I don't know what I did wrong but apparently I killed the chip (¿could my modifications on the UART port be the culprit? I would never know). Given this, I never got to the point on flashing the chip with the firmware (as said, I only loaded it to the volatile memory and run from there, I was on my way on reprogramming it and that's why I wanted to make a full backup in case if I messed up), then once I flash it then I could do some further testing proving that its stable and nothing happene when the device was rebooted with ll that I could finally confirm the firmware was 100% compatible and post it on the community.
At this point and after trying really hard to revive this device, I finally decided to move on and consider this a dead project, so I threw this device to the bin.
Im really glad that you still decide to proceed on making this device be supported by OpenWrt and do required tasks!
Anyways, if someone is looking for running OpenWrt on this device and finds this post. ¿Is there any link where they might download the firmware and where you can point out what steps you've done to get it working?

Pull request for the firmware-utils have already been merged, so you can build the firmware-utils and use tplink-safeloader to create a factory-image. (Of cause you need a compatible and existing kernel and root-filesystem to do so.)

The pull request for OpenWRT itself is still open. You can already get the sources and build it.
Once it is (hopefully) accepted I guess you can just download the latest snapshot.

The image is almost identical to RE200 images, but GPIOs for LEDs are different.
BTW: With the current stable 23.05.2 release 5GHz WLAN does not work, but that seems to be fixed on the master branch. - At least it is running quite fine on my device.