Trouble installing OpenWrt on TP-Link EAP225 Outdoor v1

I've been following the installation instructions and not having any luck. The device came with v5.0.5 installed. The web interface gets to about 5% on the progress bar and then the progress bar disappears and it says "upgrading" and to wait, but nothing is happening. I've tried flashing vendor v5.0.3, v5.0.5, my own custom build and the release openwrt version (https://downloads.openwrt.org/releases/21.02.6/targets/ath79/generic/openwrt-21.02.6-ath79-generic-tplink_eap225-outdoor-v1-squashfs-factory.bin). I have also tried tftp booting from the serial console. I tftp the initramfs to 0x80060000 and bootm it, but get:

ath> bootm
## Booting image at 80060000 ...
Bad Magic Number

I had a successful experience last September (2022) with both a v1 and v3 EAP225 Outdoor. Inspecting the u-boot partition, I noticed that this more recent device has a newer u-boot date (although the same version string):

U-Boot 1.1.4--LSDK-10.2-00082-4 (Jul 3 2018 - 16:11:24)
vs.
U-Boot 1.1.4--LSDK-10.2-00082-4 (May 20 2021 - 16:43:27)

The hashes differ:

86da6958646c631105d186d79fc285708c366aefb61c999f040779f3db0e5b62  2018-uboot.bin
b32ad2d9ea08719571922f23041ba55bb44cb3f12f45e5f50884cb47db145e36  2021-uboot.bin

and I've just glanced at a diff of the hexdumps.

Has anyone else run into this newer u-boot? I haven't inspected the board closely to find the flash part, but if it is accessible, I'd consider trying to flash the u-boot partition back to the older 2018 version.

Fwiw, I got brave and erased the 2021 u-boot and wrote the 2018 one, and I get the same "Bad Magic Number" message.

I took a firmware partition (mtdblock3: kernel+squashfs+jffs2) from a working eap225 outdoor v1 and from u-boot, tftp'd mtdblock3.bin, erased/cp.b'd it to 0x9f040000, and that boots (bootelf!).

openwrt-ath79-generic-tplink_eap225-outdoor-v1-initramfs-kernel.bin is not booting from u-boot with bootm or bootelf:

Filename 'openwrt-ath79-generic-tplink_eap225-outdoor-v1-initramfs-kernel.bin'.
Load address: 0x80060000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ##########################
done
Bytes transferred = 6786704 (678e90 hex)
ath> bootelf
Loading .text @ 0x80060000 (6782194 bytes)

That seems problematic.

@svanheule ^^^^

Fwiw, I got another device which purported to be "the same", same hardware version 1.0 and vendor firmware v5.0.5, and this one flashed Just Fine, according to the wiki page instructions. No idea why. Seems to be a device-specific quirk, based on available data.

Do you have flash dumps of both devices you could compare? Obviously some parts of flash will be device-specific anyway, but it might be good to check if there are any differences to find out what was causing this.

Yes, I do have flash dumps. There are difference in mtdblock2 and mtdblock4. In mtdblock4 (rootfs), the differences appear between 0x00c00000 and 0x00c00900 between all three of the devices, the initial problematic one and the other two that flashed fine. However, binwalk -eM'ing the mtdblock4's and recursive diff'ing the expanded squashfs's find no differences, e.g.:
diff -ruN eap225-01/_mtdblock4.bin.extracted/ eap225-02/_mtdblock4.bin.extracted/

The problems with the first device seems like a fluke. At this point, I'm more worried about the initramfs image not booting.

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