Adding OpenWrt support for TP-Link EAP245

The reverse rootfs/uimage order must be put in there for some reason. I'd imagine to stay close to some original device firmware layout. It has been there for a long time. However, after a quick look, I can't immediately find the need to support that with the commits surrounding the introduction of that code.

The issue with non-aligned partitions could also arise later in the process, when splitting off the rootfs_data partition. The code rounds the end of the squashfs up to the next erase block. Using a firmware partition at 0x0c3000, rootfs_data was placed at firmware+0x5f0000. As a result, the DEADC0DE marker was 0xd000 bytes into the jffs2 partition, resulting in the initialisation failing.

Filed as a pull request. If you would like to test, I can provide images (but you'll have to do the soldering yourself).

Is there any hope for a v1 version?

I'm trying to find a way in order to get these images signed, using the vendor's GPL toolchain.
Can someone of you upload some image file, in order to give it a try?
It might also be possible, to build a default image file using their sources, and remove the checking for new image files. (I did so for my Winbond BMC, and they are using the same building tool and structure.)

If you need a v1 build, you could try with j-d-r's 18.06 image. I don't think you'll be able to create a signed image with TP-Link's toolchain however. They don't include their private key in the GPL sources. At least they shouldn't. So unless you found their private key somewhere, I wouldn't spend too much time on this path.

What you could alternatively try, is patching the library or elf file so that it has your own key. Then you could:

  • get a root shell
  • mount an overlayfs to replace the patched target file
  • restart the necessary processes
  • upload your OpenWrt image, signed with your key, via the web interface.

I've updated 19.07 branch to make ELF image for ar71xx that can be run with original u-boot (release here). I've modified kernel partition size to 0x700 instead of 0x600.

@Knogle I put factory.bin image if you want to make some test but without private key you will need at least a root access.

1 Like

Good news everyone! I have found a way to flash images via the TP-Link web interface. :star_struck:
I only found the EAP245v3 firmware to contain the required code. The EAP245v1 and the EAP225v3 appear to use a different version of the software.

If you want to test, I've uploaded images for the EAP245v3.

This image format is similar to TRX v1. The TP-Link log messages appear to indicate this is an OpenWrt image format, but that must've been really long ago.

2 Likes

Awesome!

What about the EAP225-Outdoor? It seems rather close to the EAP245v1, isn't it?

https://deviwiki.com/wiki/TP-LINK_EAP225-Outdoor
https://deviwiki.com/wiki/TP-LINK_EAP245_v1.x

Note: I got mine from Amazon.de in April 2020, it has hardware v1.0 revision and came with firmware version 1.5.0 Build 20190404 Rel. 58086(4555). I voluntarily did not upgrade it to the newer versions listed on https://www.tp-link.com/support/download/eap225-outdoor/#Firmware hoping it would help flashing it to openwrt in the future.

Edit: oh, I misread the second sentence start, I thought it said EAP245v1, not EAP245v3 :man_facepalming:

The EAP225-outdoor has the exact same chips as the EAP225v3. The EAP225v3 is different from the EAP245v1 only in that it has a different 5GHz radio. The 225v3, 245v1 (and most likely 225v1 and 225v2) are based on the ap152 reference board. The GPL sources for these two devices contains code that should have been in the bootloader, so bringing up ethernet is a pain. That's one of the reasons j-d-r's port didn't get accepted.

I had a quick look at the v1.5 FW (which is also the only version listed) for the EAP225-OD, but it appears to be a similar uclited daemon as as the EAP245v3; i.e. no known exploit to get a root shell.

1 Like

What confused me is that there's no EAP245v3 listed at WikiDevi: https://deviwiki.com/w/index.php?search=EAP245&title=Special%3ASearch&go=Go

I see other versions for my EAP225-OD:

Yeah, nobody (including me) made an entry for the v3. Note that the 5G chip (QCA9982) listed on that page is the one from the v3, not the v1 (QCA9880).

You are right. Apparently different languages get different support levels :man_facepalming:

  • English: up to v1.7
  • Dutch: up to v1.6.1
  • French: up to v1.5

So I can try enabling serial console and then flash it via tftp like you wrote in this PR?

Yes, that would be the general procedure. But you would need a firmware build that is designed for this board and my EAP245v3 builds are not compatible.

You may have more luck trying j-d-r's EAP245v1 build, but verify that the firmware layouts match first! 5GHz would most likely not work, as the QCA9886 is a QCA99x0-compatible device, while the QCA9880 is QCA988x-compatible (different ath10k firmware packages)

How can I verify that? Are there somewhere instructions how the serial ports have to be connected?

If you can ssh into the device from the stock firmware, you could check /proc/mtd for the flash layout and /proc/cmdline for the boot arguments (the flash layouts in both should more or less match).

Not that I know, and the FCC pictures aren't clear enough. Open up the device and check for unpopulated headers. You should have something with four connections: VCC, GND, RX, TX. Feel free to post board pictures in this thread (or maybe a new one).

@j-d-r If I understand correctly, you had to add three things to initialise the ethernet on the EAP245v1:

  • SGMII SERDES VCO resistor calibration
  • SGMII SERDES reset sequence
  • SGMII reset sequence

The last bit appears to be already present in OpenWrt, and available from the DT via a qca955x-sgmii-fixup directive.

I've tried porting your ar71xx code to ath79. What I got working, was the resistor value scan (which also never detected any value changes on my device, ending up at a value of 7). But I think either the SERDES reset didn't work or the SGMII reset wasn't called, because the SGMII link didn't want to come up. Do you think it would be a lot of work to port it over? The EAP225(v3) and EAP225-ODv1 use the same (crappy) mach-ap152.c source, so they could also benefit from this if they want these kind of patches in OpenWrt or upstream.

That's a good news, this commit introduce reset, and support for some broken u-boot on qca955x.

  • First step is only a scan to find a value, used in serdes setup. The resistor value scan doesn't work on my board too. I keep it as it comes from QCA u-boot. I think you can skip, this step and use value 7 (or a dts value). With TP-Link kernel:

[ 0.080000] MIPS: machine is Qualcomm Atheros AP152 reference board
[ 0.600000] Max resets limit reached exiting...

  • Second step is setup and reset, but a lot of #define are used, you might need ar71xx.h patch from this refused PR.

  • Third step looks very close to qca955x. In QCA u-boot 956x and 955x are identical.

It shouldn't be difficult to do, most boring work is translating #defines and way to set/clear bit in register from one version to another.

But if this patch is rejected, you may have work to keep it up-to-date.

I have an TP EA-225-Outdoor(EU) Ver 1.1.
I can not find the serial port. Any idea where it is?

I've done a quick and dirty patch that seems to work.

edit: HERE
edit2: I badly tested it. It doesn't work, if the board is not power down, it keep working if i've done tftpboot
edit3: This time it seems to work fine:

  • serdes initialization must be done at start of probe
  • rgmii-ge0, ge0-sgmii, rxdv-delay and/or rxd-delay need to be set instead I get "eth0: tx timeout" from refused PR
1 Like

No idea, look for R225 and R237.

1 Like