Fixing/replacing uboot on Archer A7v5

Installing and Using OpenWrt
1

In the process of migrating from DD-WRT to OpenWRT I ended up with a bad flash at some point along the way. And during "troubleshooting" I ended up making things worse, but then better, and worse, and slightly better now.

I'm close to the finish line of fixing this thing...
... but need to fix/replace uboot. And maybe reflash after correcting the flash layout?

Current setup:
This board does not have JTAG but I have serial console connected, with TFTP server running on my laptop. No issues with TFTP transfer with TPlink recovery mode (via 192.168.0.66), and TFTP from uboot's CLI (via 192.168.0.10) works as well, but I don't know what addresses to load/erase/copy or flash bins to use for flashing with this method. I have kmod-mtd-rw installed in psuedo-booting openwrt install, so I can reflash bootloader from running system, but don't know what should be overwritten and with which file.

Limitation on flashing: The normal factory recovery via TFTP works only with the openwrt's factory-to-openwrt image, NOT oem factory image due to software version checks (TFTP downloads OK but refuses to flash oem firmware due to installed xxx-WRT version "7.0" > oem firmware file's v "1.2"), and NOT dd-wrt factory-to-ddwrt either for other weird reasons. TFTP from uboot cli appears to have no limitations, but again, not sure what files/addresses to use, or if the file length field and/or other file headers on the factory-bin needs to be cut off prior to flash, etc.

Problem 1) Partially corrupted uboot, only "manual boot" works, plus screwed up flash layout (prob 2)
Successfully flashed openwrt factory bin, but it will not boot.

Firmware for this device normally has a double-uboot start, uboot booting twice before launching the kernel. Currently, the initial uboot run works (and I am able to get uboot cli through that first run) but the system freezes/stops when it tries to run uboot the second time. See "known good" boot log: https://openwrt.org/toh/tp-link/archer_a7_v5#openwrt_bootlog

Last console spew of normal broken boot startup:

U-Boot 1.1.4-g8fda4a3b-dirty (Feb 24 2018 - 18:17:06)

ap152 - Dragonfly 1.0

DRAM:  128 MB
Top of RAM usable for U-Boot at: 88000000
Reserving 393k for U-Boot at: 87f9c000
Reserving 16448k for malloc() at: 86f8c000
Reserving 44 Bytes for Board Info at: 86f8bfd4
Reserving 36 Bytes for Global Data at: 86f8bfb0
Reserving 128k for boot params() at: 86f6bfb0
Stack Pointer at: 86f6bf98
Now running in RAM - U-Boot at: 87f9c000
Flash Manuf Id 0xef, DeviceId0 0x40, DeviceId1 0x18
flash size 16MB, sector count = 256
Flash: 16 MB
Using default environment

In:    serial
Out:   serial
Err:   serial
Net:   ath_gmac_enet_initialize...
No valid address in Flash. Using fixed address
ath_gmac_enet_initialize: reset mask:c02200
athr_mgmt_init ::done
Dragonfly  ----> S17 PHY *
athrs17_reg_init: complete
SGMII in forced mode
athr_gmac_sgmii_setup SGMII done
: cfg1 0x80000000 cfg2 0x7114
eth0: 00:23:7f:55:22:ad
eth0 up
eth0
Setting 0x181162c0 to 0x40802100
factory boot check integer ok.
factory boot load fs uboot len 131072 to addr 0x80010000.
Hit any key to stop autoboot:  0
## Starting application at 0x80010000 ...
(Hangs/freezes/halts ...)

If I break into the uboot cli, I can manually boot the kernel and it will run, but I have to do this manual process everytime the device re/boots:

(...)
factory boot check integer ok.
factory boot load fs uboot len 131072 to addr 0x80010000.
Hit any key to stop autoboot:  0
**ath> boot**
## Booting image at 9f040000 ...
   Image Name:   MIPS OpenWrt Linux-5.10.146
   Created:      2022-10-14  22:44:41 UTC
   Image Type:   MIPS Linux Kernel Image (lzma compressed)
   Data Size:    2244051 Bytes =  2.1 MB
   Load Address: 80060000
   Entry Point:  80060000
   Verifying Checksum at 0x9f040040 ...OK
   Uncompressing Kernel Image ... OK
