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. 
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
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
Thanks for all the helpful information so far. I'm not totally sure how to back up the flash memory before proceeding. Additionally, it seems like the filesystem partitions are a lot more granular than the flash layout printed after the factory firmware launches. Here's another snippet of printenv and bdinfo, but I don't think I've gleaned much more details besides the size of each of these partitions.
You don't. Right now you're just going to test ramfs images and not write to the flash memory. And once you've got the ramfs image running, that means you've got a functional openwrt device (at least until you reboot). And with openwrt running you can backup the flash memory super easy in the web interface.
printenv doesn't tell you anything about the flash layout. Only where addresses start for RAM and flash. But you don't need to worry about that.
The important part you need to fix is this file:
At the bottom there is a "partitions" block.
Only thing I did was to split off the "product-info" to be able to reach the MAC address specific to the device.
So apart from "product-info" it should look like the partitions you can see in your bootup pastebin. This is the one for the M4R for reference:
[ 0.470000] Creating 5 MTD partitions on "spi0.0":
[ 0.480000] 0x000000000000-0x000000080000 : "u-boot"
[ 0.480000] 0x000000080000-0x000000280000 : "kernel"
[ 0.490000] 0x000000280000-0x000000e80000 : "rootfs"
[ 0.490000] mtd: partition "rootfs" set to be root filesystem
[ 0.500000] 0x000000e80000-0x000000ff0000 : "config"
[ 0.510000] 0x000000ff0000-0x000001000000 : "art"
And this is the one from your garbled output at the end: (your newest pastbin has this part garbled for whatever reason)
Creating 5 MTD partitions on "spi0.0":
[ 0.480000] 0x000000000000-0x000000080000 : "u-boot"
[ 0.480000] 0x000000080000-0x0000001f0000 : "config"
[ 0.490000] 0x0000001f0000-0x000000200000 : "art"
[ 0.490000] 0x000000200000-0x000000400000 : "kernel"
[ 0.500000] 0x000000400000-0x000001000000 : "rootfs"
Don't worry about the location of the MAC address right now. That you can find by opening the oem firmware you can download from tp-link with an editor like Notepad++. Should be somewhere in there in clear text.
Good stuff, looks like the software is staying up now:
And the modifications I made to the .dts file are here:
Now, with that out of the way, I see some errors that indicate that I might not have reconstructed the partition structure perfectly, and I cannot access the device at 192.168.1.1, but this seems like it's heading the right direction still?
ETA: Disregard, I’ve got an initramfs image with luci built. I’ll poke around that and familiarize myself with OpenWRT as well as make a backup of the existing flash.
Yes, I forgot to mention that you have to explicitly include luci.
The backup you can create by going to System->Backup/Flash Firmware. There you can download every mtd block available. BUT those are the mtd blocks as dictated by your .dts file. So that should be correct first before backing up anything. I haven't checked if any of the partitions are correct but the rootfs partition is too big:
[ 0.548669] mtd: partition "rootfs" extends beyond the end of device "spi0.0" -- size truncated to 0xc00000
If you have corrected that then the next step is to look into the oem firmware file and see how tp-link subdivides the config partition. There should be a "MAC" partition in there.
Edit:
I just checked the newest oem firmware on https://www.tp-link.com/us/support/download/deco-s4/#Firmware
The partitions in that file look like this:
partition fs-uboot base 0x00000 size 0x80000
partition product-info base 0x80000 size 0x05000
partition default-mac base 0x85000 size 0x01000
partition device-id base 0x86000 size 0x01000
partition support-list base 0x87000 size 0x10000
partition user-config base 0xa7000 size 0x10000
partition device-config base 0xb7000 size 0x10000
partition group-info base 0xc7000 size 0x10000
partition partition-table base 0xd7000 size 0x02000
partition soft-version base 0xd9000 size 0x10000
partition profile base 0xe9000 size 0x10000
partition default-config base 0xf9000 size 0x10000
partition url-sig base 0x1e0000 size 0x10000
partition radio base 0x1f0000 size 0x10000
partition os-image base 0x200000 size 0x200000
partition file-system base 0x400000 size 0xc00000
You can see that partition "radio" is the "art" partition, so that's correct. And the "config" partition consists of many sub-blocks. You can split off the "product-info" partition in your .dts file just like I did it. That way you can just use my configuration in my .dts for the mtd-mac-address = <&config 0x8>.
I hope that made any sense.
Further more these are the partitions for the tplink-safeloader.c as you can see at the bottom of my commit here: https://github.com/bobthebuilder4711/openwrtForDecoM4RV1V2/commit/4d009c90500b02bf00bb843893881820968fe2da
It took me a minute of reading, and re-reading both your posts and the .dts file but I think I've got it!
I now have anunderstanding of the reg = <0x.... 0x...> is that the first entry is the address and the second is the size. It seems like my most recent U-Boot log confirms that (no errors!)
I did not yet slice the product-info out of the config partition yet, but I did take the opportunity to back up each mtd block individually.
Edit:
I've re-arranged the dts file and now have it fitting well. I'm not sure if this is supposed to make the MAC on the label under my router appear under the Interaces menu in Luci, but that currently is not happening:
Uptime: 0h 2m 34s
MAC: 00:00:00:01:00:00
RX: 365.10 KB (4530 Pkts.)
TX: 901.87 KB (4576 Pkts.)
IPv4: 192.168.1.1/24
IPv6: fde7:ce27:8a32::1/60```Show what you did exactly. Splitting off the product-info partition moves the default-mac partition to the beginning of the big config partition. that way <&config 0x8> should give you the label MAC you have on the label on the bottom of the device.
You're coming close to being able to flash to the flash memory. If you do keep in mind that all the OpenWrt images ever contain are the kernel and the rootfs. So only overwrite those partitions and nothing else!
If you let the device boot up at the point where the bootloader loads the kernel you should see at which address. That should match with the starting point of the kernel partition.
And you're currently testing with my version as a base. I used to set the rootfs to /dev/mtdblock2 but that's of course nonsense for your device. So definitely change that in your .dts file or remove it altogether. I don't know if it is actually needed or if I tried to fix something with that that wasn't the actual problem while I was still playing around.
You should also take a look at the current master branch of OpenWrt. @KinteLiX added the M4R to that a while back and that's going to be the future reference for our devices anyway: https://github.com/openwrt/openwrt/commit/063e9047cc8b247ea4b04ee3248b99f3212a42f8
Here's the latest diff of my spi structure:
and the latest u-boot output:
I appreciate the tip about moving to master. I'll see if I can get cracking on that.
Hm. Looks okay and should work. But 00:00:00:01:00:00 definitely isn't correct. Maybe open up your backups and search in there for the MAC as it is written on the label?
1 Like