OpenWrt Forum Archive

Topic: TL-R470T+ support

The content of this topic has been archived on 22 Mar 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi, I have a router (TP-Link TL-R470T+ v2.1) and I want to know if it works with OpenWRT. (i have not found it on the supported devices wiki). The product page isn't very useful[0] and I can not find chipset details.

Is there a simple and safe way to know if this piece of hardware supports OpenWRT?

0: http://www.tp-link.us/products/details/ … 0T%2B#spec

The chipset is QCA9533 (Atheros). Another router with the same board (TL-WR841N) appears to have support. I haven't tried flashing mine yet as I've been unable to get the serial connection to work and don't want to brick my router without a way back. It looks like people have had to add pull-up resistors to the TL-WR841N to get serial working. I've tried that, but it's still not ... connecty. TP-Link may have done something tricky to disable serial that needs to be worked around. If anyone has any other suggestions, please speak up.

Here's a look at the PCB:

http://i1018.photobucket.com/albums/af308/diepiapaopolopo/IMG_2360_zps0fcee3e0.jpg

It looks like quite the machine. ddr2 memory and even gas spark gaps. Thumbs up!.

On the other hand, the PSU is grose. ditch that.

You could find some really usefull information by tapping into that serial connection (The headers next to 2021500165).

They should be 3,3V TTL output, and should spit out beautifull debug info during bootup.

If you're in for playing, it is highly recommendable that you get one of these:
http://www.dx.com/p/crius-ftdi-basic-br … FA2XRaH0yw

Make sure to get a 3,3v capable converter, as everything these days is 3,3v. And buy a FTDI one. the 2 bucks you'll pay will avoid a lot of yalling at the non-working drivers of cheap usb-to-ttl dongles.

@carrapato

Yeah, I soldered those headers onto the serial pads myself. I've got a few USB-UARTs lying around, too. With a multi-meter, I've managed to identify VCC, GND, Tx/Rx, Tx/Rx (left to right in the photo) but no combination of connections has resulted in any debug output. You can see more details of my travails here:

https://forum.openwrt.org/viewtopic.php?id=53652

It looks like your RX (Presumably) line dies at R157, take a look at that.

Other than that, i really recommend you to get a 3,3v capable UART converter, as the underlying logic at the processor is probably 1,8v / 2,5v mixed, and then scaled to 3v3.
It is my experience that those things don't like 5V signalling, nor resistor-dividers, as they tend to make the edges of the signals "rounder.
Bottomline: there are already enough cows in that bus, get a trustable UART on your side of it.


I used to have the MAX232 homebrew thing, never let me off hand, until i switched to a RS232-less PC.
Then i needed a USB-UART thing, and none ever worked as they should.

Get an original FTDI one, most others have buggy drivers, or are chinese scam 8081.

don't even bother if you have one that has the chip-on-board with that epoxy blob. those make you scratch your head more often than actually communicate.


Slightly off-topic:  I was thinking of getting one of those things [r470+/r480+] to play with, but i got a shipment of rb750's, and for $40 they do kinda make hell freeze over (if you just want the routing, not the troughpout).

How bad is the factory firmware? Does that load-ballancing thing work propperly?
As a paperweight, is it usefull enough having, or it is too-light even to be a paperweight?



Edit:

Can you try to take a Hi-Res picture from the traces between the CPU and the headers?
Taking a look at the bottom of the PCB might prove usefull.

(Last edited by carrapato on 29 Oct 2014, 03:56)

Thanks, I'll look into a FTDI device.

I saw that R157 gap, too. That could be to make the serial read-only (if I ever get read working :-p).

The factory firmware on the r470t is pretty lousy. Port forwarding doesn't work (I found others complaining of the same thing online) and there's no IPv6. The translation from (I assume) chinese leaves a bit to be desired. Headings don't really help find some of the bits of functionality one might look for. I haven't tried the dual WAN feature yet. The metal case is awesome--nice and heavy. The power supply (someone else already ridiculed it slightly) makes a soft hum when the thing is plugged in, but it's really only noticeable when the case is open. The case is easy to open--two screws that aren't hidden by rubber feet or anything. The whole thing feels nice and sturdy. The internal hardware seems like it would be pretty capable, too, if it wasn't held back by the lousy firmware.

Here's a better image of the PCB. You should be able to zoom in a long way:
http://i1018.photobucket.com/albums/af308/diepiapaopolopo/FullSizeRender_zpsdf85a6d2.jpg

Now, i've been scratching my head thinking what on earth that lot of cmos logic is doing there.

Anyone with ideas about that?

After following someone's advice, I got the serial connection working (read and write). Pins are (starting at JP1):

TX
RX
GND
VCC

I had to solder bridge R157 and R169. Finally, I currently have to disconnect TX (JP1) while powering on the router and hitting any key repeatedly. Once u-boot drops to a command prompt, I can reconnect TX and have two-way communication with u-boot. I'm not sure, but the have-to-disconnect-tx-on-boot thing might be due to the solder bridge (instead of an actual resistor) on R157 (leads to TX).

printenv gives the following output (watch the breaks on the long lines):

ath> printenv
bootargs=console=ttyS0,115200 root=31:02 rootfstype=jffs2 init=/sbin/init mtdparts=ath-nor0:256k(u-boot),64k(u-boot-env),2240k(rootfs),1408k(uImage),64k(mib0),64k(ART)
bootcmd=go 0x9f040000
bootdelay=1
baudrate=115200
ethaddr=0x00:0xaa:0xbb:0xcc:0xdd:0xee
ipaddr=192.168.1.1
serverip=192.168.1.10
dir=
lu=tftp 0x80060000 ${dir}u-boot.bin&&erase 0x9f000000 +$filesize&&cp.b $fileaddr 0x9f000000 $filesize
lf=tftp 0x80060000 ${dir}board953x${bc}-jffs2&&erase 0x9f050000 +0x630000&&cp.b $fileaddr 0x9f050000 $filesize
lk=tftp 0x80060000 ${dir}vmlinux${bc}.lzma.uImage&&erase 0x9f680000 +$filesize&&cp.b $fileaddr 0x9f680000 $filesize
stdin=serial
stdout=serial
stderr=serial
ethact=eth0

Environment size: 684/65532 bytes

I've tried copying a firmware for another device running the same SoC (TL-WR841N v9) into address 0x9f040000, changing bootargs to use rootfstype=squashfs, and then bootm 0x9f040000, but I get a bad magic number error. I've also tried their `go` command with the same address instead, but it just hangs.

ath> bootm 0x9f040000
## Booting image at 9f040000 ...
Bad Magic Number
ath> go 0x9f040000
## Starting application at 0x9F040000 ...

The fact that u-boot is configured to "start [an] application" instead of just using bootm makes me wonder if there was something magical that was in 0x9f040000 before I nuked it :-/

Any ideas? And thanks again for all the previous suggestions.

brnt wrote:

The fact that u-boot is configured to "start [an] application" instead of just using bootm makes me wonder if there was something magical that was in 0x9f040000 before I nuked it :-/

Never mind this bit. I've been reading about u-boot and bootm and I've learned that `go` just just a environment-less application execution command.

(Last edited by brnt on 23 Dec 2014, 04:46)

How is it going on? Any success booting openwrt? Do you know, if V3 is compatible?

Sorry for the slow response. No, I haven't messed around with this any more. It's a shame---this looks like a great little router, but it's a bit of a pain to figure out.

The discussion might have continued from here.