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:
http://www.8devices.com/community/viewtopic.php?t=1051&p=4206
1 „Gefällt mir“
Then i’m out of ideas…
Might be some issue with the gpio settings, the driver or a broken serial adapter 
Or the moon has the wrong phase when you are testing
Edit:
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 - OpenWrt Forum
Ah, ok, cool.
Didn’t know the other thread existed
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
Hi!
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?
cheers
wakkomon
Yes,got it working.
You can find sources here:
https://github.com/robimarko/source/tree/CPE210-v2-clock
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
1 „Gefällt mir“
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‘
wifi
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:Google Drive : connexion
1 „Gefällt mir“
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
1 „Gefällt mir“
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?
1 „Gefällt mir“
Hallo
Es scheint ja voran zu gehen. Ist schon absehbar wann es eine Firmware für den CPE210 V2 geben wird?
Gruß
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?