TD-W9980 (/ W8980 / W8970) partitions mod ( and "fix" ?)

Click on each section/summary to see the full content. Done this way since I wrote quite a bit.

What and Why

I recently bought a TD-W9980 (hw rev 1.0) since my TD-W8970 (hw rev 1.2) is apperenlty functinally dead (boot properly but crashes within 5 hours, even with restored original FW, with a complete flash dump). I started toying around with partitions while I was trying to properly configure uboot-envtools. I noticed some "questionable" IMO partitions scheme choices and I am asking here to know if my proposed idea can improve the current situation.

Main HW diffs between W9980, W8980 and W8970

In this thread I'll talk about the TD-W9980 partitions schema, but its valid also for TD-W8980 (same hw with an older case) and TD-W8970 (same hw except for case and 2.4 GHz only wireless chip). The similarity between 9980/8980/8970 can also be seen in the source code, the entry for 9980 does not exist (if you want to compile an image or use one already existing, simply treat it like a 8980) and both 8980's .dts file and 8970's .dts file actually import almost everything from the same .dtsi file (TDW8X90.dtsi).

All different board have an 8MB SPI Flash chip (may not be the same exact chip).

OpenWRT Partition schema

In the shared *.dtsi file (what is used to build the official OpenWRT image for thses routers) the parititon scheme can be found in the &spi section line 238, describing this:

                FROM         TO       SIZE
uboot       0x000000   0x020000   0x020000
firmware    0x020000   0x7C0000   0x7A0000   // where to flash openwrt image
config      0x7C0000   0x7D0000   0x010000   // original fw xml configs
boardconfig 0x7D0000   0x800000   0x030000   // big partition to store the unknown?

boardconfig in the dtsi file is also labelled as ath9k_cal, used at line 112 to tell where the mac addres of the 2.4 GHz wifi chip is (that partition starting offset 0x7D0000 + 0x00F100 = 0x7DF100).

Original FW Parition Schema (what is written in the wiki)

The original firmware partition scheme reported on the owrt wiki is:

              FROM         TO       SIZE
uboot     0x000000   0x020000   0x020000
kernel    0x020000   0x160000   0x140000
rootfs    0x160000   0x7C0000   0x660000
config    0x7C0000   0x7D0000   0x010000
romfile   0x7D0000   0x7E0000   0x010000 
rom       0x7E0000   0x7F0000   0x010000
radio     0x7F0000   0x800000   0x010000

Uboot+Lantiq Patches Partition Schema

I was looking to get uboot-envtools working on this router(s), to properly configure it you need to find out the value of some variables (read the uboot-envtools wiki page) and you may need to use the original souce code providded from the router manufacturer (or other external sources, basically not OpenWRT git). I ended up reading the uboot + lantiq patches git, expecially this file (vr9_cfg.h) which describe this partition schema for tons of cases (read the 8 MB SPI Flash chip section specifically, elif block starting at line 598):

                FROM         TO       SIZE
uboot       0x000000   // size unspecified, assumed 0x020000 - until "rootfs"
rootfs      0x020000   // size unspecified
kernel      0x7DFFFF   0x7E0000   0x000001   // what ? maybe is just a "dummy"?
sysconfig   0x7E0000   0x7F0000   0x010000
ubootconfig 0x7F0000   0x7F1000   0x001000   // I was looking for these values
fwdiag      0x7F1000   0x7F2000   0x001000
calibration 0x7F2000   0x7F3000   0x001000
??????      0x7F3000   0x800000   0x‭00D000‬   // space left unpartitioned

Original FW Partition Schema derived from full chip dump

With an external programmer I dumped the content of my router flash chip and tryed to understand how data was "displaced" (looking where large "FF" data section ended), and ended up with this:

                FROM         TO       SIZE
