Ok, so I have this setup at my home a TP-Link Archer C7 v5.0 with two TP-Link RE205 v3.0 with that I can have OneMesh network setup.
I know that OpenWrt fully support the router but there isn't post regarding of supporting the range extender (RE205 v3.0) so I can have all the setup running OpenWrt (if I change just the main router to OpenWrt firmware I would loose the Mesh network function since there is n nothing about how OneMesh works so I can reproduce it on a non-tplink firmware).
Anyways opening up the RE205 v3.0 device so I can inspect what's running, Its main SoC is a Mediatek MT7610EN and I found that a user on this forum (Compile 'kmod-mt7610e' for MT7610EN) has run OpenWrt with it, is this could be a starting point?
What could be some sort of safe option without resulting in a bricked device?
Running an initramfs-image from RAM should be a safe option.
I tried to access the bootloader to start an OpenWrt-image, or at least to be able to recover if something went wrong.
I connected ground of my serial interface to TP5.
TP4 seems to be 3.3V
TP2 is TX (connect to RX of the serial interface)
I thought TP1 might be RX, but TP1 seems to be pulled to ground.
I can see output from the bootloader (u-boot 1.1.3). But I cannot interrupt it, I cannot send commands to the bootloader.
Did anybody had more luck than I?
Did anybody found TP3?
This is the output from the bootloader:
cid reg:00010102, cid:1[04010D07][04010D0A]
DDR Calibration DQS reg = 00008988
DDR Calibration MEMCTRL reg = 0E120003
U-Boot 1.1.3 (Nov 28 2020 - 10:44:01)
Board: Ralink APSoC DRAM: 64 MB
relocate_code Pointer at: 83fb8000
flash manufacture id: 20, device id 70 17
Warning: un-recognized chip ID, please update bootloader!
*** Warning - bad CRC, using default environment
============================================
Ralink UBoot Version: 5.0.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:Nov 28 2020 Time:10:44:01
============================================
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 3
0
3: System Boot system code via Flash.
tplink_turn_off_led
## Booting image at bc020000 ...
text base: 80000000
entry point: 8000c150
Uncompressing Kernel Image ... OK
No initrd
## Transferring control to Linux (at address 8000c150) ...
## Giving linux memsize in MB, 64
Starting kernel ...
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.
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.
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...)
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.
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.
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...
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!
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. 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?
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.
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.