TL-WR810N from dd-wrt to OpenWrt

Installing and Using OpenWrt
1

The short version: Can anyone tell me if there's a good way to get my WR810N switched from dd-wrt to OpenWrt?

So I've been using OpenWrt since the good ol' wrt54gl days. I have a couple of TL-WR810N (US) devices that are almost useless to me with the factory firmware but their specs are decent enough that I decided to try to put OpenWrt on them tonight. However, although I found .bin files for it in the download section, they wouldn't install because the WR810N is locked by default to prevent 3rd party firmware. I found that someone at dd-wrt had figured a way to make a dd-wrt image that looked like an authorized image so I installed that thinking it would get me past the lockout, and that I could then just flash to OpenWrt from dd-wrt. Sure enough, dd-wrt installed fine, but I can't seem to get OpenWrt to take from the web flash. I've never used dd-wrt before tonight, and I know OpenWrt well enough that I'd rather not run dd-wrt on these if I don't have to, I already don't like dd-wrt from what little I've seen of it tonight. So, long story short, can anyone tell me if there's a good way to get my WR810Ns switched over to OpenWrt?

Thoughts? Thanks much!

2

v1? v2? https://openwrt.org/toh/tp-link/tl-wr810n

v2 may be dicey these days for much more than basic routing and wireless, since it only has 32 MB of RAM.

Would you be able to log into the DD-WRT command line and post the output of cat /proc/mtd and the section of dmesg that shows how its flash is formatted.

From a different device, it might look something like

root@office:/home/jeff# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00010000 "u-boot"
mtd1: 00fd0000 00010000 "firmware"
mtd2: 00184545 00010000 "kernel"
mtd3: 00e4bab8 00010000 "rootfs"
mtd4: 00470000 00010000 "rootfs_data"
mtd5: 00010000 00010000 "art"

and

[    0.399185] m25p80 spi0.0: w25q128 (16384 Kbytes)
[    0.403994] 3 fixed-partitions partitions found on MTD device spi0.0
[    0.410452] Creating 3 MTD partitions on "spi0.0":
[    0.415323] 0x000000000000-0x000000020000 : "u-boot"
[    0.421012] 0x000000020000-0x000000ff0000 : "firmware"
[    0.477675] 2 tplink-fw partitions found on MTD device firmware
[    0.483689] 0x000000020000-0x0000001a4545 : "kernel"
[    0.489356] 0x0000001a4548-0x000000ff0000 : "rootfs"
[    0.494999] mtd: device 3 (rootfs) set to be root filesystem
[    0.500778] 1 squashfs-split partitions found on MTD device rootfs
[    0.507089] 0x000000b80000-0x000000ff0000 : "rootfs_data"
[    0.513150] 0x000000ff0000-0x000001000000 : "art"
3

Yes, I should have mentioned that originally -- the two I have are the older but better spec'd v1.

I first tried the injection method here with no joy, the router still rejected the openwrt bins, and that's when I caved to try dd-wrt as a middleman.

Here's the mtd as it looks under dd-wrt.

root@DD-WRT:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00010000 "RedBoot"
mtd1: 007c0000 00010000 "linux"
mtd2: 005a8000 00010000 "rootfs"
mtd3: 000f0000 00010000 "ddwrt"
mtd4: 00010000 00010000 "nvram"
mtd5: 00010000 00010000 "board_config"
mtd6: 00800000 00010000 "fullflash"
mtd7: 00020000 00010000 "fullboot"
mtd8: 00010000 00010000 "uboot-env"

Thoughts? Thanks.

4

