ramips: add support for TP-Link Archer C5 v4#2174
ramips: add support for TP-Link Archer C5 v4#2174dengqf6 wants to merge 4 commits intoopenwrt:masterfrom
Conversation
|
Please don't patch the entire realtek switch SDK into openwrt tree. We only need to set up VLAN and there is nothing else useful. |
|
@981213 |
|
Leaked datasheet here, which may be helpful :) edit: BTW there are some other interesting documentations in this repo. |
RTL8367S is configured using MDIO bus, and currently supported realtek switches are configured using their own SMI protocol. I don't know if the register arrangement are similar but you'll at least need to add a different register accessing method and probing mechanism. |
|
There has been a reorganization in ramips target today. Please:
Thank you! Note that this in particular will require naming the device tplink_archer-c5-v4 / tplink,archer-c5-v4 in your case. |
|
What a crappy driver for a crappy chip... |
I don't expect that. There are some differences. It could work for your device, but that doesn't mean it works for others. Does it work in the current state at all? I expect that it wouldn't compile. |
dengqf6
force-pushed
the
c5v4
branch
3 times, most recently
from
d13b3d2 to
5654a47
Compare
dengqf6
changed the title
|
@981213 @CodeFetch |
There was a problem hiding this comment.
Indentation is wrong here
There was a problem hiding this comment.
Indentation is wrong here
There was a problem hiding this comment.
better use dev_info()
and it's "checking chip_num..."
There was a problem hiding this comment.
please add curly braces or remove newline after "else" and remove one level of indentation to make it more readable
There was a problem hiding this comment.
remove space after "(" and add space after if
There was a problem hiding this comment.
Wrong indentation. use 3 spaces instead of 4 and tabs before values
|
@CodeFetch Would you mind sending your review to the original patch on mailing list? @dengqf6 just picked those patches here. |
dengqf6
changed the title
dengqf6
changed the title
|
@CodeFetch As he did not reply to the mailing list, I fixed the code format myself. |
There was a problem hiding this comment.
I would prefer putting the dev_info() before the if so this message will always be printed and remove the double-curly-braces and write
} else switch(...) {
(...)
}
instead. This is rare, but clean C-formatting as far as I know.
There was a problem hiding this comment.
By the way there is currently one level of indentation missing in the switch statement
dengqf6
force-pushed
the
c5v4
branch
2 times, most recently
from
a9e28e3 to
9036027
Compare
I can't test with C5 v4 right now, but I will test your code with my Dir810l with has same slow speed with 2.4g(and same Soc). |
It works as before.
I rebased @981213 branch over @dangowrt (check it here luizluca/openwrt@68b2f84). It still works but 2.5Ghz is still the same. First iperf3 runs is using 2.5Ghz to a wired target, the second one uses 5Ghz. |
|
rtl8369 is the wired port switch, so maybe it is the wired performance (not wifi) that needs to be looked at ? Could you guys test it, please ? |
It might have some wired limitations but the performance improves from 10 to more than 150 Mbps simply changing from 2.5Ghz to 5Ghz. |
Last time I tested, I can reach 300mbit in wired internet using pppoe. Wired switch speed is not an problem I think. |
I tested with 810l and have same speed as before. I will leave it conected to see if is more stable than before. |
@981213 , is your branch good enough for merge? |
|
Hello, My installation (based on luizluca/openwrt@68b2f84) is crashing once each day or two. It might be more if it reboots by itself although there is no /sys/kernel/debug/crashlog (if it supports it). Free tells me it has lots of used memory: With only 14 userland processes (plus two shells started after the crash). I guess it is all in kernel space. My build is more than 20 days old. Is there any known fix in master? Or could it be a side effect from using @981213 branch over @dangowrt? edit: after the reboot, it is much cleaner: Userland is even using more memory than before. |
|
Maybe it is now fixed: 08a42ef I rebased it just now. Let's see how things go. |
I don't know if that was 08a42ef but r14808+3-499924adf0 is working as expected (including the bad 2.5GHz performance). After 5 days, no significant change in memory usage: Anyway, the memory issue was not specific to this device. 2.5GHz will not be fixed in anytime soon and other already merged devices are also affected. Wouldn't it be better to merge as it is (PR or with @981213 fixes)? There are build being kept outside OpenWrt for this device. We could have that effort inside OpenWrt. |
|
@luizluca: for the record, which devices also share the badly-supported 2.5GHz radio and were already merged? I also agree this should not get in the way of this PR. |
|
I agree too, this is general mt7620a driver problem, not C5 V4 only. |
I'm just saying what has being commented in this PR. I guess all these are affected as they share the same SoC: |
|
I try latest openwrt build in my D-link 810l to test wifi performance before flash my archer c5 v4, and wifi is much better than before, now it reach 100mbit in wifi 2.4ghz in both down and up speed. I will test it a few days more to see how it perform and see stability of kernel, then flash archer c5 later. Maybe c5 can't perform like 810l because some radio differences, but at least is not problem of mt7620 anymore. |
@981213 I tested on my WN-AC733GR3 (ramips/mt7620, RTL8367RB, RGMII on extif1), works without any issues. |
|
Because I no longer have this router, I'm closing this pull request. |
|
I wonder why this was not merged. It won't break existing devices, it won't brick on install and it provides decent wired and 5GHz performance. The poor 2Ghz is not ideal but other devices are in master missing features while all features are implemented for this device. I tested it multiple times until everything just worked. Thanks @dengqf6 for your work. |
|
I'll try to take from here. It looks like af5a17d added support for rtl8367s. |
That's mediatek target, not ramips. The only way to get anywhere with this PR is through @981213 ... |
Isn't mediatek target simply the new ramips? target/linux/ramips/mt7620
If the get rid of the switch patches, the PR will only be a normal DTS/leds/makefile port. It would be much easier to get merged. |
|
It looks like that same driver added by @blogic was already being used in 19.07.x port published in OpenWrt wiki (https://github.com/benwht/openwrt/commit/b57307fa1e498e9b82fe53cdcf58e6005a73baef.patch). It should work. |
And who do you think will review porting the mediatek driver to ramips? |
It's not. ramips are for mediatek mips and former ralink socs. the mediatek target is for the new arm socs.
That switch driver is still a bit scary for me to touch :( |
Thanks. Anyway, it looks like the same driver added for mediatek target is already in use for everyone that is currently using @benwht port for 19.07 (and even 18.06). If true, I could say it is in use for years.
It looks like rtl8367c or rtl8367s (I'm confused with cross-referencing between these two) is also needed for mediatek target mt7622. @blogic took a quick path and added a completely new driver specific for mediatek target and configured it as builtin. This PR was based on changes to rtl8367b driver (target/linux/generic) to also support rtl8367c. It looks like one option should go. For a device perceptive, it should not matter which one is in use if they work as expected, specially when compiled as a module. I don't know which one costs less to maintain in OpenWrt tree but OpenWrt is already "paying" it for mediatek target. The resulting ipk for the standalone driver is 10x bigger, probably because it might not depend on other modules.
I don't feel comfortable to post a patch from someone else to mail list when I'm not sure that exactly it does. I'm a hobby kernel developer and I never touched switch drivers (yet). Eventually someone will suggest a change and I will not have the background to discuss it. The two options for rtl8367c support can be discussed between the big guys in a dedicated thread or PR. This PR does work and it would cost nothing if accepted. However, it didn't get merged after 20 months. I'll try an alternative reusing the existing driver, probably migrating it from target/linux/mediatek to target/linux/generic and nobody needs to touch a single switch driver. I hope this clears the path for C5v4 to get merged. This PR rebased just worked as expected. --- this PR rebased
+++ using new rtl8367c driver
====
@@ -25,10 +25,10 @@
] Kernel command line: console=ttyS0,115200 rootfstype=squashfs,jffs2
] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes, linear)
] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes, linear)
-] Writing ErrCtl register=00000800
-] Readback ErrCtl register=00000800
+] Writing ErrCtl register=0000080c
+] Readback ErrCtl register=0000080c
] mem auto-init: stack:off, heap alloc:off, heap free:off
@@ -51,8 +51,12 @@
] IO 0x0000000010160000..0x000000001016ffff
] rt2880_gpio 10000600.gpio: registering 24 gpios
] rt2880_gpio 10000600.gpio: registering 24 irq handlers
+] rt2880_gpio 10000638.gpio: registering 16 gpios
+] rt2880_gpio 10000638.gpio: registering 16 irq handlers
] rt2880_gpio 10000660.gpio: registering 32 gpios
] rt2880_gpio 10000660.gpio: registering 32 irq handlers
+] rt2880_gpio 10000688.gpio: registering 1 gpios
+] rt2880_gpio 10000688.gpio: registering 1 irq handlers
] PCI host bridge to bus 0000:00
@@ -107,28 +111,24 @@
] libphy: Fixed MDIO Bus: probed
-] gsw: setting port4 to ephy mode
-] libphy: mdio: probed
-] mtk_soc_eth 10100000.ethernet: using fixed link parameters
-] mtk_soc_eth 10100000.ethernet: loaded mt7620 driver
-] mtk_soc_eth 10100000.ethernet eth0: mediatek frame engine at 0xb0100000, irq 5
+] Error: Driver 'mtk_soc_eth' is already registered, aborting...
] rt2880_wdt 10000120.watchdog: Initialized
] NET: Registered protocol family 10
@@ -149,11 +149,6 @@
] hub 1-0:1.0: 1 port detected
-] rtl8367b rtl8367s: switch phy addr=29
-] rtl8367b rtl8367s: using MDIO bus 'mdio'
-] rtl8367b rtl8367s: RTL8367C chip found
-] rtl8367b rtl8367s: checking chip_num=0x6367 ver=0xa0...
-] libphy: rtl8367s: probed
] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
@@ -166,22 +161,12 @@
] random: jshn: uninitialized urandom read (4 bytes read)
-] rtl8367b rtl8367s: checking chip_num=0x6367 ver=0xa0...
-] mtk_soc_eth 10100000.ethernet eth0: port 5 link up (1000Mbps/Full duplex)
-] 8021q: adding VLAN 0 to HW filter on device eth0
] urandom_read: 4 callbacks suppressed
] ...
] random: procd: uninitialized urandom read (4 bytes read)
-] mtk_soc_eth 10100000.ethernet eth0: port 5 link down
+] urandom-seed: Seeding with /etc/urandom.seed
] procd: - early -
@@ -210,73 +195,57 @@
] random: crng init done
-] rtl8367b rtl8367s: checking chip_num=0x6367 ver=0xa0...
-] mtk_soc_eth 10100000.ethernet eth0: port 5 link up (1000Mbps/Full duplex)Tomorrow I'll try to isolate the cause. |
|
It looks like it is a conflict when I have kmod-switch-rtl8366-smi loaded. Without that, the driver does load. The new driver also changed the CPU port from 7 to 5. With some more DTS changes I got a running config. I created a new PR based on that approach. |
|
See #14418 |
14 participants
TP-Link Archer C5 v4 is a dual band router with 5 GbE ports
Advertised as AC1200 for its 867Mbps (2×2) 5GHz band and 300 Mbps (2×2) 2.4GHz band.
Specs:
Flash instructions:
Currently one has to install OpenWrt only via the serial console
This PR includes the RTL8367S driver from mailing list
The
TPLINK_HWIDTPLINK_HWREVTPLINK_HWREVADDare dummy values. TP-Link seem s to use an RSA signed header for the stock firmware.