No initrd
## Transferring control to Linux (at address 80060000) ...
## Giving linux memsize in bytes, 134217728

Starting kernel ...

[    0.000000] Linux version 5.10.146 (builder@buildhost) (mips-openwrt-linux-musl-gcc (OpenWrt GCC 11.2.0 r19803-9a599fee93) 11.2.0, GNU ld (GNU Binutils) 2.37) #0 Fri Oct 14 22:44:41 2022
[    0.000000] printk: bootconsole [early0] enabled
[    0.000000] CPU0 revision is: 00019750 (MIPS 74Kc)
[    0.000000] MIPS: machine is TP-Link Archer A7 v5
[    0.000000] SoC: Qualcomm Atheros QCA956X ver 1 rev 0
(...)

Problem 2) While attempting to get a "clean/normal flash", I upgraded the factory bin with the sysupgrade bin. I can set password/change settings and nvram is retained across reboots. But the flash layout seems to be messed up.

Layout after flashing factory bin:

[    0.455991] 2 uimage-fw partitions found on MTD device firmware
[    0.462159] Creating 2 MTD partitions on "firmware":
[    0.467300] 0x000000000000-0x000000230000 : "kernel"
[    0.473352] 0x000000230000-0x000000ec0000 : "rootfs"
[    0.480736] mtd: device 4 (rootfs) set to be root filesystem
[    0.486684] 1 squashfs-split partitions found on MTD device rootfs
[    0.493130] 0x000000620000-0x000000ec0000 : "rootfs_data"
[    0.500361] 0x000000f40000-0x000000f60000 : "info"
[    0.506353] 0x000000f60000-0x000000fb0000 : "config"
[    0.513901] 0x000000fc0000-0x000000fd0000 : "partition-table"
[    0.520808] 0x000000ff0000-0x000001000000 : "art"

Layout after flashing sysupgrade bin:

[    0.426513] Creating 7 MTD partitions on "spi0.0":
[    0.431532] 0x000000000000-0x000000020000 : "factory-uboot"
[    0.442047] 0x000000020000-0x000000040000 : "u-boot"
[    0.448097] 0x000000040000-0x000000f00000 : "firmware"
[    0.455989] 2 uimage-fw partitions found on MTD device firmware
[    0.462161] Creating 2 MTD partitions on "firmware":
[    0.467303] 0x000000000000-0x000000223e13 : "kernel"
[    0.472457] mtd: partition "kernel" doesn't end on an erase/write block -- force read-only
[    0.482629] 0x000000223e13-0x000000ec0000 : "rootfs"
[    0.487771] mtd: partition "rootfs" doesn't start on an erase/write block boundary -- force read-only
[    0.498131] mtd: device 4 (rootfs) set to be root filesystem
[    0.504901] 1 squashfs-split partitions found on MTD device rootfs
[    0.511345] 0x000000610000-0x000000ec0000 : "rootfs_data"
[    0.517824] 0x000000f40000-0x000000f60000 : "info"
[    0.525258] 0x000000f60000-0x000000fb0000 : "config"
[    0.531342] 0x000000fc0000-0x000000fd0000 : "partition-table"
[    0.539576] 0x000000ff0000-0x000001000000 : "art"

I'm thinking the whole thing needs to be erased and reflashed, uboot included, but I don't know which method is best (mtd write mtdX-Z, uboot cli> tftp 0x???? which.bin, etc). And no real clue on which files to use for flashing via uboot cli versus other methods, nor addresses/mem map, etc.

So.... What is the best approach to fixing this thing?
I appreciate input on this. Thanks!

2

What does your printenv in u-boot say?

3

Given that TP-Link has changed their firmware structure a couple of times over the last decade (and me only being familiar with the -very- old ones), I'll refrain from giving direct advice, but…

