Sysupgrade question for new device (TL-WPA8630P V2)

I am in the same boat as @infl00p, I cannot direct message either. I actually signed up just now to reply to this thread. I have a TL-WPA8630P and no openwrt experience. Though I am hoping to change that by helping anyway I can. This corona virus isolation is putting new demands on my home network.

Edit: I found this:

Get to trust level 1 by…

* Entering at least 5 topics
* Reading at least 30 posts
* Spend a total of 10 minutes reading posts

Users at trust level 1 can…
* Send PMs

Same here and, fortunately, a bit more time (due to the same virus...)

Managed to sent a backup to @andyboeh !
Apparently the recovery was successful :smiley:


OK, with the help of @infl00p I was able to revive my WPA8630P V2 and I'm now running my ath79-based OpenWrt build. I still cannot flash from the stock firmware, though: Even if I flash a stock firmware image, it overwrites factory-uboot with zeros. Thus, I cannot test whether my OpenWrt build flashes from stock (the firmware definitely accepts it).

If you want to try my build or my code, please be prepared that it might bring your device to a state where you need to flash the IC directly. I did not have an SOIC-8 clip, so I soldered 8 small wires to the IC and hooked them up to a Raspberry PI. With a bit of dd- and flashrom-foo it can be restored.

1 Like

I am a bit confused by the difference between TL-WPA8630v2 and TL-WPA8630P and TL-WPA8630Pv2.

Stock I have:
Hardware version: TL-WPA8630P v1 00000000
Firmware version: 1.0.1 Build 170405 Rel.64864n

Am I out of luck for the build you've been working on?

Yes and No: Yours seems to be a v1 which is already officially supported. I've git one, too, and used @netadair's build for an initial flash and did a sysupgrade afterwards. If you check [Solved] TL-WPA8630P Lede does not install they're discussing the v1 and the initial installation problems (as well as P vs. non-P)

I have worked through the thread @andyboeh linked. I unfortunately could not get past the wrong file error despite downgrading stock, using @netadair's fixed versions (17.01.4 and 18.06.1) and changing the file name.

Is it possible the electrical plug/region type matters? I know TP-Link have different stock version of the firmware based on region. I am using the US version and the screenshots and links I've seen suggest you guys might be using the EU version? The hardware ID (0x86310001) seemed to be more complicated than just model and version.

I ask in this thread for continuity as well as possible relevance. It would be a consideration for V2 images as well right?

@andyboeh Is it possible that part of your issue from overwriting u-boot when reverting to stock comes from the fact that

		.first_sysupgrade_partition = "os-image",
		.last_sysupgrade_partition = "file-system"

in the relevant commit to tplink-safeloader.c are not in the list of existing partitions (see a few lines above in the .partitions member)?

Thanks for the response, but unfortunately that's not the case: If you look at the definitions for the other devices, it's the same thing.
Plus, even flashing an OEM image overwrites my boot loader, so I'm sure something else was/is broken. I don't really care since it works for me this way.

Full disclosure: I'm still learning when it comes to building openwrt, though I've got a working build system that's producing working images for my pi and netgear router. But I'm a total newbie when it comes to porting openwrt...

Does it matter that the partition tables in the US and EU firmware for the WPA8630Pv2 are different?

Specifically that the default-mac, pin, device-id, product-info partitions are at 7e0000 upwards in the US and AU firmware, and 630000 upwards in the EU (and UK) firmware? (I haven't looked at the others.)

I've got a pair of (UK) WPA8630Pv2 devices running the build from, and am very interested in getting something better running - I'm finding wifi intermittently unstable on that build.


I just bought my second WPA8630Pv2 and was wondering how many people are successfully running OpenWRT on it? Also 2.4Ghz network seems to struggle for some reason even though I sit right next to it, 5Ghz runs really well. Could this improve with OpenWRT firmware?

Yes and no: The partition table stuff is only evaluated when flashing from stock. OpenWrt uses the MTD definitions in the .dts.
However, you don't want OpenWrt to overwrite important stuff from the stock firmware, so the definitions in the .dts file are usually created in a way that only the os-image and file-system partitions are used.

My EU v2 has the partition table at 0x620000, not at 0x630000. I can't even find a US version of the v2 firmware, where did you download it? The AU version also has the partition table at 0x620000, maybe you mixed up the P and non-P version as I did previously?

Yes, you're right, I was trying to find a US P v2, but there isn't one and I picked the not-P version by mistake. And yes, in all the versions of firmware I could find (for Pv2 models) the partition table starts at 0x620000.

I'm learning here - would appreciate feedback if I'm getting it, or not!

I can see the partitions in the .dts file - and these make sense. There's a single firmware partition at 0x40000 which spans both the os-image and file-system partitions defined in the stock firmware. All the others are marked read-only, and presumably the absence of a partition in, say, the 0x670000 to 0x7f0000 region doesn't matter, and openwrt won't overwrite it? (There are some more partitions defined here in the stock firmware).

I can also see the partitions in the safeloader, but these don't match the stock firmware - though again I guess this doesn't matter as you're only overwriting the firmware partition.

But what I didn't get for a while is that if the first and last sysupgrade partitions are os-image and file-system, how does the safeloader make sense of this when they're not defined in the list of partitions just above? But if I've understood the code correctly it splits the firmware partition into os-image and file-system partitions as it builds the image, thus allowing more flexibility as to where the boundary is between these. (and that seems to need to align to a flash block boundary in factory images, but not for sysupgrade, which also seems to make some sense).

I think I'm getting there...

I'm not an expert in this either, since I also mostly copied and interpreted other people's work.

Generally, I have about the same understanding as you. The partitions in safeloader should match with the sole exception being os-image and file-system replace by firmware.

Were you able to test my branch, especially flashing from stock? I'd love to create a PR, but I don't want to do this without a test by someone else...
EDIT: I created a PR in the meantime ( and we found out that I was mixing DE and EU versions. That might be the reason why my device cannot flash from stock. I would still be interested if someone could test whether flash from stock works as expected - as mentioned, do a full backup first and be prepared to restoring your device via an SPI flasher.

Sorry, work got busy again. I tried flashing one of my 8630Pv2s from stock with a patched version of 19.07.2 a couple of weeks ago, and bricked it :-(. Haven't had time to do anything about that yet (it's still sitting on the workbench waiting for me to wire up the serial port).

I have this and installed the 18.06 version. Can someone please explain how to open the device to access the flash chip?

I did take dump from openwrt using dd but since has a massive role at my please for the kids internet I need to be able to flash it back quickly to a working device.

I hvae not been able to open the stupid thing. I did remove the 4 screws and tried with a bit hard to open it but it didn't do the trick.

If I remember correctly, I just unscrewed the four screws and could pry it open using a guitar pick (there are some snaps that still hold it together).

Usually, I take dd dumps from all mtd partitions before playing around, but this time, I forgot. Luckily, another user sent me his dumps which I could use to revive mine (bootloader overwritten). I used a Raspberry Pi to flash the IC directly (I soldered wires, but a Pomona clip helps as well).

If your bootloader is not destroyed, you can always flash via Serial and TFTP (not the dumps, but a working firmware image. The stock firmware needs to be prepared to be accepted!).

Thanks I will give it a go again. I felt at some stage that I was about to break it as I was using a flat head screwdriver.

That will probably leave can check the FCC Internal Photos on how the case is built: