ath79: Add support for CPE210 v1, CPE510v1, CPE220 v2#2252
ath79: Add support for CPE210 v1, CPE510v1, CPE220 v2#2252adschm wants to merge 8 commits intoopenwrt:masterfrom
Conversation
|
@apcameron Can you check the shared DTSI on your CPE510/610? Should be sufficient if you only pick patch no. 2. (However, note that I have not even build-tested yet). @p-wassi @apcameron @981213 |
|
@adrianschmutzler You could try to copy ethernet setup from Qihoo C301. |
|
A correct result should be that one port is on builtin switch and the other one is eth1. |
blocktrron
left a comment
blocktrron
left a comment
There was a problem hiding this comment.
Regarding the mtdsplit: This is currently not working as the kernel is prepended by the LZMA loader.
We might however be able to either add a kernel-offset property for this case or even detect this circumstance automatically. I will look into this later.
There was a problem hiding this comment.
status property should be safe to drop. The GPIO controller has it's status not set to disabled in the inherited dtsi.
There was a problem hiding this comment.
Yes, will do it with the next update.
|
@blocktrron Note that mtdsplit IS working on CPE210 v2/v3 (qca9533). I own both CPE210 v1 and v2, so I would be able to run tests if required (I however have no serial access). |
|
@adrianschmutzler Both the CPE210v2 and CPE210v3 don't use the LZMA loader prepended to the kernel image, so the mtdsplit driver can read proper offsets from the first header. |
dedeckeh
added
the
build/scripts/tools
|
@adrianschmutzler @robimarko is also looking at the TP-LINK CPE210 V1 and I believe has it working on the ath79 branch so you may want to work with him on this. As far as your changes for the TP-LINK CPE610 v1 and CPE510 V2/V3 I can try to test a build within the next week or so time permitting. |
|
Thanks @981213 , ethernet ports are working now ( However, I have some remaining issues:
|
|
@apcameron So the CPE220 V2 is identical to the CPE210 V1? |
|
@adrianschmutzler it appears to be almost identical. I do not have one but I helped someone in New Zealand get it working. Note The CPE210 V1.1 and CPE220 V2 sometimes have a problem being recovered and what I discovered is it looks for vmlinuz when recovering and this is what I did We were then able to use scp to upload a full version of the software and use sysupgrade -F -v -n /tmp/filename.bin to reflash it. The T-LINK CPE220 V3 which I am working on is similar to the CPE210 V2 but with 2 ethernet ports. |
981213
added
target/ath79
This is expected. eth0 connects to port 0 of builtin switch so it's always link up. You can use swconfig trigger on switch port 4 instead.
No idea about this one :( |
If I add it here (which looks trivial), can you have the 220v2 tested?
I know :-( They seem to ship different bootloaders (or whatever). I bricked the first lended CPE210 I received and then had to remove the chip and reflash it to get it working again. TFTP recovery never worked on this one. (I did not try vmlinuz) |
adschm
force-pushed
the
cpev1p3
branch
3 times, most recently
from
ee7a772 to
f7e2f42
Compare
Works fine now (just pushed the final state), network config seems to be set up correctly now. Is there any kind of objective guideline which port should be WAN and which LAN by default? I still have the reboot-problem. (Switched power adapter and cable to be sure.) |
|
I have added support for CPE510 v1 on top. The corresponding #1704 has not seen updates since January, and adding the device here is trivial. Considering CPE210v1 and CPE510v1, DTSes have considerable amount of shared code. I'm undecided on whether I should create another cpexxx-v1.dtsi for those (will be a lot of nesting then ...) |
|
@adrianschmutzler If I remember from comments by @ynezz in an earlier PR #1748 for the CPE610-v1 all references to As far as testing the CPE220 V2 I will include you in a e-mail to the person who tested it for me in the past. |
|
Hmm, if I do not (un)plug cables, it does not reboot. |
|
@adrianschmutzler if you check you e-mail you will see you now have a Tester for the TP-LINK CPE220 V2. |
|
Looks like something is triggering the reboot: |
|
@adrianschmutzler If the Ports seem to be the wrong way around try adding for all the devices with 2 ports in this PR |
|
@adrianschmutzler I have created a build based on your PR and done a quick test. TP-LINK CPE610 v1 works as before |
|
@apcameron Thanks for testing.
I'm aware of that choice. However, how do you define the "right way" here? Is this somehow implied by vendor firmware? |
|
@adrianschmutzler It is so that for existing users port LAN0 still is the port that provides an ip to the device that connects to it. |
|
Fixed commit title capitalization and did (trivial) rebase. |
|
@blocktrron @ynezz @981213 |
There was a problem hiding this comment.
bae927c#diff-b232b41a358a2b44c64fb32925bd265a
The removal of the CPE510 v2 from the v1 Supportlist will brick devices in ar71xx when upgrading from an earlier build.
Honestly, as ar71xx is source only now, i would (personally) be finde dropping the CPE510 v2 from here. But as it doesn't seem to hurt us much, maybe exclude the removal and place a short comment explaining the situation.
What do you think?
There was a problem hiding this comment.
Ah, I didn't find the commit you referenced in the first place.
Several things cross my mind here:
- Removing v2 from CPE510 v1 support list already is a separate patch in this PR, so there won't be interference with the rest no matter what we decide.
- I also change ar71xx when adjusting kernel partitions. I don't think this should be backported, so this will already introduce differences between 19.07 and master anyway. In this context, it does not seem too wrong to touch CPE510v2 support , too.
- Having the link to the initial patch introducing v2 "support", I'm currently in favor of just reverting that patch entirely. It was a hack in the first place, and reverting the patch will remove support (of v2 in master/ar71xx) more cleanly than just changing the safeloader data.
- I'm aware that this complicates backporting if we ever have to fix something with CPE510. Nevertheless, not removing lines in safeloader now will "enable" flashing CPE510v2@ath79 with v1 images, won't it? So, I would argue to keep the master clean (and remove CPE510v2@ar71xx). Fixes for [email protected] can still be done by just basing patches directly on it.
- What do you mean by "maybe exclude the removal"?
So, I would:
- Apply this patchset WITHOUT the patch removing v2 from safeloader.
- Remove the v2 support afterwards with "git revert bae927c". It might be easier if you just do it, if you do not want or have time I can also provide the patch.
- Change the SUPPORTED_DEVICES for CPE510v2 in ath79 to "cpe510" as the current "cpe510-v2" seems to be wrong then. Again, you can just do that during merging this PR or I can send a small patch for this one afterwards.
There was a problem hiding this comment.
(If you do prefer that, I can obviously also just add a bigger explanation to the existing patch)
There was a problem hiding this comment.
Personally, i would leave the SupportList for the CPE510v1 untouched and simply place a note above it, that the CPE510v2 entries can be deleted after ar71xx is deprecated.
I also change ar71xx when adjusting kernel partitions. I don't think this should be backported, so this will already introduce differences between 19.07 and master anyway. In this context, it does not seem too wrong to touch CPE510v2 support , too.
The kernel partition change is no change which possibly breaks updates here. ar71xx is source only, but I'm uncertain if we should really break compatibility now (or invest a lot of time in working around this issue).
Having the link to the initial patch introducing v2 "support", I'm currently in favor of just reverting that patch entirely. It was a hack in the first place, and reverting the patch will remove support (of v2 in master/ar71xx) more cleanly than just changing the safeloader data.
I agree, the patch is a hacky way of adding support. However, ar71xx is full of those hacks (See the TL-WR841 mess). The Question of dropping support for the v2 is something I wouldn't want to decide alone.
Nevertheless, not removing lines in safeloader now will "enable" flashing CPE510v2@ath79 with v1 images, won't it?
Yes, however (given we provide both separate images), this shouldn't be an issue. Flashing the "wrong image" is never a good idea, so it is in this case.
So, I would argue to keep the master clean (and remove CPE510v2@ar71xx). Fixes for [email protected] can still be done by just basing patches directly on it.
Again, this comes close to a removal of the CPE510v2 in ar71xx. This is something you should probably get opinions on via the ML. Yes, i think I'm "to new" to decide something like this alone 😕 I hope you understand this.
What do you mean by "maybe exclude the removal"?
To remove 1d73264 from this PR.
There was a problem hiding this comment.
Okay, just drop the patch then.
I will think about whether the CPE510v2 topic is important enough to move it to the mailing list.
|
PR #1631 was created to give the CPE510 V2 its own profile on the ar71xx branch but closed when I was told to switch to the ATH79 Branch. |
|
@apcameron I will have a look at #1631 . Maybe one can boil it down to something that's small enough to be accepted as a fix for the current hack in ar71xx. Maybe it's too much work and we just leave it as it is. |
|
I Agree the best approach is to remove 1d73264 from this PR. |
|
I've removed the patch and rebased on latest master. |
|
I added a patch for the CPE510v2 issue in #2302 |
|
Checkpatch found the following misspells: Otherwise, this looks good to me. |
|
fixed "address" typo (3 times). |
This is a preparation for ath79 support of the CPE210/CPE510 v1. Kernel size is chosen equal to the latest update for CPE610 v1. This also updates the partition size in ar71xx target, so code remains consistent if someone looks up the device. Since CPE210, CPE510, WBS210 and WBS510 (all v1) share the same partition layout definition, and are on deprecated target anyway, this changes them all at once. Signed-off-by: Adrian Schmutzler <[email protected]>
This puts some common code into a new shared DTSI. Common nodes are chosen so that the new DTSI can be used for CPE210 v1, too. Signed-off-by: Adrian Schmutzler <[email protected]>
The loader-okli is shared by several TP-Link CPExxx devices, so give it its own definition to prevent too much code duplication. Signed-off-by: Adrian Schmutzler <[email protected]>
Specifications:
* SoC: Qualcomm Atheros AR9344 (560 MHz)
* RAM: 64MB
* Storage: 8 MB
* Wireless: 2.4GHz N based built into SoC 2x2
* Ethernet: 2x 100/10 Mbps, integrated into SoC, 24V POE IN
Installation:
Flash factory image through stock firmware WEB UI
or through TFTP:
To get to TFTP recovery just hold reset button while powering on for
around 4-5 seconds and release.
Rename factory image to recovery.bin
Stock TFTP server IP:192.168.0.100
Stock device TFTP address:192.168.0.254
Signed-off-by: Adrian Schmutzler <[email protected]>
TP-Link CPE510-v1 is an outdoor wireless CPE for 5 GHz with two Ethernet ports based on Atheros AR9334 Specifications: - 560/450/225 MHz (CPU/DDR/AHB) - 2x 10/100 Mbps Ethernet, 1x PoE-in, 1x PoE-out - 64 MB of DDR2 RAM - 8 MB of SPI-NOR Flash - 2T2R 5 GHz - 13 dBi built-in antenna - Power, LAN0, LAN1 green LEDs - 4x green RSSI LEDs Flash factory image through stock firmware WEB UI or through TFTP: To get to TFTP recovery just hold reset button while powering on for around 4-5 seconds and release. Rename factory image to recovery.bin Stock TFTP server IP:192.168.0.100 Stock device TFTP address:192.168.0.254 Based on the work of Paul Wassi <[email protected]> Signed-off-by: Adrian Schmutzler <[email protected]>
This seems to be identical to CPE210 v1 despite having removable
antennas.
Specifications:
* SoC: Qualcomm Atheros AR9344 (560 MHz)
* RAM: 64MB
* Storage: 8 MB
* Wireless: 2.4GHz N based built into SoC 2x2
* Ethernet: 2x 100/10 Mbps, integrated into SoC, 24V POE IN
Installation:
Flash factory image through stock firmware WEB UI
or through TFTP:
To get to TFTP recovery just hold reset button while powering on for
around 4-5 seconds and release.
Rename factory image to recovery.bin
Stock TFTP server IP:192.168.0.100
Stock device TFTP address:192.168.0.254
Signed-off-by: Adrian Schmutzler <[email protected]>
According to detective grep, with this patch all devices should be labelled "TP-Link" consistently. Signed-off-by: Adrian Schmutzler <[email protected]>
All those devices only have one MAC address, which is also printed on label (obviously). Signed-off-by: Adrian Schmutzler <[email protected]>
|
@adrianschmutzler I've pulled your patches except for ffd49dd into my staging tree, as this concept has still the general RFC PR open. I propose you add this patch there after I've pushed your other patches to master. Is this fine for you? |
|
@blocktrron Yes, I will just add the label-mac-device to my label MAC PR. It was just included here so I do not forget... |
|
Okay, closing then. |
6 participants
This adds support for CPE210 v1, CPE510v1, CPE220v2 after some preparations (tplink-safeloader partition adjustments and DTSI reorganization).
This is tested and ready for merge.
The device boots and has working WiFi, but for ethernet I need help with the correct setup.Note that this is a two-port device compared to most of the other CPExxx devices which are one-port (CPE210 v2+, CPE510 v2+, CPE610v1).
There has already been a discussion for the very similar CPE510 v1 in #1704, but work on it stopped in-between so I fail to draw helpful conclusions on the correct setup.Ethernet is working now (thanks to 981213)
Side-note:
I have checked tplink-safeloader with automatic partition splitting (tplink-safeloader and tplink,firmware) as well as uimage (tplink-safeloader-uimage and denx,uimage) without success as already reported on the other CPE devices with ar9344.