CPE610 v1: sysupgrade.bin missing / too big

For Developers
5

is actually quite revealing (from tools/firmware-utils/src/tplink-safeloader.c).

	{
		.id     = "CPE610V1",
		.vendor = "CPE610(TP-LINK|UN|N300-5|00000000):1.0\r\n",
[...]
		.partitions = {
			{"fs-uboot", 0x00000, 0x20000},
			{"partition-table", 0x20000, 0x02000},
			{"default-mac", 0x30000, 0x00020},
			{"product-info", 0x31100, 0x00100},
			{"signature", 0x32000, 0x00400},
			{"os-image", 0x40000, 0x1c0000},
			{"file-system", 0x200000, 0x5b0000},
			{"soft-version", 0x7b0000, 0x00100},
			{"support-list", 0x7b1000, 0x00400},
			{"user-config", 0x7c0000, 0x10000},
			{"default-config", 0x7d0000, 0x10000},
			{"log", 0x7e0000, 0x10000},
			{"radio", 0x7f0000, 0x10000},
			{NULL, 0, 0}
		},
[...]
	},

os-image := kernel
file-system := rootfs

0x1c0000 = 1'835'008 bytes

Taking a current snapshot as example (https://downloads.openwrt.org/snapshots/targets/ath79/generic/openwrt-ath79-generic-tplink_tl-wr1043nd-v1-squashfs-factory.bin):

$ binwalk openwrt-ath79-generic-tplink_tl-wr1043nd-v1-squashfs-factory.bin

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
512           0x200           gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null date)
8256          0x2040          LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: 6045946 bytes
1894768       0x1CE970        Squashfs filesystem, little endian, version 4.0, compression:xz, size: 2117646 bytes, 822 inodes, blocksize: 262144 bytes, created: 2019-06-27 15:15:37

0x1CE970 - 0x2040 = 0x1CC930
0x1CC930 = 1'886'512 bytes

In other words, the kernel is too big for the limited size of the kernel partition, probably since ath79 got switched from kernel 4.14 to 4.19. If this can be rectified by extending os-image at the expense of file-system, or by merging both into a single firmware partition and using mtdsplit from there on (more flexible) needs to be checked by someone who has that device on their desk[0]. The partitions are in the correct order (kernel --> rootfs) for that to work, but it still depends on if the bootloader is flexible enough to read the kernel beyond its original partitioning limit and if the bootloader tftp and OEM factory upgrade (OEM webinterface) implementations can cope with a modified partitioning.

--
[0] mature recovery mechanism required, ideally serial console, but at least something like push-button tftp. full backup of all partitions strongly required (radio/ ART in particular), means to reflash the spi-nor chip externally would be advisable.

1 Like