OpenWrt support for Deco S4

I have a Deco S4 system and the stock firmware is crap. Is there anyone thta has open wrt firmware running on a Deco S4? If so please contact me as I would like to flash over to Openwrt to remove the crap stock firmware package.

I know there's been progress on the Deco M4R (which I think is very close to the S4). Thread here: OpenWrt support for TP-Link Deco M4R - #83 by bobthebuilder

However, to install OpenWRT, we need access to the telnet console. I tried using the TP-Link M4R firmware with telnet access found in the thread above using my Deco on the recovery page. Unfortunately, my Deco wouldn't even allow me to install it (perhaps it was due to an issue with the model number). FCC ID of the Deco S4 shows it's an M4R v2 - that's why I thought I'd give it a try.

If anyone has a TP-Link firmware for the Deco S4 where we can obtain telnet access; or has figured out a way to build the firmware so we can load it natively on the S4, I'd love to hear from you. :slight_smile:

It sadly doesn't work like that. The Deco P9 for instance has the exact same GPL sources, the same flash layout and the exact same hardware in it apart from the Powerline stuff and it still needs a firmware specially made for it or it won't flash it. Here we're lucky that there exists a telnet beta firmware too.

But for a device without such a telnet firmware you will have to open it up and gain serial console access. Oftentimes that means having to solder 3 wires to it. I've done that for all of my three Deco M4Rs and if you know what to do it's actually quite easy, but not everybody has a soldering iron or wants to buy a TTL converter.

FCC ID of the Deco S4 shows it's an M4R v2 - that's why I thought I'd give it a try.

Can you tell me where you got that from? I can't find anything online and the list of FCC applications doesn't seem to contain it either: https://fccid.io/TE7

@bobthebuilder Thanks for the reply. :slight_smile: This is on the bottom of my S4. FCC ID is TE7M4RV2.

Okay, that's interesting. And trying to download the GPL source code from TP-Link only results in the source code for the M4R.

That would indeed mean that the hardware is the same.

But it sadly doesn't change the fact that we don't have any black magic way to get OpenWrt on it without someone getting their hands on a firmware version with telnet.

Apart from that you will only be able to get OpenWrt on it by opening the device and attaching a TTL-to-usb converter to it. Which at the end of the day is easy, but of course not as hassle free as just flashing some beta firmware to it and running a dd command.

1 Like

I currently have an S4 open on my desk and have it wired up, but I'm at an absolute loss for next steps. I've loaded up screen on the /dev/ttyUSB0 port with a baud rate of 115200 and waited for the router, which currently has its factory firmware, to finish its bootup routine. The yellow light changes to blue and is flashing, but the screen session shows nothing. Even if the screen session did show that at least my Tx/Rx were good, I wouldn't know what to do next.

Any for dummies guidance from this point forth would be appreciated!

Okay, so after poking around the M4 topics and double-checking my wiring, I am able to access the failsafe console.

What I am currently unable to do is access the U Boot console. The autoboot routine is gibberish, about half a second after the boot executes I start getting legible data over my serial port:

According to a different post about getting into the U Boot console, tpl is the combination of keys to access the console. When I spam t p l into the terminal server it seems to kill the boot process entirely. I do not get a command prompt, and all Tx from the router ceases.

Not helping with your problem but can you provide a few photos of the board's sides and mark where you attached TX, RX and GND? (I hope you didn't attach Vcc.)

Just a thought: If you spam tpl then the bootloader switches to its prompt so of course no more output. But have you tried pressing buttons after that? Hit Enter? The input is usually visible, so maybe just wait until the connection becomes usable and then you might be able to use the prompt?

Further more it's strange that the output becomes readable in the middle of the kernel bootup. What kind of connector are you using between your computer and the router? Maybe it's just garbage and you need a different one?

Here are the dongle and the 3 wires. No VCC is connected. As I said on Reddit, pyserial does read the port well, PuTTY does not. Screen is a lost cause.

Yellow goes to dongle TX, blue to dongle RX

You are correct, what I took for a halt was actually the command prompt. So after I get to that point I hit return a few times and then can start typing help. It also seems like the input (e.g. help) is written to serial correctly based on the repeatability of the output. It seems possible that from here I could attempt the flash blind.

Since you already have serial access you should try an initramfs image first. It's only loaded into RAM and executed and nothing is ever written to the flash memory. That way you can't brick the device while playing around.

But yes, you can definitely try transferring and executing the initramfs image blind.

The last ungarbled output of your pastbin link tells us that the flash layout for your device is different than for the M4R. So you will have to compile your own firmware at some point once you want to actually flash it. But I guess the initramfs image for the M4R should work for testing purposed even if it doesn't work 100%.

There currently only seems to be a snapshot version here: https://downloads.openwrt.org/snapshots/targets/ath79/generic/

Although I definitely know that my v19.07.8 initramfs works on the M4R and thus I recommend using that:

You will need some tftp server to serve the firmware file. I'm using OpenTFTPServer on Windows but there are many others out there if you're using Linux.

If all that is set up then you need to load and execute the image. This is what I did back when I played around with my M4R. The serverip and ipaddr have defaults but I can't remember what those were and they might be different for your bootloader, so better set them to what you want.
"openwrt-initramfs.bin" is just the name of the file on the server. You can call it a.bin if you don't want to type that much and don't have verification.
And 0x81000000 should be some address in RAM which I hope works for your device the same way since the hardware is the same.

setenv serverip 192.168.0.1
setenv ipaddr 192.168.0.2
tftpboot 0x81000000 openwrt-initramfs.bin
bootm 0x8100000

Here is an example of me doing exactly that with my M4R:

Edit:
If you can, please get a complete readable output of your device booting with that python script. You will need the flash layout and you also want to know where the bootloader boots the kernel from to verify that your custom image's dts file is correct.

I've switched to Picocom as my terminal emulator which has resolved my garbled mess issues at bootup quite nicely. Here's the boot, plus a copy of the initramfs image booting on the device and hitting kernel panic.

The kernel panik isn't that great, but hey, it's a big step in the right direction that you now have clean access to the bootloader and can test out ramfs images.

From what I can gather from the log (and I'm far from an expert here) you still need to create your own firmware with a better fitting .dts file.

I suggest you clone my github repo to a local folder and play around with that. Just for testing you don't have to change any of the 'M4R' names because that's just to select the right device during 'make menuconfig'. But the partitions in the .dts should fit the partition as shown in your log when the oem firmware boots up.

Follow this guide to get your build environment up and running: https://openwrt.org/docs/guide-developer/toolchain/beginners-build-guide

You should also definitely back up the flash memory in case you accidentally overwrite the config and art sections when you actually flash an image. The art section for instance contains the radio calibration data and that should not be lost for the device to function properly. If the initramfs image actually boots up eventually you can easily dump the whole flash memory via the backup functionality in luci.

If you encounter any problems, just ask, but after watching Stranger Things all night I'm going to go sleep now and probably won't answer for half a day.

1 Like