I've linked my releases (a few posted up) to the correct branch, and they all have IMAGE_SIZE set, so yes.
Once you have serial access, you can try and see which one works 
(It's the sysupgrade image)
Interesting. It wouldn’t produce sysupgrade image on the current state of the repository - tplink_eap2x5 branch - for some reason. I’ll take a look.
Update: Looks like it was a local problem from my side. Everything is fine now.
My contact just did this since I don’t really know or understand what do you mean by unpopulated limiting resistors so I can’t really direct him to do it.
This is the current state of the soldering:
I assume I also need a USB adapter to connect to a PC.
@arinc9 Do you know you can upload images onto the forum directly? If your image host goes down, the images are gone too. Not when you just upload the pictures to the forum.
1 Like
Looks okay to me. I also think that the necessary resistors are already present. But you'll need to hook up a serial port adapter to find out.
Something like this, for example: https://www.sparkfun.com/products/12731
These are high quality images which exceed size limit put by the forum (4MB).
TXD light dies after powering up the AP, I don’t see anything on serial console either.
Edit: Switching TXD to RXD on the adapter worked for some reason.
Edit: I’m not sure how I can run commands on it though.
@svanheule I couldn't figure out how to run commands but after multiple try of booting the AP, I was able to access it.
U-Boot 1.1.4--LSDK-10.2-00082-4 (Jul 3 2018 - 16:11:24)
board956x - Dragonfly 1.0DRAM:
sri
ath_ddr_initial_config(287): (ddr2 init)
ath_ddr_initial_config: DDR_EMR2_ADDRESS=0x180000bc, EMR2 value=0x80
ath_sys_frequency: ref_clk 25000000
ath_sys_frequency: cpu 775 ddr 650 ahb 258
Tap values = (0x10, 0x10, 0x10, 0x10)
128 MB
Top of RAM usable for U-Boot at: 88000000
Reserving 165k for U-Boot at: 87fd4000
Reserving 192k for malloc() at: 87fa4000
Reserving 44 Bytes for Board Info at: 87fa3fd4
Reserving 36 Bytes for Global Data at: 87fa3fb0
Reserving 128k for boot params() at: 87f83fb0
Stack Pointer at: 87f83f98
Now running in RAM - U-Boot at: 87fd4000
Flash Manuf Id 0xc8, DeviceId0 0x40, DeviceId1 0x18
flash size 16MB, sector count = 256
Flash: 16 MB
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
Setting 0x181162c0 to 0x30602100
Hit Ctrl+B to stop autoboot: 0
## No elf image at address 0x9f040000
Net: ath_gmac_enet_initialize...
No valid address in Flash. Using fixed address
ath_gmac_enet_initialize: reset mask:c02200
athr_mgmt_init ::done
Dragonfly ----> S17 PHY *
AR8033 PHY reg init
ath_reg_rd(0x1804006c)=82
Max resets limit reached exiting...
athr_gmac_sgmii_setup SGMII done
: cfg1 0x80000000 cfg2 0x7114
eth0: 00:03:7f:09:0b:ad
ath_reg_rd(0x1804006c)=82
eth0 up
eth0
ath>
It'd stop here on a casual boot:
U-Boot 1.1.4--LSDK-10.2-00082-4 (Jul 3 2018 - 16:11:24)
board956x - Dragonfly 1.0DRAM:
sri
ath_ddr_initial_config(287): (ddr2 init)
ath_ddr_initial_config: DDR_EMR2_ADDRESS=0x180000bc, EMR2 value=0x80
ath_sys_frequency: ref_clk 25000000
ath_sys_frequency: cpu 775 ddr 650 ahb 258
Tap values = (0x10, 0x10, 0x10, 0x10)
128 MB
Top of RAM usable for U-Boot at: 88000000
Reserving 165k for U-Boot at: 87fd4000
Reserving 192k for malloc() at: 87fa4000
Reserving 44 Bytes for Board Info at: 87fa3fd4
Reserving 36 Bytes for Global Data at: 87fa3fb0
Reserving 128k for boot params() at: 87f83fb0
Stack Pointer at: 87f83f98
Sending binary over tftp was fine but I get this weird error on erase and cp:
ath> erase 0x9f040000 +$filesize
Bad address format
ath> cp.b $fileaddr 0x9f040000 $filesize
Usage:
cp - memory copy
Stupid question maybe, but is $filesize defined? If it's an empty variable it's normal the command errors out.
Any ideas how and what should I define it?
I'd guess it would be part of uboot environment variables that get set at boot time, but I'm out of my league here.
Hopefully @svanheule knows more.
Hi, your local u-boot expert here! (cough, cough)
$filesize is a variable that should be defined after you complete a tftp transfer. Same goes for $fileaddr. If they aren't you have to replace $fileaddr by the location you transferred the sysupgrade image to. $filesize should be size of the transferred image in bytes. If you have to enter it manually, probably safest to enter it as a hex number.
You could also define them manually with setenv. If you get any error messages after entering a command, you'll probably get an answer via [search engine] sooner than if you have to wait for me to reply 
1 Like
Yeah, I figured. I've finally made it! After the hacky way of accessing the command line, I have run these commands. Turns out I could indeed see the size of the binary in hex on tftpboot, (probably wasted 30 minutes looking at Stack Overflow to find it before realizing that ;P).
ath> setenv ipaddr 192.168.1.1
ath> setenv serverip 192.168.1.2
ath> tftpboot 0x81000000 openwrt-ath79-generic-tplink_eap225-outdoor-v1-squashfs-sysupgrade.bin
Trying eth0
Checking Link: Up
Checking Duplex: Full
athrs_ar8033_phy_speed 172 speed=2 phy_hw_status=bc5c
dup 1 speed 1000
Using eth0 device
TFTP from server 192.168.1.2; our IP address is 192.168.1.1
Filename 'openwrt-ath79-generic-tplink_eap225-outdoor-v1-squashfs-sysupgrade.bin'.
Load address: 0x81000000
Loading: T #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
##########
done
Bytes transferred = 5374747 (52031b hex)
ath> erase 0x9f040000 +0x52031b
Erasing flash...
First 0x4 last 0x56 sector size 0x10000 86
Erased 83 sectors
ath> cp.b 0x81000000 0x9f040000 0x52031b
Copy to Flash... write addr: 9f040000
done
ath> reset
After resetting, OpenWRT boots just fine. I have tried flashing -factory image first, which would boot back to the command line.
Fantastic job and thanks for the huge help @svanheule!
1 Like
@svanheule one little update prior to OpenWRT on EAP225 as an architecture.
There's only openwrt_core and openwrt_base on /etc/opkg/distfeeds.conf hugely limiting packages to install.
I have added the missing repositories prior to the architecture. In the end, the file should look like this:
src/gz openwrt_core http://downloads.openwrt.org/snapshots/targets/ath79/generic/packages
src/gz openwrt_kmods http://downloads.openwrt.org/snapshots/targets/ath79/generic/kmods/5.4.52-1-7088f695112953c6065247e81d1535bb/
src/gz openwrt_base http://downloads.openwrt.org/snapshots/packages/mips_24kc/base
src/gz openwrt_luci http://downloads.openwrt.org/snapshots/packages/mips_24kc/luci
src/gz openwrt_packages http://downloads.openwrt.org/snapshots/packages/mips_24kc/packages
src/gz openwrt_routing http://downloads.openwrt.org/snapshots/packages/mips_24kc/routing
src/gz openwrt_telephony http://downloads.openwrt.org/snapshots/packages/mips_24kc/telephony
I was wondering if this can be updated from the source code.
./scripts/feeds update -a
./scripts/feeds install -a
These made LuCI appear (at least) on menuconfig but there still are only these 2 repositories on opkg on an image produced with these commands ran.
Well I'm not going anywhere yet sigh. After desoldering and putting the case back, I had the shock of the day, it won't boot.
I have soldered back and realized that most of the time on cold-boot, the bootloader becomes stuck here:
U-Boot 1.1.4--LSDK-10.2-00082-4 (Jul 3 2018 - 16:11:24)
board956x - Dragonfly 1.0DRAM:
sri
ath_ddr_initial_config(287): (ddr2 init)
ath_ddr_initial_config: DDR_EMR2_ADDRESS=0x180000bc, EMR2 value=0x80
ath_sys_frequency: ref_clk 25000000
ath_sys_frequency: cpu 775 ddr 650 ahb 258
Tap values = (0x10, 0x10, 0x10, 0x10)
128 MB
Top of RAM usable for U-Boot at: 88000000
Reserving 165k for U-Boot at: 87fd4000
Reserving 192k for malloc() at: 87fa4000
Reserving 44 Bytes for Board Info at: 87fa3fd4
Reserving 36 Bytes for Global Data at: 87fa3fb0
Reserving 128k for boot params() at: 87f83fb0
Stack Pointer at: 87f83f98
Sometimes, it passes that stage to boot OpenWRT:
U-Boot 1.1.4--LSDK-10.2-00082-4 (Jul 3 2018 - 16:11:24)
board956x - Dragonfly 1.0DRAM:
sri
ath_ddr_initial_config(287): (ddr2 init)
ath_ddr_initial_config: DDR_EMR2_ADDRESS=0x180000bc, EMR2 value=0x80
ath_sys_frequency: ref_clk 25000000
ath_sys_frequency: cpu 775 ddr 650 ahb 258
Tap values = (0x10, 0x10, 0x10, 0x10)
128 MB
Top of RAM usable for U-Boot at: 88000000
Reserving 165k for U-Boot at: 87fd4000
Reserving 192k for malloc() at: 87fa4000
Reserving 44 Bytes for Board Info at: 87fa3fd4
Reserving 36 Bytes for Global Data at: 87fa3fb0
Reserving 128k for boot params() at: 87f83fb0
Stack Pointer at: 87f83f98
Now running in RAM - U-Boot at: 87fd4000
Flash Manuf Id 0xc8, DeviceId0 0x40, DeviceId1 0x18
flash size 16MB, sector count = 256
Flash: 16 MB
*** Warning - bad CRC, using default environment
In: serial
Out: serial
Err: serial
Setting 0x181162c0 to 0x30602100
Hit Ctrl+B to stop autoboot: 0
Loading .text @ 0x80060000 (1985278 bytes)
## Starting application at 0x80060000 ...
OpenWrt kernel loader for AR7XXX/AR9XXX
Copyright (C) 2011 Gabor Juhos <juhosg@openwrt.org>
Decompressing kernel... done!
Starting kernel at 80060000...
Any ideas what might be causing this?
P.S. Under no circumstances that flashing stock TP-Link firmware works. Either it passes that stage which goes straight to the command line or it just becomes stuck.
I'm another step closer to return it to Amazon. I can't make sense of this situation but seriously consider something is terribly wrong, hardware-wise.
There's a feeds.conf.default file in your buildroot. Copy it to feeds.conf if you don't have that yet, and comment the repos you don't need. Mine shows four: packages, routing, luci and telephony.
Mine is slightly the same with an addition:
src-git packages https://git.openwrt.org/feed/packages.git
src-git luci https://git.openwrt.org/project/luci.git
src-git routing https://git.openwrt.org/feed/routing.git
src-git telephony https://git.openwrt.org/feed/telephony.git
src-git freifunk https://github.com/freifunk/openwrt-packages.git
#src-git video https://github.com/openwrt/video.git
#src-git targets https://github.com/openwrt/targets.git
#src-git management https://github.com/openwrt-management/packages.git
#src-git oldpackages http://git.openwrt.org/packages.git
#src-link custom /usr/src/openwrt/custom-feed
You should have all the active feeds in feeds/ in your buildroot. It looks like you are confusing the OpenWrt repos (which opkg will try to sync with) with the git repos the buildroot syncs with.
Your custom image won't have any custom feed repos unless you host them yourself. Or add existing ones to what's already in /etc/opkg/*feeds.conf.