Thinking is that if the partition scheme is compatible (and DD-WRT didn't change the boot loader in a strange way), use the proper low-level tool to write an OpenWrt image to the flash.

Edit: Being very clear, this is thinking, not direction to blindly flash an image at this point!

2 Likes
5

Yes, I was thinking exactly the same thing but the OpenWrt wiki doesn't specifically show the US version MTD layout so I wasn't confident to jump to a brute-force mtd next.

However, I found this similar issue and the layout the openwrt user showed there is essentially the same, and they succeeded by overwriting the dd-wrt linux partition with the appropriate openwrt-factory. I really wouldn't be too sad if it bricked, and I'd still have one left, so I decided it was worth the risk to try the same thing, and voila, my wr810n-v1 is now running 18.06.2, end results shown below.

root@OpenWrt:~# cat /proc/cpuinfo
system type             : Qualcomm Atheros QCA9533 ver 2 rev 0
machine                 : TP-LINK TL-WR810N
processor               : 0
cpu model               : MIPS 24Kc V7.4
BogoMIPS                : 432.53
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 16
extra interrupt vector  : yes
hardware watchpoint     : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb]
isa                     : mips1 mips2 mips32r1 mips32r2
ASEs implemented        : mips16
shadow register sets    : 1
kscratch registers      : 0
package                 : 0
core                    : 0
VCED exceptions         : not available
VCEI exceptions         : not available

root@OpenWrt:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00010000 "u-boot"
mtd1: 00150438 00010000 "kernel"
mtd2: 0067fbc8 00010000 "rootfs"
mtd3: 00430000 00010000 "rootfs_data"
mtd4: 00010000 00010000 "art"
mtd5: 007d0000 00010000 "firmware"

root@OpenWrt:~# free
             total       used       free     shared    buffers     cached
Mem:         60296      19796      40500        656       1940       5784
-/+ buffers/cache:      12072      48224
Swap:            0          0          0

root@OpenWrt:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 2.5M      2.5M         0 100% /rom
tmpfs                    29.4M    656.0K     28.8M   2% /tmp
/dev/mtdblock3            4.2M    296.0K      3.9M   7% /overlay
overlayfs:/overlay        4.2M    296.0K      3.9M   7% /
tmpfs                   512.0K         0    512.0K   0% /dev
1 Like
6

Glad you had success!

No "complaints" about problems with not finding the ART data?

For the ath79 version, qca9531_tplink_tl-wr810n-v1.dts includes qca953x_tplink_tl-wr810n.dtsi without modifying the partition layout. (This may not apply to the ar71xx version that would be present in 18.06 and 19.07 and hasn't yet been removed from master)

        flash@0 {
                compatible = "jedec,spi-nor";
                reg = <0>;
                spi-max-frequency = <25000000>;

                partitions {
                        compatible = "fixed-partitions";
                        #address-cells = <1>;
                        #size-cells = <1>;

                        uboot:  partition@0 {
                                label = "u-boot";
                                reg = <0x000000 0x020000>;
                                read-only;
                        };

                        partition@20000 {
                                compatible = "tplink,firmware";
                                label = "firmware";
                                reg = <0x020000 0x7d0000>;
                        };

                        art: partition@7f0000 {
                                label = "art";
                                reg = <0x7f0000 0x010000>;
                                read-only;
                        };
                };
        };

The firmware partition, as I understand it, is auto-split during early boot by the OpenWrt-patched kernel into kernel, rootfs, and rootfs_data

7

Agreed, here's what I think is relevant from each boot, let me know if there's something else you'd like to see that you think would be helpful to contribute.

[    0.831961] 5 tp-link partitions found on MTD device spi0.0
[    0.837759] Creating 5 MTD partitions on "spi0.0":
[    0.842712] 0x000000000000-0x000000020000 : "u-boot"
[    0.850211] 0x000000020000-0x000000170438 : "kernel"
[    0.857967] 0x000000170438-0x0000007f0000 : "rootfs"
[    0.864998] mtd: device 2 (rootfs) set to be root filesystem
[    0.870990] 1 squashfs-split partitions found on MTD device rootfs
[    0.877399] 0x0000003c0000-0x0000007f0000 : "rootfs_data"
[    0.885582] 0x0000007f0000-0x000000800000 : "art"
[    0.893058] 0x000000020000-0x0000007f0000 : "firmware"
8

As long as it properly extracted the ART data and there aren't any wireless driver errors as they load, you're probably OK.

1 Like
9

Yes, it looks good. I can see other WiFi from it, and other devices can see and connect to it, so I think I'm golden! One down, one to go!

10

Use the sysupgrade when writing directly to flash.

11

Now that I have openwrt installed, of course, for future updates. But I don't think using dd-wrt's sysupgrade (if they even have a similar script) to install an openwrt image would've been appropriate or safe, if it worked at all. mtd seemed the best tool under the circumstances and, indeed, it did the trick perfectly.

12

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.