mpc85xx: TP-Link TL-WDR4900 v1 ~~resurrect~~ and convert to DSA #10850
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
CHKDSK88
changed the title
github-actions
bot
added
kernel
|
Wow dsa work good? |
|
DSA status response is quite slow: But it works. LAN/WAN separation works, vlan filtering works, fdb prints well. Switch forward well. Enough for initial support. |
|
@CHKDSK88 god damn even on this target in band doesn't work.... |
|
It's strange. One time was very fast, another 5seconds... It looks that first time wrong data was captured... |
|
@CHKDSK88 let me give you some context... the switch supports in band method to send and receive mgmt stuff.... |
|
@Ansuel This Big Endian processor. Could endianess be an issue? |
|
@CHKDSK88 YES TOTALLY! the problem is also present on ath79 that is also big endian.... so 99% it's that... the function used are probably not accounting for endianness on building the payload required but you need to help me with this with some tcpdump (full tcpdump without the header stripped) to check if the payload is wrong should be simple... you can generate a sample packet with the ethtool -S and with the bridge fdb show command. And take packet from eth0 (or whatever is the cpu port) |
Do You see anything suspicious? |
Hurricos
reviewed
Sep 30, 2022
target/linux/mpc85xx/image/p1010.mk
Outdated
| strings -td < /tmp/uboot | grep '^ *[0-9]* spiboot=' | \n$\ | ||
| awk '{print $$$$1}' | \n$\ | ||
| while read offset; do \n$\ | ||
| echo -n "spiboot=sf probe 0;sf read 2000000 60200 69f000;" | dd of=/tmp/uboot_patched bs=1 seek=$$$${offset} conv=notrunc \n$\ |
There was a problem hiding this comment.
If we have to patch, I would prefer not to hard-code the bootcmd, but instead, refer to a u-boot variable, and then fw_setenv that variable appropriately. (We would first of course need to make the u-boot env partition variable writable.)
There was a problem hiding this comment.
This device have only hardcoded envs and no 'saveenv' cmd. Tp-link offen offer u-boot without env partition. How to find in binary if env partition creation is possible?
There was a problem hiding this comment.
Edit: Environment storage removed, it would erase the MAC address!
I modified and compiled uboot, adding several commands (cmp, cp, echo, nm, mm, mw, test, unzip...).
Openwrt detection can be easily done now by searching the "Openwrt" string at the start of the kernel:
bootcmd=run openwrt_detect
openwrt_detect=run openwrt_str_load;if cmp.b 2000000 2000008 8;then echo Openwrt found;run openwrt_boot; else echo Openwrt not found;run spiboot;fi
spiboot=sf probe 0;sf read 2000000 60200 29f000;sf read 3000000 50000 10000;bootm 2000000 - 3000000
openwrt_boot=sf probe 0;sf read 2000000 60200 69f000;sf read 3000000 50000 10000;bootm 2000000 - 3000000
openwrt_str_load=mw.b 2000000 0 8;mw.b 2000000 4f;mw.b 2000001 70;mw.b 2000002 65;mw.b 2000003 6e;mw.b 2000004 57;mw.b 2000005 72;mw.b 2000006 74;mw.b 2000007 20;sf probe 0;sf read 2000008 60228 8
These commands are already included in the modded uboot and it will work right away.
Modded uboot: wdr4900v1_uboot_mod.tar.gz
It's ready for flashing, ex. following the uboot patch guideline:
opkg update
opkg install kmod-mtd-rw
cd /tmp
wget https://github.com/openwrt/openwrt/files/9690519/wdr4900v1_uboot_mod.tar.gz -O uboot_mod.tar.gz
tar -xzf uboot_mod.tar.gz
Just in case:
md5sum wdr4900v1_uboot_mod.bin
9d951e5a02e51c718650c0e5179c61da wdr4900v1_uboot_mod.bin
Flash:
insmod mtd-rw i_want_a_brick=y
mtd write wdr4900v1_uboot_mod.bin u-boot
Tested here exactly with these commands, everything works.
The last 64KB sector with the MAC/PIN etc is preserved, mtd is smart enough to only erase the required sectors, but better to backup the original in any case!
cat /dev/mtd0 >/tmp/mtd0.bin
cd /www
ln -s /tmp/mtd0.bin
Get the file by browsing http://router_ip/mtd0.bin
Boot log (Ignore the crazy frequencies, I'm running a HW modified wdr4900, not caused by uboot):
U-Boot 2010.12 (Oct 01 2022 - 14:55:41)
CPU: P1014, Version: 1.0, (0x80f10110)
Core: E500, Version: 5.1, (0x80212151)
Clock Configuration:
CPU0:1400 MHz,
CCB:400 MHz,
DDR:400 MHz (800 MT/s data rate) (Asynchronous), IFC:100 MHz
L1: D-cache 32 kB enabled
I-cache 32 kB enabled
Board: P1014RDB
SPI: ready
DRAM: 128 MiB
L2: 256 KB enabled
Using default environment
PCIe1: Root Complex of mini PCIe Slot, x1, regs @ 0xffe0a000
01:00.0 - 168c:abcd - Network controller
PCIe1: Bus 00 - 01
PCIe2: Root Complex of PCIe Slot, x1, regs @ 0xffe09000
03:00.0 - 168c:0033 - Network controller
PCIe2: Bus 02 - 03
In: serial
Out: serial
Err: serial
Net: initialization for Atheros AR8327/AR8328
AR8327/AR8328 v1.1 is found!
eTSEC1
Autobooting in 1 seconds
SF: Detected S25FL128S_64K with page size 256, total 16 MiB
16384 KiB S25FL128S_64K at 0:0 is now current device
SPI flash read successful
Total of 8 bytes were the same
Openwrt found
SF: Detected S25FL128S_64K with page size 256, total 16 MiB
16384 KiB S25FL128S_64K at 0:0 is now current device
SPI flash read successful
SPI flash read successful
## Booting kernel from Legacy Image at 02000000 ...
Image Name: POWERPC OpenWrt Linux-5.4.154
Image Type: PowerPC Linux Kernel Image (uncompressed)
Data Size: 2546236 Bytes = 2.4 MiB
Load Address: 01000000
Entry Point: 01000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 03000000
Booting using the fdt blob at 0x3000000
Loading Kernel Image ... OK
OK
Loading Device Tree to 00ffa000, end 00ffffff ... OK
[ 0.000000] Memory CAM mapping: 64/64 Mb, residual: 0Mb
[ 0.000000] Linux version 5.4.154 (builder@buildhost) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r16325-88151b8303)) #0 Sun Oct 24 09:01:35 2021
If anyone wants to compile himself, just replace the file
TL-WDR4900_eu_1.0_GPL/p1010/uboot/u-boot-2010.12/include/configs/P1010RDB.h
With this one P1010RDB.h.tar.gz
If compiling yourself, remember to append the generated uboot image to the boot header:wdr4900v1_uboot_header.tar.gz
Ex.
cat header.bin uboot.bin > wdr4900_uboot.bin
(First time I forgot and hard bricked it, requiring SPI programmer to recover)
There was a problem hiding this comment.
So if you have any better ideas for the booting, just let me know, after the initial setup mess now it takes just 20 seconds to compile a new uboot :)
Flashed original FW, detection is working:
U-Boot 2010.12 (Oct 01 2022 - 14:55:41)
CPU: P1014, Version: 1.0, (0x80f10110)
Core: E500, Version: 5.1, (0x80212151)
Clock Configuration:
CPU0:1400 MHz,
CCB:400 MHz,
DDR:400 MHz (800 MT/s data rate) (Asynchronous), IFC:100 MHz
L1: D-cache 32 kB enabled
I-cache 32 kB enabled
Board: P1014RDB
SPI: ready
DRAM: 128 MiB
L2: 256 KB enabled
Using default environment
PCIe1: Root Complex of mini PCIe Slot, x1, regs @ 0xffe0a000
01:00.0 - 168c:abcd - Network controller
PCIe1: Bus 00 - 01
PCIe2: Root Complex of PCIe Slot, x1, regs @ 0xffe09000
03:00.0 - 168c:0033 - Network controller
PCIe2: Bus 02 - 03
In: serial
Out: serial
Err: serial
Net: initialization for Atheros AR8327/AR8328
AR8327/AR8328 v1.1 is found!
eTSEC1
Autobooting in 1 seconds
SF: Detected S25FL128S_64K with page size 256, total 16 MiB
16384 KiB S25FL128S_64K at 0:0 is now current device
SPI flash read successful
byte at 0x02000000 (0x4f) != byte at 0x02000008 (0x36)
Total of 0 bytes were the same
Openwrt not found
SF: Detected S25FL128S_64K with page size 256, total 16 MiB
16384 KiB S25FL128S_64K at 0:0 is now current device
SPI flash read successful
SPI flash read successful
## Booting kernel from Legacy Image at 02000000 ...
Image Name: Linux-2.6.35
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 2178207 Bytes = 2.1 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 03000000
Booting using the fdt blob at 0x3000000
Uncompressing Kernel Image ... OK
Loading Device Tree to 00ffa000, end 00ffffff ... OK
Using P1010 RDB machine description
Memory CAM mapping: 64/64 Mb, residual: 0Mb
Linux version 2.6.35 (root@localhost.localdomain) (gcc version 4.5.1 (Sourcery G++ Lite 2010.09-55) ) #1 Wed Apr 24 20:09:29 CST 2013
There was a problem hiding this comment.
Hi there,
Could you provide a containerized build environment for your U-Boot which uses an OpenWrt build toolchain? For example, here:
I think a full U-Boot replacement would be most reasonable if anyone can compile from source.
There was a problem hiding this comment.
(I meant an OpenWrt compiler toolchain, really*. In the linked PR, I use OpenWrt's mips compiler toolchain.)
There was a problem hiding this comment.
Nope, using 32-bit Ubuntu 14 in Virtualbox vm, with the original TP-Link sources including the toolchain.
The original FW boots perfectly with the patched uboot. So the patch method is just fine, no need of custom uboot etc.
|
I'll be happy to test and provide feedback, but not having enough time to compile myself, could you upload the image somewhere? |
|
@CHKDSK88 Ok yes think we can confirm it's an endianness bug... The header is correct... problem is in the endianness of the in band payload.... This is you packet: mdio command (i assume also wrong) + (b040) I need to check the code to account for this... |
|
@CHKDSK88 can you test this patch? https://gist.github.com/Ansuel/7103d5e97d1bb3c855d85b4851b5d054 |
abajk
reviewed
Oct 2, 2022
| @@ -245,15 +245,17 @@ CONFIG_SPI_MEM=y | |||
| CONFIG_SRCU=y | |||
| # CONFIG_STRIP_ASM_SYMS is not set | |||
| # CONFIG_STX_GP3 is not set | |||
| CONFIG_SWCONFIG=y | |||
There was a problem hiding this comment.
It seems that Ocedo Panda also has a built-in switch. Shouldn swconfig remain enabled for the P1020 subtarget?
There was a problem hiding this comment.
Thank You. I forgot commit 'target/linux/mpc85xx/p1020/config-default' file.
CHKDSK88
force-pushed
the
tl-wdr4900_v1_resurrect
branch
from
66d63b4
to
0a7c7d6
Compare
It work very fast: Stats values are wrong. But the answer is instant. |
|
Nice! Can you provide a tcpdump with the ethtool call? Also test time with bridge fdb show |
|
@CHKDSK88 here is the patch that should in theory give you correct results Check for time bridge fdb show... ethtool if the value are correct and if the switch correctly works... If everything goes well i would ask you a tested-by tag to I can add it in the patch as I want to push the fix upstream. |
|
@CHKDSK88 i need the results with the tcpdump so i can check they correctly match :( |
Noe with correlated output. :) |
|
@CHKDSK88 thanks a lot aaand ethtool is still rip |
|
@CHKDSK88 ufff why the tcpdump doesn't have the packet now :( (both zip doesn't have the inband packet) |
|
@Ansuel Both answers are instant. |
|
@CHKDSK88 hope it's not too much can you wait a second or 2 between the tcpdump start, ethtool call and then the killall tcpdump? I really need the tcpdump with the ethtool packet to understand wth is wrong. Anyway everything else works correctly? every port works, no port dropping? |
|
@Ansuel Regular packages (switch forward, to cpu., from cpu) have no loses. |
|
@CHKDSK88 NICE the sleep thing made the trick and i have the required packet :D |
|
@CHKDSK88 ok this should produce correct ethtool values https://gist.github.com/Ansuel/d1c45184fd00b5e07fa1e1757d0fa996 |
|
So far no DHCP issues, but I will keep you updated. Sorry for getting off-topic here! I'm not sure if it is related, but it was not happening, AFAIK, before the patch series. I tried to unplug the Ethernet cable from the WAN port, we are using Micrel KSZ9031RNXCA, and then I got the following: It doesn't want to get up until I reboot the router manually before it, it does not want to be restarted in software. Not sure, if it is related: |
|
Looks like a lock got stuck and cause CPU stall I suggest to enable lock
debug and analyze the code flow in search of the CPU stall... The problem
will probably autofix by fixing the stall
Il Mer 21 Dic 2022, 16:37 Josef Schlehofer ***@***.***> ha
scritto:
… So far no DHCP issues, but I will keep you updated. Sorry for getting
off-topic here!
I'm not sure if it is related, but it was not happening, AFAIK, before the
patch series. I tried to unplug the Ethernet cable from the WAN port, we
are using Micrel KSZ9031RNXCA, and then I got the following:
Dec 21 16:05:48 turris kernel: [17922.724980] Micrel KSZ9031 Gigabit PHY ***@***.***:07: phy_poll_reset failed: -110
It doesn't want to get up until I reboot the router manually before it, it
does not want to be restarted in software. Not sure, if it is related:
[ 1548.091585] rcu: INFO: rcu_sched self-detected stall on CPU
[ 1548.097179] rcu: 1-....: (1 GPs behind) idle=bb3/1/0x40000002 softirq=9058/9068 fqs=3000
[ 1548.105453] (t=6002 jiffies g=13349 q=3439)
[ 1548.109723] Task dump for CPU 1:
[ 1548.112947] ***@***.*** state:R running task stack: 0 pid: 3080 ppid: 2 flags:0x00000804
[ 1548.122874] Call Trace:
[ 1548.125315] [c1817b20] [c0063458] sched_show_task+0x198/0x1d4 (unreliable)
[ 1548.132204] [c1817b40] [c00a38cc] rcu_dump_cpu_stacks+0xf0/0x148
[ 1548.138219] [c1817b70] [c00a92b8] rcu_sched_clock_irq+0x6b0/0x948
[ 1548.144321] [c1817bd0] [c00b07c4] update_process_times+0xa8/0xf8
[ 1548.150333] [c1817bf0] [c00c5de8] tick_sched_timer+0x98/0x2f4
[ 1548.156092] [c1817c20] [c00b12e4] __hrtimer_run_queues+0x180/0x28c
[ 1548.162279] [c1817c70] [c00b23b4] hrtimer_interrupt+0x164/0x380
[ 1548.168205] [c1817cc0] [c000a674] timer_interrupt+0x1c8/0x2b0
[ 1548.173964] [c1817d00] [c000138c] Decrementer+0x14c/0x160
[ 1548.179368] --- interrupt: 900 at fsl_pq_mdio_read+0x78/0xb0
[ 1548.185035] NIP: c067e750 LR: c06696ec CTR: 000002fb
[ 1548.190085] REGS: c1817d10 TRAP: 0900 Not tainted (5.15.84)
[ 1548.195919] MSR: 02029000 <VEC,CE,EE,ME> CR: 44000442 XER: 20000000
[ 1548.202465]
[ 1548.202465] GPR00: c067808c c1817df0 c2d8cda0 c181b00 00000700 0000071b 00000001 f1152520
[ 1548.202465] GPR08: f1152534 00000001 000002fa c0b8ddbc 44000444 00000000 c005c1cc c37253c0
[ 1548.202465] GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c266b820
[ 1548.202465] GPR24: c19af364 c0093bb4 00000000 c0093acc c181b558 0000001b 00000007 c181b00
[ 1548.237429] NIP [c067e750] fsl_pq_mdio_read+0x78/0xb0
[ 1548.242482] LR [c06696ec] mdiobus_read+0x4c/0x9c
[ 1548.247112] --- interrupt: 900
[ 1548.250161] [c1817df0] [02029000] 0x2029000 (unreliable)
[ 1548.255479] [c1817e00] [c0c0e628] 0xc0c0e628
[ 1548.259750] [c1817e20] [c067808c] kszphy_handle_interrupt+0x24/0x88
[ 1548.266023] [c1817e40] [c06608d0] phy_interrupt+0x3c/0x68
[ 1548.271426] [c1817e60] [c0093b0] irq_thread_fn+0x34/0xa0
[ 1548.276841] [c1817e80] [c0093f88] irq_thread+0x174/0x228
[ 1548.282159] [c1817ed0] [c005c30c] kthread+0x140/0x148
[ 1548.287216] [c1817f10] [c001126c] ret_from_kernel_thread+0x5c/0x64
[ 1559.051656] rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 1-... } 6188 jiffies s: 185 root: 0x2/.
[ 1559.062123] rcu: blocking rcu_node structures (internal RCU debug):
[ 1559.068394] Task dump for CPU 1:
[ 1559.071617] ***@***.*** state:R running task stack: 0 pid: 3080 ppid: 2 flags:0x00000804
[ 1559.081552] Call Trace:
[ 1559.084001] [c1817c40] [eedd2160] 0xeedd2160 (unreliable)
[ 1559.089407] [c1817c50] [c00c304c] clockevents_program_event+0x90/0x1f4
[ 1559.095961] [c1817c70] [c00b23f4] hrtimer_interrupt+0x1a4/0x380
[ 1559.101903] [c1817cc0] [c000a674] timer_interrupt+0x1c8/0x2b0
[ 1559.107661] [c1817d00] [c000138c] Decrementer+0x14c/0x160
[ 1559.113074] [c1817d10] [c19af364] 0xc19af364
[ 1559.117348] [c1817d20] [c003e65c] irq_exit+0x84/0xdc
[ 1559.122336] [c1817d40] [c0000be4] ExternalInput+0x144/0x160
[ 1559.127916] [c1817e30] [c0c0e628] 0xc0c0e628
—
Reply to this email directly, view it on GitHub
<#10850 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE2ZMQQZEHX6W7NOWGZHESLWOMP25ANCNFSM6AAAAAAQZELNXM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Yeah, but the stacktrace I got for the first time, but the spammimg of |
|
Problem is that it's stuck and the code never continue to do the reset or
other setup stuff
Il Mer 21 Dic 2022, 16:42 Josef Schlehofer ***@***.***> ha
scritto:
… Yeah, but the stacktrace I got for the first time, but the spammimg of
phy_poll_reset bothers me a lot as the WAN does not want to get UP when
it is plugged back. It wants to be restarted to get it working.
—
Reply to this email directly, view it on GitHub
<#10850 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE2ZMQXQWUP2XTNC4VCO7OTWOMQMRANCNFSM6AAAAAAQZELNXM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Oh, it is not related to your patch series. I reverted it, compiled it, installed it on the router and it is the same issue with the PHY. Sorry! The patch series is working for the switch as it should so far. |
|
btw this is the patch submitted upstream https://patchwork.kernel.org/project/netdevbpf/patch/20221216161721.23863-1-ansuelsmth@gmail.com/ Feel free to add tag to them |
|
@BKPepe i merged the related patch in master. I think this is ready and a first user of qca8k? |
I can give it a test-run. |
|
@Ansuel You only backported your patch to 5.15 but this commit enables dsa driver also for 5.10? I did not read the whole thread so maybe I miss something. |
|
Eh backport to 5.10 is possible but it's a lot of work. Should we really care? |
|
Nope.
|
|
Right 5.10 doesn't have the Mgmt Eth but I need to check if I need to
backport the cache fixup
Il Sab 4 Feb 2023, 21:38 Josef Schlehofer ***@***.***> ha
scritto:
… Nope.
- 5.10 works OTB.
- 5.15 works with Ansuel patch series, but on Turris 1.x routers, we
do have some issues with PHY as said above, but we will need to investigate
it further what is happening.
—
Reply to this email directly, view it on GitHub
<#10850 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE2ZMQTOOOX3Q6CBSMJAORDWV243RANCNFSM6AAAAAAQZELNXM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
|
It was done by "make kernel_oldconfig" command for 5.10 and 5.15. Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com>
This patch introduces DSA support for TP-Link TL-WDR4900 v1 switch. Swconfig driver for QCA8327 switch is removed because this router is only one device which use Qualcom swconfig switch. Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com> Tested-by: Nick Hainke <vincent@systemli.org> # TP Link WDR4900 v1 (5.15)
|
Well, I don't want be the guy, who blocked this PR even though my comment was not addressed: |
|
@BKPepe that should be autosolved with me rebased this on top of master. Do you have other blocker? Think any qca8k problem was solved |
|
Thats not going to be resolved as mine PR was applied to mpc85xx target, but here it is going to be in generic config. |
|
@BKPepe oh... well I can fix it if that's the only problem |
|
Otherwise, this can go through. 👍 🤞 |
Ansuel
force-pushed
the
tl-wdr4900_v1_resurrect
branch
2 times, most recently
from
05747cf
to
63efe38
Compare
Ansuel
reviewed
Feb 20, 2023
| @@ -43,6 +43,7 @@ CONFIG_RPS=y | |||
| CONFIG_RWSEM_SPIN_ON_OWNER=y | |||
| CONFIG_SMP=y | |||
| CONFIG_SPI_GPIO=y | |||
| CONFIG_SWCONFIG=y | |||
There was a problem hiding this comment.
@BKPepe any idea why swconfig is still needed? for b43?
Because I still prefer my solution. But this particular patch could be simply rejected. |
Ansuel
force-pushed
the
tl-wdr4900_v1_resurrect
branch
2 times, most recently
from
5a5e5e2
to
bfa5e4e
Compare
fengmushu
pushed a commit
to fengmushu/openwrt
that referenced
this pull request
Nov 18, 2023
Signed-off-by: Beginner-Go <70857188+Beginner-Go@users.noreply.github.com>
|
By comparison between 22.03.5 (swconfig) and 23.05.2 (DSA), the bandwidth with an IPoE wan without flow offloading falls from 650Mb/s to 400Mb/s, and bandwidth with software flow offloading falls from 900 to 550. The bandwidth with a PPPoE wan is much poorer (260 vs 400 of ath79, seeing #10224 (comment) ), even with the walkaround in #10224 (comment) . It seems that the same performance issue preventing ath79 targets from being switched to DSA also hits this target. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch series bring up to life TP-Link TL-WDR4900 v1.
It was disabled due too big kernel. First patch is complete solution for u-boot patch (like cfe79f2) to allow boot 6MB kernels.Second patch is simple config refresh.
Last one switch from swconfig to DSA.