uboot       0x000000   0x020000   0x020000
kernel      0x020000   0x160000   0x140000
rootfs      0x160000   0x7C0000   0x660000
config      0x7C0000   0x7D0000   0x010000 // assumed it ended at 0x7D0000
????        0x7D0000   0x7DF100   0x00F100 // just empty space FF
wifi mac    0x7DF100   0x7DF200   0x000100 // wifi mac address followed by FF
????        0x7DF200   0x7E0000   0x000‭E00‬ // 8 bytes of something followed by FF
????        0x7E0000   0x7F0000   0x010000 // 32 bytes of something and FF utill end
ubootcfg??? 0x7F0000   0x7F1100   0x001100 // 6 bytes of something followed by FF 
????        0x7F1100   0x800000   0x00EF00 // 615 bytes of something and FF utill end

Which is a mix of all the 3 partitions schemas explained before.

Proposed Partition Schema + what you think?

So my proposed new partitioning schema is:

                   FROM         TO       SIZE
uboot          0x000000   0x020000   0x020000 // unchanged (read only)
firmware       0x020000   0x7D0000   0x7B0000 // just larger -> removed 'config'
boardconfig_1  0x7D0000   0x7F0000   0x020000 // (read only)
ubootconfig    0x7F0000   0x7F1000   0x001000 // (read and write)
boardconfig_2  0x7F1000   0x800000   0x00F000 // (read only)
  • firmware is 64KiB larger. The config partition holds the original FW settings, which is quite useless with an OpenWRT fw. It may be argued that 64 KiB is not so much and that is nice to be able to revert to the original fw withouth loosing the original config, buuuut, is always nice to have a bit more space with just 8 MiB of flash chip and before switching to OpenWRT everyone should have already backed up their configuration.
  • ubootconfig accessable read/write without loosing write protection on other sensible region that will remain read only.
  • boardconfig_1 (was simply boardconfig) will not change it's starting offset so it can be still labelled as ath9k_cal (the wifi mac adress lookup trick).
  • boardconfig_1 and boardconfig_2 are placeholder names, if you have better ideas write them here pls xD I do not know how to name them properly.

Of course this works assuming ubootconfig is actually placed at those adresses (I'll check later, but I can change them if needed), btw regardless that larger firmware partition can still be implemented (by removing the config partition, and 0xFF-ing it maybe?). What do you think?

Modified dtsi file (WIP) Did I wrote this right?

Grab the original dtsi file and change the &spi section. Alwais assuming thath the ubootconfig partitions is really there. Is the format correct? Those two "4" (highlighted by the "#############" lines) are the partition counter and should be changed to "5"?

&spi {
	status = "okay";

	pinctrl-names = "default";
	pinctrl-0 = <&pins_spi_default>;

	m25p80@4 { ###############################
		#address-cells = <1>;
		#size-cells = <1>;
		compatible = "jedec,spi-nor";
		reg = <4 0>; ############################
		spi-max-frequency = <33250000>;

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

			partition@0 {
				reg = <0x0 0x20000>;
				label = "u-boot";

			partition@20000 {
				reg = <0x20000 0x7b0000>;
				label = "firmware";

			ath9k_cal: partition@7d0000 {
				reg = <0x7d0000 0x20000>;
				label = "boardconfig_1";

			partition@0x7f0000 {
				reg = <0x7f0000 0x1000>;
				label = "ubootconfig";

			partition@0x7f1000 {
				reg = <0x7f1000 0xf000>;
				label = "boardconfig_2";


Ty for your help :slight_smile: sorry for the long post but I like to torture my router and learn new stuffs xD

As I understand you want to possibly repair your W8970 so it can be made usable for stable use. Correct me if I am wrong.

I never stated that xD I wanted to know if the process to create a modified partition layout made sense. Have I made errors writing the dtsi file? I wrote about the other routers just because the same process can be applied also to them

Small edit to clarify further: in "... if my proposed idea can improve the current situation ..." with "the current situation" I was still talking about partitions schema. I was asking if my new partition schema made sense as improvement on the current one.

I can not answer that. I consider myself a newbie and I dont know how changing the existing partitions can help improve the performance somehow. Maybe someone else with more experience can better answer it.

I didn't touch SPI chip. I'm booting the system over NFS :-D, it is too big and too volatile to fit SPI flash. But the partition could be probably increased, altough few kB is pretty low amount. I would probably just used a bigger SPI flash :smiley:

1 Like