If you (really) break u-boot, the device will be dead - while recovering that is still possible with an spi-nor writer and external flashing, this is considerably harder (requires desoldering/ resoldering the flash chip, an spi adapter/ clamp and intimate familiarity with flashrom and the exact on-flash firmware structure).

ART is specific to your individual device, if you lose it, it's gone - and with that all wireless capabilities of your device.

u-boot-env is appended to the end of the u-boot partition, if you lose it, it's gone (and with that device specifics like ethernet MAC addresses, WPS pins, etc. - and yes, also the h/w IDs.

So make backups of everything first, twice, thrice And don't do anything you're not confident with and aren't 100% sure what it does.

Apart from that, I'm not seeing anything that would warrant touching the bootloader there (but I don't have the device on my desk either, nor would be familiar with that model) I'd rather tftpboot an OpenWrt initramfs image, sysupgrade a sysupgrade image from the RAM booted device and would then continue debugging from there (including cleaning up the -potential- mess in ubootenv dd-wrt might have left behind).

Don't take dynamite to your fly fishing trip with the kids,

4

Before doing anything to the uboot, it's better to take a full flash backup from spi programmer. Otherwise like users mentioned above, you may end up hard bricking your device if something goes wrong.

5

the initramfs is non destructive, you can boot and backup everything using it.

7

I must strongly disagree. How else are the kids gonna learn?!? Hehe.

