TP-Link re450 v3 - Trouble writing to certain flash addresses

Hey all,

I'm having a bit of trouble writing to certain addresses using uboot. I've tried:

  • Doing a tftp followed by a cp.b. After the cp.b, everything is still 0 bytes
  • Doing a manual mm.l and inputting values manually. The values seem to stay around temporarily but booting a kernel or resetting the device wipes them.
  • Doing a mw.b 0x9f024000 0xff 0x8000. If I extend the write to one more byte, everything becomes 0x00 again.
  • I've also tried doing an erase which doesn't seem to clear the data:
Dragonfly> erase 0x9f020000 +0x10000
Erase Flash from 0x9f020000 to 0x9f02ffff in Bank # 1
First 0x2 last 0x2 sector size 0x10000                                                                                                                                                                                                                                         2
Erased 1 sectors

Maybe there is something I'm missing?

Dragonfly> printenv
bootargs=console=ttyS0,115200 root=31:03 rootfstype=squashfs init=/sbin/init mtdparts=ath-nor0:128k(u-boot),192k(config),768k(kernel),7040k(rootfs),64k(art)
bootcmd=bootm 0x9f050000
bootdelay=1
baudrate=115200
ethaddr=<removed>
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}ap152${bc}-squashfs&&erase 0x9f120000 +$filesize&&cp.b $fileaddr 0x9f120000 $filesize
lk=tftp 0x80060000 ${dir}vmlinux${bc}.lzma.uImage&&erase 0x9f020000 +$filesize&&cp.b $fileaddr 0x9f020000 $filesize
stdin=serial
stdout=serial
stderr=serial
ethact=eth0

Environment size: 676/65532 bytes

The 0x00 gaps seem to be around 0x4000 bytes in size such as 0x9f024000-0x9f027fff, 0x9f02c000-0x9f02ffff, etc. Some of them are in the kernel sector so i can't flash a kernel.

Maybe a u-boot bug dealing with the flash chip? Manufacturers really don't test or care if the u-boot they ship can do anything beyond de-LZMA and launch their firmware.

The preferred way to install or debrick OpenWrt is to TFTP in your model's initramfs image (available in the snapshots directory) and boot it from RAM, then use sysupgrade to write a sysupgrade image to the flash. Using u-boot to directly erase and write flash is prone to errors which can remove vital partitions like u-boot and ART.

Hey @mk24,

Unfortunately, I tried that and these gaps are still there and booting still fails with something in LzmaDecode. I don't have the full error as the device restarts too quickly so the full message isn't printed over the serial port.

Commands I ran:

Dragonfly> tftp 0x81000000 openwrt-ath79-generic-tplink_re450-v3-initramfs-kernel.bin
...
Dragonfly> bootm 0x81000000
...

Then once it is booted I scp over the sysupgrade version and run:

sysupgrade -n openwrt-ath79-generic-tplink_re450-v3-squashfs-sysupgrade.bin

Rebooting still doesn't work though.

Something that is a bit odd though is the stock firmware (I can boot this from memory if I write the rootfs and tftp the kernel) has a different mtd list:

5 cmdlinepart partitions found on MTD device ath-nor0
Creating 5 MTD partitions on "ath-nor0":
0x000000000000-0x000000020000 : "u-boot"
0x000000020000-0x000000050000 : "config"
0x000000050000-0x000000110000 : "kernel"
0x000000110000-0x0000007f0000 : "rootfs"
0x0000007f0000-0x000000800000 : "art"
@OpenWrt:/# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00010000 "u-boot"
mtd1: 00030000 00010000 "config"
mtd2: 000c0000 00010000 "kernel"
mtd3: 006e0000 00010000 "rootfs"
mtd4: 00010000 00010000 "art"

than openwrt:

[    0.458329] spi-nor spi0.0: s25fl064k (8192 Kbytes)
[    0.463443] 7 fixed-partitions partitions found on MTD device spi0.0
[    0.470015] Creating 7 MTD partitions on "spi0.0":
[    0.474990] 0x000000000000-0x000000020000 : "u-boot"
[    0.480982] 0x000000020000-0x000000022000 : "info"
[    0.486810] 0x000000022000-0x000000024000 : "partition-table"
[    0.493598] 0x000000024000-0x00000002e000 : "info2"
[    0.499496] 0x00000002e000-0x000000050000 : "config"
[    0.505484] 0x000000050000-0x0000007f0000 : "firmware"
[    0.516704] 2 tplink-fw partitions found on MTD device firmware
[    0.522874] Creating 2 MTD partitions on "firmware":
[    0.528015] 0x000000000000-0x0000000bdaa1 : "kernel"
[    0.534035] 0x0000000c0000-0x0000007a0000 : "rootfs"
[    0.539963] mtd: device 7 (rootfs) set to be root filesystem
[    0.547635] 1 squashfs-split partitions found on MTD device rootfs
[    0.554093] 0x000000790000-0x0000007a0000 : "rootfs_data"
[    0.560519] 0x0000007f0000-0x000000800000 : "art"
root@OpenWrt:/# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00010000 "u-boot"
mtd1: 00002000 00010000 "info"
mtd2: 00002000 00010000 "partition-table"
mtd3: 0000a000 00010000 "info2"
mtd4: 00022000 00010000 "config"
mtd5: 007a0000 00010000 "firmware"
mtd6: 000bdaa1 00010000 "kernel"
mtd7: 006e0000 00010000 "rootfs"
mtd8: 00010000 00010000 "rootfs_data"
mtd9: 00010000 00010000 "art"

Also, these errors appear with the stock firmware now:

[NM_Error](nvrammanager_readPtnFromNvram) 00716: partition profile is empty
[NM_Error](nvrammanager_readPtnFromNvram) 00716: partition user-config is empty
[NM_Error](nvrammanager_readPtnFromNvram) 00716: partition default-config is empty
[NM_Error](nvrammanager_writePtnToNvram) 00571: file size error!

Could it be some of these 0x00 areas are some other kind of memory that is mapped in?
Or could it be that the erase size is larger than some of the mtd partitions on openwrt?

Looks like it was a faulty device. I have a second device which I just did some tests on and it "just works".

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