TP-Link CPE210 v2 - Gluon Support


I haven’t but that is a good idea.
Will give it a go today.

Without serial, it is pretty much a dead end.


Unfortunately, bdinfo was removed from u-boot used by TP-Link
Here are available commands:
ap143-2.0> help
? - alias for ‘help’
boot - boot default, i.e., run ‘bootcmd’
bootd - boot default, i.e., run ‘bootcmd’
bootm - boot application image from memory
cp - memory copy
erase - erase FLASH memory
fwrecov - TP-Link Firmware Recovery Tools
help - print online help
mct - simple RAM test
md - memory display
mm - memory modify (auto-incrementing)
mtest - simple RAM test
mw - memory write (fill)
nm - memory modify (constant address)
ping - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
progmac - Set ethernet MAC addresses
progmac2 - Set ethernet MAC addresses
reset - Perform RESET of the CPU
run - run commands in an environment variable
setenv - set environment variables
tftpboot- boot image via network using TFTP protocol
version - print monitor version

Also, here is boot log when loading kernel over TFTP

Kernel disabled ttyS0, loads 8250 driver for serial and then console is not re-enabled like it should be.
I found similiar issue here:



Then i’m out of ideas…
Might be some issue with the gpio settings, the driver or a broken serial adapter :smiley:
Or the moon has the wrong phase when you are testing :confused:

Ok, you might be able to change the baud rate after the driver has loaded to a different level? Lede-dev IRC suggestion


It looks like it is more than just baud rate.
Appears that TP-Link has mode a lot of non standard modifications or just mistakes.

You can see that we have been even developing custom U-boot
Much more information here:First try to support CPE210 v2 - will not boot - For Developers - LEDE Project Forum


Ah, ok, cool.
Didn’t know the other thread existed :smiley:
The borked uboot would explain the wrong clock in the kernel output then. (blogic noticed that)


It looks like it is not U-boots fault since it reads from QCA953X registers and uses resistor combination to determine clocks.
It looks like TP Link messed up those resistors and therefore even in custom U-boot currently clocks are detected wrong.

To me it looks like TP Link just manually forced correct clocks in firmware instead of using ones passed by U-boot



are there any news on CPE210 V2 and gluon support?
i have three of this devices and didn’t get any older hardware version so it would be a real benefit to get gluon working on it
i’m not a developer, but may be i can help in any way?



@robimarko has successful get LEDE works on CPE210 v2, right ?


Yes,got it working.
You can find sources here:

And built images here:

I will make a PR to add it to LEDE but it will take some time due to huge backlog of patches and PRs


Danke für die Mühe…

Da mir das nötige know-how fehlt, muss ich jetzt warten bis eine Gluon Unterstützung folgt und die dann an FFKS anlehnt.


robimarko, thank you very much i managed to install the firmware!

but it seems wifi does not work, is this correct or should it already work?
i set following:

uci set wireless.radio0.disabled=‘0’

i also set ssid and channel
after that i got the wlan0 device in ifconfig, but seems no radio enabled i cannot receive any signal on a client

any idea?


That is weird.
You are the second one with that issue.

I will try to reproduce it on mine since I have not had that issue.
Can you post full log and settings used?


I was able to reproduce it and found the cause.
Reference clock was wrong for dev-wmac, that means that same way to bypass reference clock detection for CPU does not work for dev-wmac.
That means that this is not ready for upstream until I figure out a way to bypass it properly.

Source updated with temporary fix,also rebased on master to bump kernel.
Fixed images available here:CPE210 v2 – Google Drive


WOW thank you, that was FAST and i confirm it is working ;-))
downloading luci package webinterface for “usual” configuration does work also so i’m really happy

till a “freifunk” firmware will be released i will now try following workaround:

  • CPE210 in “Freifunk”-LAN by cable from another FF firmware router
  • Freifunk Firmware Router with VLAN for client and MESH
  • configuring CPE with same VLANs for client (ap) and mesh (ad-hoc) wifi network

if this works i will report, perhaps this will be a good workaround in general


btw i just checked in the new build luci seems already be included also thanks!

  • confirmed now VLANs are working also
  • client-net in VLAN working
  • Ad-Hoc-Mode also working in different vlan

but i’m not really sure how to accomplish the ad-hoc-mesh network to the “main” ff router without getting a ethernet loop, i’m still testing carefully. may be seperate vlans for each AP needed


sorry again for bothering you

is there a way to add “batman-adv” package to the firmware? this would make the meshing stuff much easier, i tried to install package but did not get the right package for this kernel


ok i managed to add batman-adv by myself by just copiing the package from openwrt routing sources to the LEDE project (kernel must match to package binaries) , confirmed badman-adv and ad-hoc working

is there any update in integration to gluon project?


3 Beiträge wurden in ein neues Thema verschoben: TP-Link CPE510v2 - Gluon Support



Es scheint ja voran zu gehen. Ist schon absehbar wann es eine Firmware für den CPE210 V2 geben wird?



kann ich leider nicht sagen…

ich habe zwar eine lauffähige LEDE- firmware “binary” mit batman-adv erstellt und aufgespielt und denn Rest “zu Fuß” per SSH console und luci nachinstalliert… mir fehlen leider die Kenntnisse die Projekte auf “Quellcodeebene” wieder zusammenzufügen um gleich alles fertig in einem image zu haben

vielleicht kann da jemand helfen oder mir sagen wo steht wie das geht?