For all practical purposes, if I have to keep a serial terminal open to manually type in "boot" or "bootm 0x9f040000" ever device reset in order for the kernel to get loaded, then it is bricked. Soldering at this point is not needed since still have TFTP (although I don't know what needs to be TFTPed and to where...), but if I reaaaaalllllly messed it up, I recently bought a chip programmer with various package adapters for a completely unrelated project, so worst case scenario, with some other learning curves I should be able to resurrect this thing if I had to. But in that case I would still need to know what files/bins/flash/etc to use and what addresses the various bits and pieces need to go...

I have backups of each MTD partition from when it was still running DD-wrt, but I'm thinking that ddwrt was a contributing factor to my current mess switching embedded platforms.

Uboot environment:

eth0: 00:03:7f:09:0b:ad
eth0 up
eth0
Setting 0x181162c0 to 0x40802100
factory boot check integer ok.
factory boot load fs uboot len 131072 to addr 0x80010000.
Hit any key to stop autoboot:  0
ath> printenv
bootargs=console=ttyS0,115200 board=AP152 rootfstype=squashfs init=/etc/preinit mtdparts=spi0.0:128k(factory-uboot),128k(u-boot),1152k(uImage),14912k(rootfs),64k@0xff0000(ART) mem=128M
bootcmd=bootm 0x9f040000
bootdelay=1
baudrate=115200
ethaddr=0x00:0xaa:0xbb:0xcc:0xdd:0xee
ipaddr=192.168.0.2
serverip=192.168.0.10
dir=
lu=tftp 0x80060000 ${dir}tuboot.bin&&erase 0x9f000000 +$filesize&&cp.b $fileaddr 0x9f000000 $filesize
lf=tftp 0x80060000 ${dir}ap152${bc}-jffs2&&erase 0x9f010000 +$filesize&&cp.b $fileaddr 0x9f010000 $filesize
lk=tftp 0x80060000 ${dir}vmlinux${bc}.lzma.uImage&&erase 0x9f300000 +$filesize&&cp.b $fileaddr 0x9f300000 $filesize
stdin=serial
stdout=serial
stderr=serial
ethact=eth0

Environment size: 701/65532 bytes
ath>

To boot, I can use the default "boot" command without the full address "bootm 0x9f040000", so uboot somehow "knows" how to boot the kernel, but it dies when it tries to run uboot the second time and doesn't get to the point when the second uboot boots the kernel (see normal boot spew here ).

Is this the correct address to use, if not please correct (I have no clue on ram/flash memory map):
uboot_cli>
tftp 0x86000000 openwrt-ath79-generic-tplink_archer-a7-v5-initramfs-kernel.bin
bootm 0x86000000

Thanks for the suggestion. I just tried the above to boot a "initramfs".bin, then used kernel cli: cd /tmp, wget "sysupgrade".bin, sysupgrade "sysupgrade".bin

This had no change to boot failure, still hangs at same spot. After manually booting the freshly flashed sysupgrade kernel, the resulting flash layout still has the kernel and rootfs partions un-aligned to erase block boundaries. So, no change.

I'm in a bit of a no-mans-land at the moment since I had a pretty good idea of "how" to flash, but not "what" to flash, or which option of flashing is the better choice with the current weird flash state. If I knew which files/chunks of backups to use and what addresses for tftp/erase/cp.b from uboot cli, I'd just reflash the whole thing including uboot, but I don't know which files/config/etc or what surgery on old ddwrt partition backups I'd need to do to pull out only the device specific bits to pull into a new clean flash.

What should I do next on this journey into the guts of embedded linux? :wink:

8

haven't checked, but is mtdparts in bootargs still valid for your butchered flash layout ?

9

@frollic: I'm not familiar with what you are referring to. The dmesg/boot spew with layout info is posted above. If there's other info I need to get, I'll get it as soon as I know how. :wink:

Also, from within the running initramfs environment:

root@OpenWrt:/# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00010000 "factory-uboot"
mtd1: 00020000 00010000 "u-boot"
mtd2: 00ec0000 00010000 "firmware"
mtd3: 00223e13 00010000 "kernel"
mtd4: 00c9c1ed 00010000 "rootfs"
mtd5: 008b0000 00010000 "rootfs_data"
mtd6: 00020000 00010000 "info"
mtd7: 00050000 00010000 "config"
mtd8: 00010000 00010000 "partition-table"
mtd9: 00010000 00010000 "art"
root@OpenWrt:/#
10

Two years ago I was in a similar position after flashing a wrong image (for a C7) via the serial port.
I was only able to tftpboot initramfs image and any kind of sysupgrade using the correct image didn't solve the problem.

My solution was to boot from the initramfs image, install the kmod-mtd-rw package, and rewrite everything except factory-uboot, u-boot and art.

Unfortunately, after two days of banging my head against the wall, I was too nervous to rewrite the partitions one by one to see which one was causing the problem.

If you want to try this approach (at your own risk) I could dump for you whatever you want.

BTW I don't see anything wrong with the flash layout.

Here is the one from my device running 22.03.2

[    0.426436] Creating 7 MTD partitions on "spi0.0":
[    0.431454] 0x000000000000-0x000000020000 : "factory-uboot"
[    0.441948] 0x000000020000-0x000000040000 : "u-boot"
[    0.448000] 0x000000040000-0x000000f00000 : "firmware"
[    0.455889] 2 uimage-fw partitions found on MTD device firmware
[    0.462055] Creating 2 MTD partitions on "firmware":
[    0.467196] 0x000000000000-0x000000223e13 : "kernel"
[    0.472352] mtd: partition "kernel" doesn't end on an erase/write block -- force read-only
[    0.482528] 0x000000223e13-0x000000ec0000 : "rootfs"
[    0.487666] mtd: partition "rootfs" doesn't start on an erase/write block boundary -- force read-only
[    0.498027] mtd: device 4 (rootfs) set to be root filesystem
[    0.504795] 1 squashfs-split partitions found on MTD device rootfs
[    0.511247] 0x000000610000-0x000000ec0000 : "rootfs_data"
[    0.517732] 0x000000f40000-0x000000f60000 : "info"
[    0.525167] 0x000000f60000-0x000000fb0000 : "config"
[    0.531255] 0x000000fc0000-0x000000fd0000 : "partition-table"
[    0.539489] 0x000000ff0000-0x000001000000 : "art"

21.02.1

[    0.355373] 7 fixed-partitions partitions found on MTD device spi0.0
[    0.361946] Creating 7 MTD partitions on "spi0.0":
[    0.366921] 0x000000000000-0x000000020000 : "factory-uboot"
[    0.373562] 0x000000020000-0x000000040000 : "u-boot"
[    0.379610] 0x000000040000-0x000000f00000 : "firmware"
[    0.388338] 2 uimage-fw partitions found on MTD device firmware
[    0.394500] Creating 2 MTD partitions on "firmware":
[    0.399644] 0x000000000000-0x0000001f3f1b : "kernel"
[    0.405563] 0x0000001f3f1b-0x000000ec0000 : "rootfs"
[    0.411589] mtd: device 4 (rootfs) set to be root filesystem
[    0.419215] 1 squashfs-split partitions found on MTD device rootfs
[    0.425651] 0x000000570000-0x000000ec0000 : "rootfs_data"
[    0.432098] 0x000000f40000-0x000000f60000 : "info"
[    0.437924] 0x000000f60000-0x000000fb0000 : "config"
[    0.443948] 0x000000fc0000-0x000000fd0000 : "partition-table"
[    0.450821] 0x000000ff0000-0x000001000000 : "art"
11

@pavelgl Heh... Ok, on one hand the unaligned flash layout looks weird and throws warnings, but on the other hand, it all gets written at the same time so it doesn't matter anyway, so I guess I'll write that "issue" off as a new experience.

Yea, a dump would be much appreciated, but I don't know which partitions could affect the current bootloader behavior. I can find my way around EFI on pc well enough, even wrote some grub scripts that scan for bootable media and generate boot menus at runtime, but I'm still trying to figure out how to tie my shoes when it comes to booting embedded.

This is the second router I've bricked in a week moving off of ddwrt. The first one I debricked after a few learning curves and soldering up the serial console. This one is being a bit more troublesome.

12

So... With some hex editing, was able to unbrick without manually modifying/replacing uboot.

Somewhere along the line, possibly done by a DDWRT install, the firmware version string got set to "soft_ver:7.0" instead of the OEM version 1.0 or 1.2-ish version numbers. This was preventing the uboot recovery from flashing the OEM firmware image due to failing the versioning check firmware_file_v1.2 is < installed_v7.0.

From searching through bin dumps of the mtd partitions with a hex editor, I found something that looked like what I needed in mtd6 aka "info" partition: "soft_ver:7.0". I modified the version to "1.0", reflashed that partition, then reflashed with OEM fw, and voila, it boots normally again.

(standard warning, use at your own risk, you could brick your device more, etc)
Steps:

  • Set up tftp server and sshd on host machine, save OEM firmware to "tftp_server_root/ArcherC7v5_tp_recovery.bin", also need copy of openwrt-initramfs.bin in tftp root as well
  • Solder serial console, connect at 115200
  • reset device, break into uboot startup for uboot console
  • tftp 0x86000000 appropriate-initramfs-image.bin
  • bootm 0x86000000
  • create backups of MTD, scp to host
  • find software string in hex dumps, mod version, save hacked copy
  • scp hacked copy back to device
  • opkg install kmod-mtd-rw
  • insmod mtd-rw i_want_a_brick=1
  • overwrite mtd partition with hacked version
  • Reflash OEM fw with normal recovery method: press and hold reset button, power cycle to reboot, keep holding reset button until serial console shows "ArcherC7v5_tp_recovery.bin" is downloading. Hopefully, flashing will succeed. NOTE: the biggest reason this method of flashing fails is that it takes too long for the host ethernet port to get reconnected when the router is power cycled, and the recovery times out attempting to connect to tftp server. SO: while the router is powered on and host ethernet connection is active, while continuously holding router reset button, power off just long enough to cause a device reset, but too short a time for the host ethernet adapter to go down. This works MUCH more consistently than otherwise.
  • verify device working properly with oem firmware
  • reflash with openwrt factory bin as normal...

The OEM firmware reflashed uboot and fixed the bootup problem I was having, whatever it was.

Thanks for the help!

13

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