@merbanan I had to revert airoha_eth, and when I re-enabled NETIF_F_IP_CSUM and NETIF_F_TSO I had no TCP network traffic; several packets were being sent out of sequence or out of order, but ICMP was working normally.
@merbanan I had to revert airoha_eth, and when I re-enabled `NETIF_F_IP_CSUM` and `NETIF_F_TSO` I had no TCP network traffic; several packets were being sent out of sequence or out of order, but ICMP was working normally.
Something else I'm seeing is IPv6, it works occasionally, but it must be a problem on my end. Another thing I'm noticing in Wireshark is multiple retransmissions, ipv6 icmp working normally
Something else I'm seeing is IPv6, it works occasionally, but it must be a problem on my end. Another thing I'm noticing in Wireshark is multiple retransmissions, ipv6 icmp working normally
I was away for the weekend, I got back on Monday and didn't even have time to mess with the kernel. I haven't had much time to look at the pinctrl driver yet, I'll try it today, And I'll also try to take a look at the xPON phy code today
I was away for the weekend, I got back on Monday and didn't even have time to mess with the kernel. I haven't had much time to look at the pinctrl driver yet, I'll try it today, And I'll also try to take a look at the xPON phy code today
That's much better, but why is the upload so slow, while the download seems to reach almost GbE speeds?
I'm away from home and I don't know when I'll be back. I have the router with me, but I don't know when I'll be able to test it. Could you send me your settings so I can test them when possible?
That's much better, but why is the upload so slow, while the download seems to reach almost GbE speeds?
I'm away from home and I don't know when I'll be back. I have the router with me, but I don't know when I'll be able to test it. Could you send me your settings so I can test them when possible?
There are no settings. I just start iperf3 -s on the router and do the test. One thing that might cause the issue is that I think TSO is broken. My Realtek network card seems to ignore that the MTU is huge so it just works anyway. Maybe that is why you have issues.
Regarding low tx performance it might be this dsa tag mem move that is redundant.
There are no settings. I just start iperf3 -s on the router and do the test. One thing that might cause the issue is that I think TSO is broken. My Realtek network card seems to ignore that the MTU is huge so it just works anyway. Maybe that is why you have issues.
Regarding low tx performance it might be this dsa tag mem move that is redundant.
Anyway the ref software gets like 350mbits. So it is possible to get more but the target is to get hardware acceleration going and then it doesnt matter anyway. 250mbit is enough to handle the control traffic.
Anyway the ref software gets like 350mbits. So it is possible to get more but the target is to get hardware acceleration going and then it doesnt matter anyway. 250mbit is enough to handle the control traffic.
Anyway the ref software gets like 350mbits. So it is possible to get more but the target is to get hardware acceleration going and then it doesnt matter anyway. 250mbit is enough to handle the control traffic.
So, from what I understand, the upload speed won't exceed 350Mbps without hardware acceleration on the switch for wireless and on the switch for CPU?
I'd like to be able to test iperf3 at stock speeds to see what speed it's currently running at.
> Anyway the ref software gets like 350mbits. So it is possible to get more but the target is to get hardware acceleration going and then it doesnt matter anyway. 250mbit is enough to handle the control traffic.
So, from what I understand, the upload speed won't exceed 350Mbps without hardware acceleration on the switch for wireless and on the switch for CPU?
I'd like to be able to test iperf3 at stock speeds to see what speed it's currently running at.
> So, from what I understand, the upload speed won't exceed 350Mbps without hardware acceleration on the switch for wireless and on the switch for CPU?
>
> I'd like to be able to test iperf3 at stock speeds to see what speed it's currently running at.
Well I would expect that more engineering would be able to beat the ref driver. Top gives 70% idle.
```
Mem: 68336K used, 347468K free, 21304K shrd, 0K buff, 21304K cached
CPU: 0% usr 7% sys 0% nic 70% idle 0% io 4% irq 17% sirq
Load average: 1.33 1.13 1.03 2/115 2663
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
2661 1 root S 1240 0% 4% iperf3 -s -D
192 2 root RW 0 0% 3% [napi/qdma_eth-3]
208 2 root SW 0 0% 1% [napi/qdma_eth-0]
2663 684 root R 1208 0% 0% top
```
For example I think that the we also only use one core. At least we only trigger interrupts on one core.
```
root@OpenWrt:~# cat /proc/interrupts | grep airoha_eth
37: 875818 0 GICv3 69 Level airoha_eth.0
38: 0 0 GICv3 87 Level airoha_eth.1
39: 0 0 GICv3 70 Level airoha_eth.4
40: 0 0 GICv3 90 Level airoha_eth.5
root@OpenWrt:~# cat /proc/interrupts | grep airoha_eth
37: 889167 0 GICv3 69 Level airoha_eth.0
38: 0 0 GICv3 87 Level airoha_eth.1
39: 0 0 GICv3 70 Level airoha_eth.4
40: 0 0 GICv3 90 Level airoha_eth.5
```
So IMO there is more performance to be unlocked.
This is good, it makes it more acceptable, but in terms of internet access, when I tested with https://speed.cloudflare.com without TSO msg, I got around 200-320Mbps download and 30-60Mbps upload.
I have a 600Mbps download and 300Mbps upload connection, I don't have another Ethernet device to test the switch locally 🙃🙃
This is good, it makes it more acceptable, but in terms of internet access, when I tested with https://speed.cloudflare.com without TSO msg, I got around 200-320Mbps download and 30-60Mbps upload.
I have a 600Mbps download and 300Mbps upload connection, I don't have another Ethernet device to test the switch locally 🙃🙃
Yeah, there is something else also. If I disabled TSO in hwcaps I only get like 100mbits/s and the cpu is far from running at 100%. TSO is just hardware acceleration kicking in.
Yeah, there is something else also. If I disabled TSO in hwcaps I only get like 100mbits/s and the cpu is far from running at 100%. TSO is just hardware acceleration kicking in.
/* It seems GDM3 and GDM4 needs SPORT enabled to correctly work */if(netdev_uses_dsa(dev)||port->id>2)airoha_fe_set(qdma->eth,REG_GDM_INGRESS_CFG(port->id),GDM_STAG_EN_MASK);elseairoha_fe_clear(qdma->eth,REG_GDM_INGRESS_CFG(port->id),GDM_STAG_EN_MASK);if(airoha_is(qdma->eth,en7523))len=0xFA4;
from this
```c
if (!airoha_is(qdma->eth, en7523)) {
if (netdev_uses_dsa(dev) || port->id > 2)
airoha_fe_set(qdma->eth, REG_GDM_INGRESS_CFG(port->id),
GDM_STAG_EN_MASK);
else
airoha_fe_clear(qdma->eth, REG_GDM_INGRESS_CFG(port->id),
GDM_STAG_EN_MASK);
}
```
to this?
```c
/* It seems GDM3 and GDM4 needs SPORT enabled to correctly work */
if (netdev_uses_dsa(dev) || port->id > 2)
airoha_fe_set(qdma->eth, REG_GDM_INGRESS_CFG(port->id),
GDM_STAG_EN_MASK);
else
airoha_fe_clear(qdma->eth, REG_GDM_INGRESS_CFG(port->id),
GDM_STAG_EN_MASK);
if (airoha_is(qdma->eth, en7523))
len = 0xFA4;
```
Wouldn't it be good to add this here?
https://sirherobrine23.com.br/airoha_en7523/xPON/src/commit/0a55a19aa2e3ed2a2ddc80df6c91304aaf6fe924/xx230v/src_output/opt/bba/bba_3_0_platform/sdk/en7529/modules/private/qdma/EN7516/qdma_bmgr.c#L11-L20
I guess, I am not convinced all this is good (ie the raf code ring buffer sizes). I think all this queue stuff is over engineered from the hardware side. Some of the queues need to be large but the others will only allocate unnecessary memory.
I guess, I am not convinced all this is good (ie the raf code ring buffer sizes). I think all this queue stuff is over engineered from the hardware side. Some of the queues need to be large but the others will only allocate unnecessary memory.
Sirherobrine23 marked this conversation as resolved
Anyway, the networking part is now better then what the reference software can reach but the question is what happens with the wifi performance. We might need to tune some parameters when wifi gets in the mix.
If we ever get to adding GPON support then yes we maybe need to differentiate the sizes of the descriptor (dma) rings. If we add a printout there:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/airoha/airoha_eth.c?h=v6.19-rc1#n1956
We will notice if we ever run out of descriptors.
Anyway, the networking part is now better then what the reference software can reach but the question is what happens with the wifi performance. We might need to tune some parameters when wifi gets in the mix.
We need to get the PPE working properly, and get the NPU working with the MT76 as well. Currently, the Wi-Fi is working at the best upload and download speeds possible on the LAN, and communication between devices is normal, as I can get 1.2Gbps~880Mbps on the 5GHz wireless band
We need to get the PPE working properly, and get the NPU working with the MT76 as well. Currently, the Wi-Fi is working at the best upload and download speeds possible on the LAN, and communication between devices is normal, as I can get 1.2Gbps~880Mbps on the 5GHz wireless band
Here you should split out the mt7530 parts and send those upstream. They are ok, it is all the other stuff that will be difficult. But splitting out things into smaller parts is always the best way forward.
Here you should split out the mt7530 parts and send those upstream. They are ok, it is all the other stuff that will be difficult. But splitting out things into smaller parts is always the best way forward.
Anyway my main point is that it will take alot of time to get everything upstream and we need to start that process. Divide and conquer, take small and easy parts and then go from there. I am not sure how we should handle the difference in position of the dma descriptor members. This is something I think we till get an answer from the kernel devs. But to get there we need patch set that is easy to review. So split out the mt7530 parts and the npu stuff. The phy change should be its own patch also. From there we start chipping off airoha_eth.c into a patch set with like 90% easy stuff and 10% of the tricky parts.
Anyway my main point is that it will take alot of time to get everything upstream and we need to start that process. Divide and conquer, take small and easy parts and then go from there. I am not sure how we should handle the difference in position of the dma descriptor members. This is something I think we till get an answer from the kernel devs. But to get there we need patch set that is easy to review. So split out the mt7530 parts and the npu stuff. The phy change should be its own patch also. From there we start chipping off airoha_eth.c into a patch set with like 90% easy stuff and 10% of the tricky parts.
I'm having trouble loading initramfs due non free memory
@merbanan needs this large qdma size?
https://sirherobrine23.com.br/airoha_en7523/openwrt/src/commit/ecb65624e576fabbf612082930fbb71e8d048859/target/linux/airoha/dts/en7523.dtsi#L34-L42
I'm having trouble loading initramfs due non free memory
I am quite sure that we can reduce the buffer allocation quite a lot. Maybe you can look at the memory allocation after boot up. The NPU memory reservation can temporary be removed also.
I am quite sure that we can reduce the buffer allocation quite a lot. Maybe you can look at the memory allocation after boot up. The NPU memory reservation can temporary be removed also.
I ran the speed test on OpenWrt to check the network speed (speedtestcpp and speedtest-go installed). Between the interfaces (WAN -> LAN), at least 60 to 80% of the traffic between them is expected. Wireless traffic should be about 70% of what arrives on the WAN.
I ran the speed test on OpenWrt to check the network speed (speedtestcpp and speedtest-go installed). Between the interfaces (WAN -> LAN), at least 60 to 80% of the traffic between them is expected. Wireless traffic should be about 70% of what arrives on the WAN.
[C0]core freq at 333000000 Hz
[C0]timer_init: Timer clk is running at 125 Mhz
[C0]wcid_counter_init:0
[C0]wcid_counter_init:1
[C0][NPU] ba_node_init...
[C0]baNode_array_init
[C0]counter_init:2
[C0][NPU] queue_mutex_init...
[C0]qdma_init
[C1]core1_main
[C2]timer_isr Store Value 1e903000, val[C2]core2_main
[C3]core3_main
[C3]do npu_enq_deq_init
[c0847244]npu_pkt_buf_addr=8dff37c0
npu_wifi_offload_get_pkt_buf_addr=8dff37c0
[c0847244]npu_pkt_buf_addr=8dff37c0
[C0]wifi_mail_data->wifi_mail_private.npuPktBufAddr=8dff37c0, 8dff37c0
npu_wifi_offload_get_force_to_cpu_flag=0
isForceToCpu=0
[C0](core0_main) just return, because QDMA driver for ARM is not ready
By configuring it to be set even before the module loads, we have this:
I have some NPU-related information. Apparently the NPUs access the console port uart directly. Lines with [CX] (X=0-3) are emitted directly from the NPU cores running the loaded code.
If the following is run:
devmem 0x1ec0c194 32 0x00000001 (any non zero value).
The NPU log output to the console stops.
The NPUs seems to be RiscV 32 based. Ghidra can partially disassemble the firmware.
I have some NPU-related information. Apparently the NPUs access the console port uart directly. Lines with [CX] (X=0-3) are emitted directly from the NPU cores running the loaded code.
If the following is run:
devmem 0x1ec0c194 32 0x00000001 (any non zero value).
The NPU log output to the console stops.
The NPUs seems to be RiscV 32 based. Ghidra can partially disassemble the firmware.
I still don't know what's happening, but when airoha_eth loads, it freezes the entire system trying to access something on the NPU. I'll take a closer look at what's going on
devmem 0x1ec0c194 32 0x00000001 (any non zero value).
I still don't know what's happening, but when airoha_eth loads, it freezes the entire system trying to access something on the NPU. I'll take a closer look at what's going on
> devmem 0x1ec0c194 32 0x00000001 (any non zero value).
0 => Enable NPU UART Log
1 => Disable NPU UART log
https://sirherobrine23.com.br/airoha_en7523/kernel/src/commit/d31d8164266e508b0842fc4e1ef7363e73931dfd/drivers/net/ethernet/airoha/airoha_npu.c#L882
https://sirherobrine23.com.br/airoha_en7523/xPON/src/commit/522a0ca806cb136bb6ada912d202a3f5a66ea8e8/econet_public/arch/arm/mach-econet/ecnt_npu.c#L704-L708
@merbanan I tested it and made several changes to the NPU code. The entire system crashes when the switch is enabled, but when I disable the switch, it doesn't crash. and it always crashes at [ 17.287891] mt7530-mmio 1fb58000.switch wan: configuring for phy/internal link mode. Regarding the NPU on the mt76 for the mt7915e, I will still have to change a few things:
[ 17.074869] mt7530-mmio 1fb58000.switch lan1: configuring for phy/internal link mode
[ 17.097267] br-lan: port 1(lan1) entered blocking state
[ 17.102539] br-lan: port 1(lan1) entered disabled state
[ 17.107962] mt7530-mmio 1fb58000.switch lan1: entered allmulticast mode
[ 17.114625] airoha_eth 1fb50000.ethernet eth0: entered allmulticast mode
[ 17.121813] mt7530-mmio 1fb58000.switch lan1: entered promiscuous mode
[ 17.160546] mt7530-mmio 1fb58000.switch lan2: configuring for phy/internal link mode
[ 17.170361] br-lan: port 2(lan2) entered blocking state
[ 17.175671] br-lan: port 2(lan2) entered disabled state
[ 17.181095] mt7530-mmio 1fb58000.switch lan2: entered allmulticast mode
[ 17.188121] mt7530-mmio 1fb58000.switch lan2: entered promiscuous mode
[ 17.199949] mt7530-mmio 1fb58000.switch lan3: configuring for phy/internal link mode
[ 17.209824] br-lan: port 3(lan3) entered blocking state
[ 17.215111] br-lan: port 3(lan3) entered disabled state
[ 17.223402] mt7530-mmio 1fb58000.switch lan3: entered allmulticast mode
[ 17.230496] mt7530-mmio 1fb58000.switch lan3: entered promiscuous mode
[ 17.287891] mt7530-mmio 1fb58000.switch wan: configuring for phy/internal link mode
@merbanan I tested it and made several changes to the NPU code. The entire system crashes when the switch is enabled, but when I disable the switch, it doesn't crash. and it always crashes at `[ 17.287891] mt7530-mmio 1fb58000.switch wan: configuring for phy/internal link mode`. Regarding the NPU on the mt76 for the `mt7915e`, I will still have to change a few things:
```log
[ 17.074869] mt7530-mmio 1fb58000.switch lan1: configuring for phy/internal link mode
[ 17.097267] br-lan: port 1(lan1) entered blocking state
[ 17.102539] br-lan: port 1(lan1) entered disabled state
[ 17.107962] mt7530-mmio 1fb58000.switch lan1: entered allmulticast mode
[ 17.114625] airoha_eth 1fb50000.ethernet eth0: entered allmulticast mode
[ 17.121813] mt7530-mmio 1fb58000.switch lan1: entered promiscuous mode
[ 17.160546] mt7530-mmio 1fb58000.switch lan2: configuring for phy/internal link mode
[ 17.170361] br-lan: port 2(lan2) entered blocking state
[ 17.175671] br-lan: port 2(lan2) entered disabled state
[ 17.181095] mt7530-mmio 1fb58000.switch lan2: entered allmulticast mode
[ 17.188121] mt7530-mmio 1fb58000.switch lan2: entered promiscuous mode
[ 17.199949] mt7530-mmio 1fb58000.switch lan3: configuring for phy/internal link mode
[ 17.209824] br-lan: port 3(lan3) entered blocking state
[ 17.215111] br-lan: port 3(lan3) entered disabled state
[ 17.223402] mt7530-mmio 1fb58000.switch lan3: entered allmulticast mode
[ 17.230496] mt7530-mmio 1fb58000.switch lan3: entered promiscuous mode
[ 17.287891] mt7530-mmio 1fb58000.switch wan: configuring for phy/internal link mode
```
I ran tests today, and I'm still having problems with the switch. If I boot with only one cable connected to LAN3, I get traffic, but if I use more than one cable, it doesn't detect the connection on any of the switch ports
I ran tests today, and I'm still having problems with the switch. If I boot with only one cable connected to LAN3, I get traffic, but if I use more than one cable, it doesn't detect the connection on any of the switch ports
What do you mean? I don't understand. The interrupt is on the eth:
https://sirherobrine23.com.br/airoha_en7523/openwrt/src/commit/2b693a6bf884c5d2205c496d38c126d73af9e86e/target/linux/airoha/dts/en7523.dtsi#L639-L640
I am unsure if this node will resolve to the correct interrupt controller (MT7530). If cat /proc/interrupts show that the mt7530 interrupts are allocated to the phy ports then everything is fine. If not then the interrupt parent is needed.
When the port phy emits an interrupt is travels to the the GIC via pin 31, then the mt7530 interrupt handler is run to handle the event.
The MT7530 switch is connected to the GIC interrupt controller pin 31 (not 37).
The 1G switch port phys are connected to the MT7530 switch interrupt controller.
```
compatible = "ethernet-phy-ieee802.3-c22";
reg = <9>;
interrupts = <1>;
phy-mode = "internal";
pinctrl-0 = <&gswp1_led0_pins>;
pinctrl-names = "gbe-led";
airoha,scu = <&scuclk>;
```
I am unsure if this node will resolve to the correct interrupt controller (MT7530). If cat /proc/interrupts show that the mt7530 interrupts are allocated to the phy ports then everything is fine. If not then the interrupt parent is needed.
When the port phy emits an interrupt is travels to the the GIC via pin 31, then the mt7530 interrupt handler is run to handle the event.
@merbanan i had to do a rollback to commit 470ae207b6 ... c3f3209d67 of the ethernet driver to boot normaly but ethernet driver no working in en7529 SoC's, on en7562 working but hw offload stop working with TCP packet with hw offload without rollback commit
EN7529CT Bootlog with rollback commit
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 6.12.80 (sirherobrine23@matheus-note) (arm-openwrt-linux-muslgnueabi-gcc (OpenWrt GCC 14.3.0 r33479-5f7ec5c8b9) 14.3.0, GNU ld (GNU Binutils) 2.44) #0 SMP Tue Apr 28 23:05:10 2026
[ 0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt: Machine model: TP-Link xx230v/xx530v v1
[ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
[ 0.000000] earlycon: ns16550 at MMIO32 0x1fbf0000 (options '115200n8')
[ 0.000000] printk: legacy bootconsole [ns16550] enabled
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] Zone ranges:
[ 0.000000] Normal [mem 0x0000000080200000-0x000000009fffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000080200000-0x0000000083ffffff]
[ 0.000000] node 0: [mem 0x0000000084000000-0x00000000844fffff]
[ 0.000000] node 0: [mem 0x0000000084500000-0x00000000848fffff]
[ 0.000000] node 0: [mem 0x0000000084900000-0x00000000862fffff]
[ 0.000000] node 0: [mem 0x0000000086300000-0x000000009fffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x000000009fffffff]
[ 0.000000] On node 0, zone Normal: 512 pages in unavailable ranges
[ 0.000000] OF: reserved mem: 0x80000000..0x8003ffff (256 KiB) nomap non-reusable atf@80000000
[ 0.000000] OF: reserved mem: 0x84000000..0x840fffff (1024 KiB) nomap non-reusable npu_binary@84000000
[ 0.000000] OF: reserved mem: 0x84100000..0x844fffff (4096 KiB) nomap non-reusable qdma0-buf@84100000
[ 0.000000] OF: reserved mem: 0x84900000..0x84cfffff (4096 KiB) nomap non-reusable qdma1-buf@84900000
[ 0.000000] OF: reserved mem: 0x84d00000..0x862fffff (22528 KiB) nomap non-reusable npu-pkt@84d00000
[ 0.000000] psci: probing for conduit method from DT.
[ 0.000000] psci: PSCIv1.1 detected in firmware.
[ 0.000000] psci: Using standard PSCI v0.2 function IDs
[ 0.000000] psci: MIGRATE_INFO_TYPE not supported.
[ 0.000000] psci: SMC Calling Convention v1.1
[ 0.000000] percpu: Embedded 14 pages/cpu s25228 r8192 d23924 u57344
[ 0.000000] Kernel command line: console=ttyS0,115200 earlycon ubi.block=0,firmware root=/dev/ubiblock0_3 rootwait
[ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes, linear)
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 130560
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] Tracing variant of Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[ 0.000000] RCU Tasks Trace: Setting shift to 1 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=2.
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] GICv3: 256 SPIs implemented
[ 0.000000] GICv3: 0 Extended SPIs implemented
[ 0.000000] GICv3: GICv3 features: 16 PPIs
[ 0.000000] GICv3: GICD_CTRL.DS=0, SCR_EL3.FIQ=0
[ 0.000000] GICv3: CPU0: found redistributor 0 region 0:0x09080000
[ 0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
[ 0.000000] arch_timer: cp15 timer(s) running at 25.00MHz (virt).
[ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x5c40939b5, max_idle_ns: 440795202646 ns
[ 0.000001] sched_clock: 56 bits at 25MHz, resolution 40ns, wraps every 4398046511100ns
[ 0.008800] Switching to timer-based delay loop, resolution 40ns
[ 0.015555] Calibrating delay loop (skipped), value calculated using timer frequency.. 50.00 BogoMIPS (lpj=250000)
[ 0.026940] CPU: Testing write buffer coherency: ok
[ 0.032332] pid_max: default: 32768 minimum: 301
[ 0.044103] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.052155] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.063694] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.070958] Setting up static identity map for 0x80300000 - 0x80300060
[ 0.078317] rcu: Hierarchical SRCU implementation.
[ 0.083581] rcu: Max phase no-delay instances is 1000.
[ 0.089604] Timer migration: 1 hierarchy levels; 8 children per group; 1 crossnode level
[ 0.098805] smp: Bringing up secondary CPUs ...
[ 0.104498] GICv3: CPU1: found redistributor 1 region 0:0x090a0000
[ 0.104552] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.104702] smp: Brought up 1 node, 2 CPUs
[ 0.122228] SMP: Total of 2 processors activated (100.00 BogoMIPS).
[ 0.129127] CPU: All CPU(s) started in SVC mode.
[ 0.134685] Memory: 452596K/522240K available (7751K kernel code, 622K rwdata, 2020K rodata, 20480K init, 217K bss, 68512K reserved, 0K cma-reserved)
[ 0.153744] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.164619] futex hash table entries: 512 (order: 3, 32768 bytes, linear)
[ 0.175512] pinctrl core: initialized pinctrl subsystem
[ 0.183318] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[ 0.190151] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.198481] thermal_sys: Registered thermal governor 'step_wise'
[ 0.198564] cpuidle: using governor menu
[ 0.212040] /pcie@1fa91000: Fixed dependency cycle(s) with /pcie@1fa91000/interrupt-controller
[ 0.221926] /pcie@1fa92000: Fixed dependency cycle(s) with /pcie@1fa92000/interrupt-controller
[ 0.240580] SCSI subsystem initialized
[ 0.244967] usbcore: registered new interface driver usbfs
[ 0.251039] usbcore: registered new interface driver hub
[ 0.256949] usbcore: registered new device driver usb
[ 0.263953] clocksource: Switched to clocksource arch_sys_counter
[ 0.276819] NET: Registered PF_INET protocol family
[ 0.282351] IP idents hash table entries: 8192 (order: 4, 65536 bytes, linear)
[ 0.291273] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear)
[ 0.300517] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 0.309048] TCP established hash table entries: 4096 (order: 2, 16384 bytes, linear)
[ 0.317603] TCP bind hash table entries: 4096 (order: 4, 65536 bytes, linear)
[ 0.325548] TCP: Hash tables configured (established 4096 bind 4096)
[ 0.332925] MPTCP token hash table entries: 512 (order: 1, 8192 bytes, linear)
[ 0.341137] UDP hash table entries: 256 (order: 1, 8192 bytes, linear)
[ 0.348362] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes, linear)
[ 0.356468] NET: Registered PF_UNIX/PF_LOCAL protocol family
[ 0.362725] PCI: CLS 0 bytes, default 64
[ 0.368569] workingset: timestamp_bits=14 max_order=17 bucket_order=3
[ 0.377345] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 0.383766] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
[ 0.721790] mtk-pcie 1fa91000.pcie: host bridge /pcie@1fa91000 ranges:
[ 0.729111] mtk-pcie 1fa91000.pcie: MEM 0x0020000000..0x0021ffffff -> 0x0020000000
[ 1.333981] mtk-pcie 1fa91000.pcie: Port0 link down
[ 1.339620] mtk-pcie 1fa91000.pcie: PCI host bridge to bus 0000:00
[ 1.346484] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 1.352547] pci_bus 0000:00: root bus resource [mem 0x20000000-0x21ffffff]
[ 1.361064] PCI: bus0: Fast back to back transfers enabled
[ 1.367158] pci_bus 0000:00: resource 4 [mem 0x20000000-0x21ffffff]
[ 1.374375] mtk-pcie 1fa92000.pcie: host bridge /pcie@1fa92000 ranges:
[ 1.381573] mtk-pcie 1fa92000.pcie: MEM 0x0022000000..0x0023ffffff -> 0x0022000000
[ 1.912425] mtk-pcie 1fa92000.pcie: PCI host bridge to bus 0001:00
[ 1.919287] pci_bus 0001:00: root bus resource [bus 00-ff]
[ 1.925358] pci_bus 0001:00: root bus resource [mem 0x22000000-0x23ffffff]
[ 1.933218] pci 0001:00:01.0: [14c3:0811] type 01 class 0x060400 PCIe Root Port
[ 1.941489] pci 0001:00:01.0: BAR 0: can't handle BAR larger than 4GB (size 0x200000000)
[ 1.950417] pci 0001:00:01.0: BAR 0 [mem size 0x00000001 64bit pref disabled]
[ 1.958359] pci 0001:00:01.0: PCI bridge to [bus 00]
[ 1.963885] pci 0001:00:01.0: bridge window [mem 0x00000000-0x000fffff]
[ 1.973502] PCI: bus0: Fast back to back transfers disabled
[ 1.979698] pci 0001:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 1.989225] pci 0001:01:00.0: [14c3:7915] type 00 class 0x000280 PCIe Endpoint
[ 1.997399] pci 0001:01:00.0: BAR 0 [mem 0x00000000-0x000fffff 64bit pref]
[ 2.005086] pci 0001:01:00.0: BAR 2 [mem 0x00000000-0x00003fff 64bit pref]
[ 2.012745] pci 0001:01:00.0: BAR 4 [mem 0x00000000-0x00000fff 64bit pref]
[ 2.021096] pci 0001:01:00.0: supports D1 D2
[ 2.025825] pci 0001:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 2.033444] pci 0001:01:00.0: 2.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x1 link at 0001:00:01.0 (capable of 4.000 Gb/s with 5.0 GT/s PCIe x1 link)
[ 2.050524] PCI: bus1: Fast back to back transfers disabled
[ 2.056700] pci_bus 0001:01: busn_res: [bus 01-ff] end is updated to 01
[ 2.064040] pci 0001:00:01.0: bridge window [mem 0x22000000-0x221fffff]: assigned
[ 2.072265] pci 0001:00:01.0: BAR 0 [mem 0x22200000 64bit pref disabled]: assigned
[ 2.080713] pci 0001:00:01.0: BAR 0: error updating (0x2220000c != 0x0000000c)
[ 2.088738] pci 0001:01:00.0: BAR 0 [mem 0x22000000-0x220fffff 64bit pref]: assigned
[ 2.097388] pci 0001:01:00.0: BAR 2 [mem 0x22100000-0x22103fff 64bit pref]: assigned
[ 2.106038] pci 0001:01:00.0: BAR 4 [mem 0x22104000-0x22104fff 64bit pref]: assigned
[ 2.114664] pci 0001:00:01.0: PCI bridge to [bus 01]
[ 2.120152] pci 0001:00:01.0: bridge window [mem 0x22000000-0x221fffff]
[ 2.127709] pci_bus 0001:00: resource 4 [mem 0x22000000-0x23ffffff]
[ 2.134626] pci_bus 0001:01: resource 1 [mem 0x22000000-0x221fffff]
[ 2.142210] pcieport 0001:00:01.0: enabling device (0140 -> 0142)
[ 2.149766] pcieport 0001:00:01.0: PME: Signaling with IRQ 31
[ 2.157934] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[ 2.165965] printk: legacy console [ttyS0] disabled
[ 2.171730] 1fbf0000.serial: ttyS0 at MMIO 0x1fbf0000 (irq = 32, base_baud = 115200) is a 16550
[ 2.181383] printk: legacy console [ttyS0] enabled
[ 2.181383] printk: legacy console [ttyS0] enabled
[ 2.191468] printk: legacy bootconsole [ns16550] disabled
[ 2.191468] printk: legacy bootconsole [ns16550] disabled
[ 2.224695] random: crng init done
[ 2.229255] spi-nand spi0.0: ESMT SPI NAND was found.
[ 2.234395] spi-nand spi0.0: 128 MiB, block size: 128 KiB, page size: 2048, OOB size: 64
[ 18.768180] 2 fixed-partitions partitions found on MTD device spi0.0
[ 18.774844] Creating 2 MTD partitions on "spi0.0":
[ 18.779653] 0x000000000000-0x000000100000 : "u-boot"
[ 18.787888] 0x000000100000-0x000007e60000 : "ubi"
[ 19.061035] ubi0: attaching mtd1
[ 19.708298] ubi0: scanning is finished
[ 19.720178] ubi0 warning: ubi_eba_init: cannot reserve enough PEBs for bad PEB handling, reserved 7, need 20
[ 19.731391] ubi0: attached mtd1 (name "ubi", size 125 MiB)
[ 19.736939] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[ 19.743825] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
[ 19.750629] ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
[ 19.757608] ubi0: good PEBs: 1003, bad PEBs: 0, corrupted PEBs: 0
[ 19.763703] ubi0: user volume: 4, internal volumes: 1, max. volumes count: 128
[ 19.770941] ubi0: max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 0
[ 19.779303] ubi0: available PEBs: 0, total reserved PEBs: 1003, PEBs reserved for bad PEB handling: 7
[ 19.788550] ubi0: background thread "ubi_bgt0d" started, PID 141
[ 19.789111] block ubiblock0_3: created from ubi0:3(firmware)
[ 19.884664] airoha-npu 1e900000.npu: L2C sram: 0x00, FPGA Stage: 0
[C0]core freq at 333000000 Hz
[C0]timer_init: Timer clk is running at 125 Mhz
[C0]npu_gre_tunnel_tx_header_init L15 gre_tx_head_addr[0]=0x8400351c
[C0]npu_gre_tunnel_tx_header_init L15 gre_tx_head_addr[1]=0x84003544
[C0][NPU] ba_node_init...
[C0]baNode_array_init
[C0]counter_init:2
[C0][NPU] queue_mutex_init...
[C1]core1_main
[C2]timer_isr Store Value 1e903000, val[C2]core2_main
[C2]do npu_enq_deq_init
[C3]core3_main
[C3]core3_main for npu tunnel offload v21
[C3]npu bridge buf init sucess
[ 20.843941] airoha-npu 1e900000.npu: wlan get msg: id 10, core 0, body size 4
[ 20.851102] airoha-npu 1e900000.npu: NPU not support get version
[ 20.857463] xhci-mtk 1fab0000.usb: supply vbus not found, using dummy regulator
[ 20.865033] xhci-mtk 1fab0000.usb: supply vusb33 not found, using dummy regulator
[ 20.886460] airoha-usb-phy 1fad0000.phy: Frequency not detected, using default SR calibration.
[ 20.899662] xhci-mtk 1fab0000.usb: xHCI Host Controller
[ 20.904949] xhci-mtk 1fab0000.usb: new USB bus registered, assigned bus number 1
[ 20.916312] xhci-mtk 1fab0000.usb: hcc params 0x01400f98 hci version 0x110 quirks 0x0000000000200010
[ 20.925527] xhci-mtk 1fab0000.usb: irq 45, io mem 0x1fab0000
[ 20.931347] xhci-mtk 1fab0000.usb: xHCI Host Controller
[ 20.936620] xhci-mtk 1fab0000.usb: new USB bus registered, assigned bus number 2
[ 20.944043] xhci-mtk 1fab0000.usb: Host supports USB 3.2 Enhanced SuperSpeed
[ 20.951793] hub 1-0:1.0: USB hub found
[ 20.955684] hub 1-0:1.0: 2 ports detected
[ 20.960393] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[ 20.969199] hub 2-0:1.0: USB hub found
[ 20.973109] hub 2-0:1.0: 1 port detected
[ 20.977884] i2c-mt7621 1fbf8000.i2c0: clock 100 kHz
[ 20.995653] mtk-eip93 1fb70000.crypto: EIP93:3:0:1,PE(0xfe007:0x41710041)
[ 21.002925] NET: Registered PF_INET6 protocol family
[ 21.009062] Segment Routing with IPv6
[ 21.012767] In-situ OAM (IOAM) with IPv6
[ 21.016824] NET: Registered PF_PACKET protocol family
[ 21.022150] 8021q: 802.1Q VLAN Support v1.8
[ 21.026539] Registering SWP/SWPB emulation handler
[ 21.215024] clk: Disabling unused clocks
[ 21.218974] PM: genpd: Disabling unused power domains
[ 21.244918] Freeing unused kernel image (initmem) memory: 20480K
[ 21.251237] Run /init as init process
[ 21.916657] init: Console is alive
[ 21.920289] init: - watchdog -
[ 21.938050] kmodloader: loading kernel modules from /etc/modules-boot.d/*
[ 21.953765] gpio_button_hotplug: loading out-of-tree module taints kernel.
[ 21.979281] usbcore: registered new interface driver usb-storage
[ 21.985920] kmodloader: done loading kernel modules from /etc/modules-boot.d/*
[ 21.995869] init: - preinit -
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
[ 23.359330] procd: - early -
[ 23.362360] procd: - watchdog -
[ 23.895693] procd: - watchdog -
[ 23.899376] procd: - ubus -
[ 23.955725] procd: - init -
Please press Enter to activate this console.
[ 24.345582] kmodloader: loading kernel modules from /etc/modules.d/*
[ 24.681741] i2c_dev: i2c /dev entries driver
[ 24.705627] GACT probability on
[ 24.710193] Mirror/redirect action on
[ 24.746425] u32 classifier
[ 24.749155] input device check on
[ 24.752817] Actions configured
[ 24.784049] ntfs3: Enabled Linux POSIX ACLs support
[ 24.806662] Loading modules backported from Linux version v6.18.7-0-g5dfbc5357
[ 24.813903] Backport generated by backports.git c8a37ce
[ 24.912180] usbcore: registered new interface driver ums-alauda
[ 24.936525] usbcore: registered new interface driver ums-cypress
[ 24.944496] usbcore: registered new interface driver ums-datafab
[ 24.952214] usbcore: registered new interface driver ums-freecom
[ 24.967762] usbcore: registered new interface driver ums-isd200
[ 24.975748] usbcore: registered new interface driver ums-jumpshot
[ 24.983610] usbcore: registered new interface driver ums-karma
[ 24.991614] usbcore: registered new interface driver ums-sddr09
[ 24.999547] usbcore: registered new interface driver ums-sddr55
[ 25.007534] usbcore: registered new interface driver ums-usbat
[ 25.051742] xt_time: kernel timezone is -0000
[ 25.074920] urngd: v1.0.2 started.
[ 25.283105] mt7915e 0001:01:00.0: enabling device (0140 -> 0142)
[ 25.495484] mt7915e 0001:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20240429200716a
[ 25.522466] mt7915e 0001:01:00.0: WM Firmware Version: ____000000, Build Time: 20240429200752
[ 25.572088] mt7915e 0001:01:00.0: WA Firmware Version: DEV_000000, Build Time: 20240429200812
[ 25.780639] mt7915e 0001:01:00.0: eeprom load fail, use default bin
[ 25.787037] mt7915e 0001:01:00.0: Direct firmware load for mediatek/mt7915_eeprom_dbdc.bin failed with error -2
[ 25.797176] mt7915e 0001:01:00.0: Falling back to sysfs fallback for: mediatek/mt7915_eeprom_dbdc.bin
[ 25.818183] mt7915e 0001:01:00.0: probe with driver mt7915e failed with error -12
[ 25.853431] PPP generic driver version 2.4.2
[ 25.859787] NET: Registered PF_PPPOX protocol family
[ 25.876058] wireguard: WireGuard 1.0.0 loaded. See www.wireguard.com for information.
[ 25.883904] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
[ 25.907625] kmodloader: done loading kernel modules from /etc/modules.d/*
[ 39.495469] platform 1fb58000.switch: deferred probe pending: (reason unknown)
[ 39.502717] platform 1fb50000.ethernet: deferred probe pending: (reason unknown)
@merbanan i had to do a rollback to commit 470ae207b6bb32cdce2899cc92b64c75f5e9da28 ... c3f3209d67a425ed98c69f19b7d06c239077d09a of the ethernet driver to boot normaly but ethernet driver no working in en7529 SoC's, on en7562 working but hw offload stop working with TCP packet with hw offload without rollback commit
<details>
<summary>EN7529CT Bootlog with rollback commit</summary>
```
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 6.12.80 (sirherobrine23@matheus-note) (arm-openwrt-linux-muslgnueabi-gcc (OpenWrt GCC 14.3.0 r33479-5f7ec5c8b9) 14.3.0, GNU ld (GNU Binutils) 2.44) #0 SMP Tue Apr 28 23:05:10 2026
[ 0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt: Machine model: TP-Link xx230v/xx530v v1
[ 0.000000] OF: fdt: Ignoring memory range 0x80000000 - 0x80200000
[ 0.000000] earlycon: ns16550 at MMIO32 0x1fbf0000 (options '115200n8')
[ 0.000000] printk: legacy bootconsole [ns16550] enabled
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] Zone ranges:
[ 0.000000] Normal [mem 0x0000000080200000-0x000000009fffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000080200000-0x0000000083ffffff]
[ 0.000000] node 0: [mem 0x0000000084000000-0x00000000844fffff]
[ 0.000000] node 0: [mem 0x0000000084500000-0x00000000848fffff]
[ 0.000000] node 0: [mem 0x0000000084900000-0x00000000862fffff]
[ 0.000000] node 0: [mem 0x0000000086300000-0x000000009fffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000080200000-0x000000009fffffff]
[ 0.000000] On node 0, zone Normal: 512 pages in unavailable ranges
[ 0.000000] OF: reserved mem: 0x80000000..0x8003ffff (256 KiB) nomap non-reusable atf@80000000
[ 0.000000] OF: reserved mem: 0x84000000..0x840fffff (1024 KiB) nomap non-reusable npu_binary@84000000
[ 0.000000] OF: reserved mem: 0x84100000..0x844fffff (4096 KiB) nomap non-reusable qdma0-buf@84100000
[ 0.000000] OF: reserved mem: 0x84900000..0x84cfffff (4096 KiB) nomap non-reusable qdma1-buf@84900000
[ 0.000000] OF: reserved mem: 0x84d00000..0x862fffff (22528 KiB) nomap non-reusable npu-pkt@84d00000
[ 0.000000] psci: probing for conduit method from DT.
[ 0.000000] psci: PSCIv1.1 detected in firmware.
[ 0.000000] psci: Using standard PSCI v0.2 function IDs
[ 0.000000] psci: MIGRATE_INFO_TYPE not supported.
[ 0.000000] psci: SMC Calling Convention v1.1
[ 0.000000] percpu: Embedded 14 pages/cpu s25228 r8192 d23924 u57344
[ 0.000000] Kernel command line: console=ttyS0,115200 earlycon ubi.block=0,firmware root=/dev/ubiblock0_3 rootwait
[ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes, linear)
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 130560
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] Tracing variant of Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[ 0.000000] RCU Tasks Trace: Setting shift to 1 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=2.
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] GICv3: 256 SPIs implemented
[ 0.000000] GICv3: 0 Extended SPIs implemented
[ 0.000000] GICv3: GICv3 features: 16 PPIs
[ 0.000000] GICv3: GICD_CTRL.DS=0, SCR_EL3.FIQ=0
[ 0.000000] GICv3: CPU0: found redistributor 0 region 0:0x09080000
[ 0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
[ 0.000000] arch_timer: cp15 timer(s) running at 25.00MHz (virt).
[ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x5c40939b5, max_idle_ns: 440795202646 ns
[ 0.000001] sched_clock: 56 bits at 25MHz, resolution 40ns, wraps every 4398046511100ns
[ 0.008800] Switching to timer-based delay loop, resolution 40ns
[ 0.015555] Calibrating delay loop (skipped), value calculated using timer frequency.. 50.00 BogoMIPS (lpj=250000)
[ 0.026940] CPU: Testing write buffer coherency: ok
[ 0.032332] pid_max: default: 32768 minimum: 301
[ 0.044103] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.052155] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.063694] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.070958] Setting up static identity map for 0x80300000 - 0x80300060
[ 0.078317] rcu: Hierarchical SRCU implementation.
[ 0.083581] rcu: Max phase no-delay instances is 1000.
[ 0.089604] Timer migration: 1 hierarchy levels; 8 children per group; 1 crossnode level
[ 0.098805] smp: Bringing up secondary CPUs ...
[ 0.104498] GICv3: CPU1: found redistributor 1 region 0:0x090a0000
[ 0.104552] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.104702] smp: Brought up 1 node, 2 CPUs
[ 0.122228] SMP: Total of 2 processors activated (100.00 BogoMIPS).
[ 0.129127] CPU: All CPU(s) started in SVC mode.
[ 0.134685] Memory: 452596K/522240K available (7751K kernel code, 622K rwdata, 2020K rodata, 20480K init, 217K bss, 68512K reserved, 0K cma-reserved)
[ 0.153744] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.164619] futex hash table entries: 512 (order: 3, 32768 bytes, linear)
[ 0.175512] pinctrl core: initialized pinctrl subsystem
[ 0.183318] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[ 0.190151] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.198481] thermal_sys: Registered thermal governor 'step_wise'
[ 0.198564] cpuidle: using governor menu
[ 0.212040] /pcie@1fa91000: Fixed dependency cycle(s) with /pcie@1fa91000/interrupt-controller
[ 0.221926] /pcie@1fa92000: Fixed dependency cycle(s) with /pcie@1fa92000/interrupt-controller
[ 0.240580] SCSI subsystem initialized
[ 0.244967] usbcore: registered new interface driver usbfs
[ 0.251039] usbcore: registered new interface driver hub
[ 0.256949] usbcore: registered new device driver usb
[ 0.263953] clocksource: Switched to clocksource arch_sys_counter
[ 0.276819] NET: Registered PF_INET protocol family
[ 0.282351] IP idents hash table entries: 8192 (order: 4, 65536 bytes, linear)
[ 0.291273] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear)
[ 0.300517] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 0.309048] TCP established hash table entries: 4096 (order: 2, 16384 bytes, linear)
[ 0.317603] TCP bind hash table entries: 4096 (order: 4, 65536 bytes, linear)
[ 0.325548] TCP: Hash tables configured (established 4096 bind 4096)
[ 0.332925] MPTCP token hash table entries: 512 (order: 1, 8192 bytes, linear)
[ 0.341137] UDP hash table entries: 256 (order: 1, 8192 bytes, linear)
[ 0.348362] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes, linear)
[ 0.356468] NET: Registered PF_UNIX/PF_LOCAL protocol family
[ 0.362725] PCI: CLS 0 bytes, default 64
[ 0.368569] workingset: timestamp_bits=14 max_order=17 bucket_order=3
[ 0.377345] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 0.383766] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
[ 0.721790] mtk-pcie 1fa91000.pcie: host bridge /pcie@1fa91000 ranges:
[ 0.729111] mtk-pcie 1fa91000.pcie: MEM 0x0020000000..0x0021ffffff -> 0x0020000000
[ 1.333981] mtk-pcie 1fa91000.pcie: Port0 link down
[ 1.339620] mtk-pcie 1fa91000.pcie: PCI host bridge to bus 0000:00
[ 1.346484] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 1.352547] pci_bus 0000:00: root bus resource [mem 0x20000000-0x21ffffff]
[ 1.361064] PCI: bus0: Fast back to back transfers enabled
[ 1.367158] pci_bus 0000:00: resource 4 [mem 0x20000000-0x21ffffff]
[ 1.374375] mtk-pcie 1fa92000.pcie: host bridge /pcie@1fa92000 ranges:
[ 1.381573] mtk-pcie 1fa92000.pcie: MEM 0x0022000000..0x0023ffffff -> 0x0022000000
[ 1.912425] mtk-pcie 1fa92000.pcie: PCI host bridge to bus 0001:00
[ 1.919287] pci_bus 0001:00: root bus resource [bus 00-ff]
[ 1.925358] pci_bus 0001:00: root bus resource [mem 0x22000000-0x23ffffff]
[ 1.933218] pci 0001:00:01.0: [14c3:0811] type 01 class 0x060400 PCIe Root Port
[ 1.941489] pci 0001:00:01.0: BAR 0: can't handle BAR larger than 4GB (size 0x200000000)
[ 1.950417] pci 0001:00:01.0: BAR 0 [mem size 0x00000001 64bit pref disabled]
[ 1.958359] pci 0001:00:01.0: PCI bridge to [bus 00]
[ 1.963885] pci 0001:00:01.0: bridge window [mem 0x00000000-0x000fffff]
[ 1.973502] PCI: bus0: Fast back to back transfers disabled
[ 1.979698] pci 0001:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 1.989225] pci 0001:01:00.0: [14c3:7915] type 00 class 0x000280 PCIe Endpoint
[ 1.997399] pci 0001:01:00.0: BAR 0 [mem 0x00000000-0x000fffff 64bit pref]
[ 2.005086] pci 0001:01:00.0: BAR 2 [mem 0x00000000-0x00003fff 64bit pref]
[ 2.012745] pci 0001:01:00.0: BAR 4 [mem 0x00000000-0x00000fff 64bit pref]
[ 2.021096] pci 0001:01:00.0: supports D1 D2
[ 2.025825] pci 0001:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 2.033444] pci 0001:01:00.0: 2.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x1 link at 0001:00:01.0 (capable of 4.000 Gb/s with 5.0 GT/s PCIe x1 link)
[ 2.050524] PCI: bus1: Fast back to back transfers disabled
[ 2.056700] pci_bus 0001:01: busn_res: [bus 01-ff] end is updated to 01
[ 2.064040] pci 0001:00:01.0: bridge window [mem 0x22000000-0x221fffff]: assigned
[ 2.072265] pci 0001:00:01.0: BAR 0 [mem 0x22200000 64bit pref disabled]: assigned
[ 2.080713] pci 0001:00:01.0: BAR 0: error updating (0x2220000c != 0x0000000c)
[ 2.088738] pci 0001:01:00.0: BAR 0 [mem 0x22000000-0x220fffff 64bit pref]: assigned
[ 2.097388] pci 0001:01:00.0: BAR 2 [mem 0x22100000-0x22103fff 64bit pref]: assigned
[ 2.106038] pci 0001:01:00.0: BAR 4 [mem 0x22104000-0x22104fff 64bit pref]: assigned
[ 2.114664] pci 0001:00:01.0: PCI bridge to [bus 01]
[ 2.120152] pci 0001:00:01.0: bridge window [mem 0x22000000-0x221fffff]
[ 2.127709] pci_bus 0001:00: resource 4 [mem 0x22000000-0x23ffffff]
[ 2.134626] pci_bus 0001:01: resource 1 [mem 0x22000000-0x221fffff]
[ 2.142210] pcieport 0001:00:01.0: enabling device (0140 -> 0142)
[ 2.149766] pcieport 0001:00:01.0: PME: Signaling with IRQ 31
[ 2.157934] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[ 2.165965] printk: legacy console [ttyS0] disabled
[ 2.171730] 1fbf0000.serial: ttyS0 at MMIO 0x1fbf0000 (irq = 32, base_baud = 115200) is a 16550
[ 2.181383] printk: legacy console [ttyS0] enabled
[ 2.181383] printk: legacy console [ttyS0] enabled
[ 2.191468] printk: legacy bootconsole [ns16550] disabled
[ 2.191468] printk: legacy bootconsole [ns16550] disabled
[ 2.224695] random: crng init done
[ 2.229255] spi-nand spi0.0: ESMT SPI NAND was found.
[ 2.234395] spi-nand spi0.0: 128 MiB, block size: 128 KiB, page size: 2048, OOB size: 64
[ 18.768180] 2 fixed-partitions partitions found on MTD device spi0.0
[ 18.774844] Creating 2 MTD partitions on "spi0.0":
[ 18.779653] 0x000000000000-0x000000100000 : "u-boot"
[ 18.787888] 0x000000100000-0x000007e60000 : "ubi"
[ 19.061035] ubi0: attaching mtd1
[ 19.708298] ubi0: scanning is finished
[ 19.720178] ubi0 warning: ubi_eba_init: cannot reserve enough PEBs for bad PEB handling, reserved 7, need 20
[ 19.731391] ubi0: attached mtd1 (name "ubi", size 125 MiB)
[ 19.736939] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[ 19.743825] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
[ 19.750629] ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
[ 19.757608] ubi0: good PEBs: 1003, bad PEBs: 0, corrupted PEBs: 0
[ 19.763703] ubi0: user volume: 4, internal volumes: 1, max. volumes count: 128
[ 19.770941] ubi0: max/mean erase counter: 2/1, WL threshold: 4096, image sequence number: 0
[ 19.779303] ubi0: available PEBs: 0, total reserved PEBs: 1003, PEBs reserved for bad PEB handling: 7
[ 19.788550] ubi0: background thread "ubi_bgt0d" started, PID 141
[ 19.789111] block ubiblock0_3: created from ubi0:3(firmware)
[ 19.884664] airoha-npu 1e900000.npu: L2C sram: 0x00, FPGA Stage: 0
[C0]core freq at 333000000 Hz
[C0]timer_init: Timer clk is running at 125 Mhz
[C0]npu_gre_tunnel_tx_header_init L15 gre_tx_head_addr[0]=0x8400351c
[C0]npu_gre_tunnel_tx_header_init L15 gre_tx_head_addr[1]=0x84003544
[C0][NPU] ba_node_init...
[C0]baNode_array_init
[C0]counter_init:2
[C0][NPU] queue_mutex_init...
[C1]core1_main
[C2]timer_isr Store Value 1e903000, val[C2]core2_main
[C2]do npu_enq_deq_init
[C3]core3_main
[C3]core3_main for npu tunnel offload v21
[C3]npu bridge buf init sucess
[ 20.843941] airoha-npu 1e900000.npu: wlan get msg: id 10, core 0, body size 4
[ 20.851102] airoha-npu 1e900000.npu: NPU not support get version
[ 20.857463] xhci-mtk 1fab0000.usb: supply vbus not found, using dummy regulator
[ 20.865033] xhci-mtk 1fab0000.usb: supply vusb33 not found, using dummy regulator
[ 20.886460] airoha-usb-phy 1fad0000.phy: Frequency not detected, using default SR calibration.
[ 20.899662] xhci-mtk 1fab0000.usb: xHCI Host Controller
[ 20.904949] xhci-mtk 1fab0000.usb: new USB bus registered, assigned bus number 1
[ 20.916312] xhci-mtk 1fab0000.usb: hcc params 0x01400f98 hci version 0x110 quirks 0x0000000000200010
[ 20.925527] xhci-mtk 1fab0000.usb: irq 45, io mem 0x1fab0000
[ 20.931347] xhci-mtk 1fab0000.usb: xHCI Host Controller
[ 20.936620] xhci-mtk 1fab0000.usb: new USB bus registered, assigned bus number 2
[ 20.944043] xhci-mtk 1fab0000.usb: Host supports USB 3.2 Enhanced SuperSpeed
[ 20.951793] hub 1-0:1.0: USB hub found
[ 20.955684] hub 1-0:1.0: 2 ports detected
[ 20.960393] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[ 20.969199] hub 2-0:1.0: USB hub found
[ 20.973109] hub 2-0:1.0: 1 port detected
[ 20.977884] i2c-mt7621 1fbf8000.i2c0: clock 100 kHz
[ 20.995653] mtk-eip93 1fb70000.crypto: EIP93:3:0:1,PE(0xfe007:0x41710041)
[ 21.002925] NET: Registered PF_INET6 protocol family
[ 21.009062] Segment Routing with IPv6
[ 21.012767] In-situ OAM (IOAM) with IPv6
[ 21.016824] NET: Registered PF_PACKET protocol family
[ 21.022150] 8021q: 802.1Q VLAN Support v1.8
[ 21.026539] Registering SWP/SWPB emulation handler
[ 21.215024] clk: Disabling unused clocks
[ 21.218974] PM: genpd: Disabling unused power domains
[ 21.244918] Freeing unused kernel image (initmem) memory: 20480K
[ 21.251237] Run /init as init process
[ 21.916657] init: Console is alive
[ 21.920289] init: - watchdog -
[ 21.938050] kmodloader: loading kernel modules from /etc/modules-boot.d/*
[ 21.953765] gpio_button_hotplug: loading out-of-tree module taints kernel.
[ 21.979281] usbcore: registered new interface driver usb-storage
[ 21.985920] kmodloader: done loading kernel modules from /etc/modules-boot.d/*
[ 21.995869] init: - preinit -
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
[ 23.359330] procd: - early -
[ 23.362360] procd: - watchdog -
[ 23.895693] procd: - watchdog -
[ 23.899376] procd: - ubus -
[ 23.955725] procd: - init -
Please press Enter to activate this console.
[ 24.345582] kmodloader: loading kernel modules from /etc/modules.d/*
[ 24.681741] i2c_dev: i2c /dev entries driver
[ 24.705627] GACT probability on
[ 24.710193] Mirror/redirect action on
[ 24.746425] u32 classifier
[ 24.749155] input device check on
[ 24.752817] Actions configured
[ 24.784049] ntfs3: Enabled Linux POSIX ACLs support
[ 24.806662] Loading modules backported from Linux version v6.18.7-0-g5dfbc5357
[ 24.813903] Backport generated by backports.git c8a37ce
[ 24.912180] usbcore: registered new interface driver ums-alauda
[ 24.936525] usbcore: registered new interface driver ums-cypress
[ 24.944496] usbcore: registered new interface driver ums-datafab
[ 24.952214] usbcore: registered new interface driver ums-freecom
[ 24.967762] usbcore: registered new interface driver ums-isd200
[ 24.975748] usbcore: registered new interface driver ums-jumpshot
[ 24.983610] usbcore: registered new interface driver ums-karma
[ 24.991614] usbcore: registered new interface driver ums-sddr09
[ 24.999547] usbcore: registered new interface driver ums-sddr55
[ 25.007534] usbcore: registered new interface driver ums-usbat
[ 25.051742] xt_time: kernel timezone is -0000
[ 25.074920] urngd: v1.0.2 started.
[ 25.283105] mt7915e 0001:01:00.0: enabling device (0140 -> 0142)
[ 25.495484] mt7915e 0001:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20240429200716a
[ 25.522466] mt7915e 0001:01:00.0: WM Firmware Version: ____000000, Build Time: 20240429200752
[ 25.572088] mt7915e 0001:01:00.0: WA Firmware Version: DEV_000000, Build Time: 20240429200812
[ 25.780639] mt7915e 0001:01:00.0: eeprom load fail, use default bin
[ 25.787037] mt7915e 0001:01:00.0: Direct firmware load for mediatek/mt7915_eeprom_dbdc.bin failed with error -2
[ 25.797176] mt7915e 0001:01:00.0: Falling back to sysfs fallback for: mediatek/mt7915_eeprom_dbdc.bin
[ 25.818183] mt7915e 0001:01:00.0: probe with driver mt7915e failed with error -12
[ 25.853431] PPP generic driver version 2.4.2
[ 25.859787] NET: Registered PF_PPPOX protocol family
[ 25.876058] wireguard: WireGuard 1.0.0 loaded. See www.wireguard.com for information.
[ 25.883904] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
[ 25.907625] kmodloader: done loading kernel modules from /etc/modules.d/*
[ 39.495469] platform 1fb58000.switch: deferred probe pending: (reason unknown)
[ 39.502717] platform 1fb50000.ethernet: deferred probe pending: (reason unknown)
```
</details>
I had to remove that part because the driver not having network traffic. I didn't have to make many changes with the commit airoha_en7523/openwrt@dda777dd44
@merbanan
I had to remove that part because the driver not having network traffic. I didn't have to make many changes with the commit airoha_en7523/openwrt@dda777dd44
#define PPE_FOE_SIZE_64 80 //7581 64byte extend to 80byte.
#define PPE_FOE_SIZE_80 80
#define IS_64_BYTE_MODE 0
#define IS_80_BYTE_MODE 1
#define PPE_FOE_SIZE_BYTE_MODE IS_64_BYTE_MODE // 0 means foe size is 64byte
@merbanan
The en7523 PPE supports both 64-byte and 80-byte files, so why don't we use the 80-byte file since it's supported by the en7523?
https://sirherobrine23.com.br/airoha_en7523/airoha_sdk/src/commit/76a8cc95081337fa0434c62537247eabfde4925a/private/hw_nat/foe_fdb_7523_64Byte.h#L56-L63
https://sirherobrine23.com.br/airoha_en7523/airoha_sdk/src/commit/76a8cc95081337fa0434c62537247eabfde4925a/private/hw_nat/foe_fdb_7523_80Byte.h#L56-L63
and from what i've seen, the an7581 and an7583 are already using 80 bytes by default
https://sirherobrine23.com.br/airoha_en7523/airoha_sdk/src/commit/76a8cc95081337fa0434c62537247eabfde4925a/private/hw_nat/foe_fdb_7581_64Byte.h#L56-L63
https://sirherobrine23.com.br/airoha_en7523/airoha_sdk/src/commit/76a8cc95081337fa0434c62537247eabfde4925a/private/hw_nat/foe_fdb_7583.h#L56-L63
from what I've seen in the code, only the en7523 and the mips SoCs support 64 bytes, the an7581, an7583, and an7552 force 80 bytes in the PPE, and the EN7523 has both.
from what I've seen in the code, only the en7523 and the mips SoCs support 64 bytes, the an7581, an7583, and an7552 force 80 bytes in the PPE, and the EN7523 has both.
I wonder if the airoha_ppe and friends support 64byte at all. Anyway we probably should use that same as an7581 for now at least.
I will be adding the values for 7523_80Bytes, then I will also take a look at hw_offload through the NPU
They support it as much as a providing a bit to toggle it.
Should I continue with 80 or 64?
> I wonder if the airoha_ppe and friends support 64byte at all. Anyway we probably should use that same as an7581 for now at least.
I will be adding the values for 7523_80Bytes, then I will also take a look at hw_offload through the NPU
> They support it as much as a providing a bit to toggle it.
Should I continue with 80 or 64?
This is for the AN7581 but might work on EN7523 also.
it's returning the same values in raw_hwe that i added in ppe_debugfs, it's all coming back as zero.
> This is for the AN7581 but might work on EN7523 also.
it's returning the same values in raw_hwe that i added in ppe_debugfs, it's all coming back as zero.
@merbanan I added your mt76 patcher for the NPU's RX, and that's it for now. I'll test it with the NPU firmware from the xx230v, because the Heingard one doesn't work with my xx230v's wireless chip
When the PPE rules are working properly we can start looking into the wifi acceleration via WED and NPU. Alot of things needs to be wired in properly but in theory the same logic that is used in AN7581 for wifi offload can be used.
When the PPE rules are working properly we can start looking into the wifi acceleration via WED and NPU. Alot of things needs to be wired in properly but in theory the same logic that is used in AN7581 for wifi offload can be used.
Have you added WED support also? Or are those patches not yet merged?
Your patches caused a kernel panic with WED, but the NPU wouldn't finish configuring the ring, so I removed the patchers
Lots of PPE config registers seem to differ abit also.
Based on what I have from hw_nat/, I realized this, I added some, but it seems that some files are missing from the TP-Link GPLs that contain the codes
> > [ 25.917818] mt7915e 0001:01:00.0: NPU WiFi RX offload enabled (band 1)
> > [ 25.952631] mt7915e 0001:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20240429200716a
> > [ 25.980824] mt7915e 0001:01:00.0: WM Firmware Version: ____000000, Build Time: 20240429200752
> > [ 26.032227] mt7915e 0001:01:00.0: WA Firmware Version: DEV_000000, Build Time: 20240429200812
>
> Have you added WED support also? Or are those patches not yet merged?
Your patches caused a kernel panic with WED, but the NPU wouldn't finish configuring the ring, so I removed the patchers
> Lots of PPE config registers seem to differ abit also.
Based on what I have from `hw_nat/`, I realized this, I added some, but it seems that some files are missing from the TP-Link GPLs that contain the codes
@merbanan i got to that part, besides having a speed 100mbps higher than what I'm paying for, the CPU usage by qdma is quite variable, but probably because of the logs in uart.
@merbanan i got to that part, besides having a speed 100mbps higher than what I'm paying for, the CPU usage by qdma is quite variable, but probably because of the logs in uart.
Just merge the change as a new commit. If all is good later we can squash the commits. As long as it is a nice small commit it is easy to bisect. I'm going for the PPE so I'm not going to test any new code right now.
Just merge the change as a new commit. If all is good later we can squash the commits. As long as it is a nice small commit it is easy to bisect. I'm going for the PPE so I'm not going to test any new code right now.
On HexS I get decent speed via the WAN directly on openwrt, but if I use lan2 the traffic doesn't go to TCP/UDP, it reaches openwrt, but doesn't go to the wan port on gdm3
On HexS I get decent speed via the WAN directly on openwrt, but if I use lan2 the traffic doesn't go to TCP/UDP, it reaches openwrt, but doesn't go to the wan port on gdm3
It seems that gdm2 and gdm3 aren't communicating very well with gdm1
Is it working well from the device?
The (en8801sn) phy -> gdm3 pcie1 -> wan sounds like broken phy setup. Try the new kernel driver for it.
gdm1 -> wan should work fine but 1000Base-X might need additional code for the driver. Have you requested the Hex GPL packge? It should be in there.
> It seems that gdm2 and gdm3 aren't communicating very well with gdm1
Is it working well from the device?
The (en8801sn) phy -> gdm3 pcie1 -> wan sounds like broken phy setup. Try the new kernel driver for it.
gdm1 -> wan should work fine but 1000Base-X might need additional code for the driver. Have you requested the Hex GPL packge? It should be in there.
In my tests before the new changes, with only the patches I sent earlier, it was like this:
GDM3 -> GDM2: Okay, but without ppe
GDM3 -> GDM1: Only ping working
GDM3 -> GDM1: No upload in iperf test (iperf -c 192.168.1.10 -R)
In my tests before the new changes, with only the patches I sent earlier, it was like this:
- GDM3 -> GDM2: Okay, but without ppe
- GDM3 -> GDM1: Only ping working
- GDM3 -> GDM1: No upload in iperf test (`iperf -c 192.168.1.10 -R`)
Ok, my device have the usb-serdes connected to gdm3 so I should hit this issue also. I'll get there eventually. There might still be an issue with the serdes code.
Ok, my device have the usb-serdes connected to gdm3 so I should hit this issue also. I'll get there eventually. There might still be an issue with the serdes code.
This is a broken generated rule. The rule written sends the packets somewhere where they are dropped. Eventually it times out then some traffic gets through when it it learning the rule again. And then the broken state repeats. Might be a bad nbq id.
Can you run linux shell on the vendor software ?
> ╭─sirherobrine23@matheus-note ~
> ╰─$ iperf3 -c 172.16.0.0 -t 20
> Connecting to host 172.16.0.0, port 5201
> [ 5] local 192.168.1.220 port 56188 connected to 172.16.0.0 port 5201
> [ ID] Interval Transfer Bitrate Retr Cwnd
> [ 5] 0.00-1.00 sec 768 KBytes 6.28 Mbits/sec 11 1.41 KBytes
> [ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
> [ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
> [ 5] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
> [ 5] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
> [ 5] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
> [ 5] 6.00-7.00 sec 2.00 MBytes 16.8 Mbits/sec 21 1.41 KBytes
> [ 5] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
> [ 5] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
> [ 5] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
> [ 5] 10.00-11.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
> [ 5] 11.00-12.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
> [ 5] 12.00-13.00 sec 384 KBytes 3.15 Mbits/sec 12 28.3 KBytes
> [ 5] 13.00-14.00 sec 1.75 MBytes 14.7 Mbits/sec 7 1.41 KBytes
> [ 5] 14.00-15.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
> [ 5] 15.00-16.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
> [ 5] 16.00-17.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
> [ 5] 17.00-18.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
> [ 5] 18.00-19.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
> [ 5] 19.00-20.00 sec 1.88 MBytes 15.7 Mbits/sec 29 1.41 KBytes
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval Transfer Bitrate Retr
> [ 5] 0.00-20.00 sec 6.75 MBytes 2.83 Mbits/sec 87 sender
> [ 5] 0.00-20.00 sec 6.50 MBytes 2.73 Mbits/sec receiver
>
This is a broken generated rule. The rule written sends the packets somewhere where they are dropped. Eventually it times out then some traffic gets through when it it learning the rule again. And then the broken state repeats. Might be a bad nbq id.
Can you run linux shell on the vendor software ?
No, not on RouterOS, it sends me to its limited shell
gdm1 -> wan should work fine but 1000Base-X might need additional code for the driver. Have you requested the Hex GPL packge? It should be in there.
I made the request, but they sent the 2022 RouterOS GPL, without any content about Econet/Airoha in that GPL, so I don't have much information about it
> Can you run linux shell on the vendor software ?
No, not on RouterOS, it sends me to its limited shell
> gdm1 -> wan should work fine but 1000Base-X might need additional code for the driver. Have you requested the Hex GPL packge? It should be in there.
I made the request, but they sent the [2022 RouterOS GPL](https://box.mikrotik.com/d/81912835977544a291c9/), without any content about Econet/Airoha in that GPL, so I don't have much information about it
airoha_probe() brought up the QDMA hardware (airoha_hw_init() +
airoha_qdma_start_napi()) before allocating the GDM ports. The GDM port
allocation reads the port MAC address via of_get_ethdev_address(), which
on boards that store the MAC in a late-registering nvmem provider (e.g. a
U-Boot env or fixed-layout cell on a UBI volume) returns -EPROBE_DEFER.
On that defer the probe error path runs airoha_hw_cleanup() ->
page_pool_destroy() while the RX DMA is already live. page_pool_destroy()
then busy-waits for in-flight RX pages that are never returned, live-locks
against the RX softirq and hangs the CPU - so the deferred probe is never
retried and the board never boots.
Allocate the GDM ports (and thus read the MAC) before airoha_hw_init() so
an -EPROBE_DEFER unwinds before any RX ring or page pool exists. Add an
error_ports_free label for the pre-hardware unwind; the post-hardware
failure path keeps stopping NAPI and calling airoha_hw_cleanup().
Signed-off-by: Benjamin Larsson <benjamin.larsson@genexis.eu>
Signed-off-by: Matheus Sampaio Queiroga <srherobrine20@gmail.com>
Add Airoha EN7523 Switch support. This is based on Airoha EN7581 that is
based on Mediatek MT7988 Switch.
Signed-off-by: Matheus Sampaio Queiroga <srherobrine20@gmail.com>
Support for en7523 has been added to the Airoha NPU. Some changes have been implemented to start the cores, as they are different generations but with the same code base.
In addition to introducing the correct values for l2c size and fpga stage, which are taken from the SCU, and obtaining the version of the loaded firmware.
Signed-off-by: Matheus Sampaio Queiroga <srherobrine20@gmail.com>
Introduce support for EN7523 ethernet controller to airoha-eth dirver
and ppe support for en7523 SoC
Signed-off-by: Matheus Sampaio Queiroga <srherobrine20@gmail.com>
The EN7523 PON PCS has phya=INVALID, so mainline never initialises the
analog serdes PMA. The attached RTL8221B drives an SGMII (1.25G) serdes for
a 1G copper link and a 2500Base-X (3.125G) serdes at 2.5G; without the
matching analog PMA bring-up the serdes link never establishes and the
XSI-AE MAC stays in local-fault with no traffic.
Port the vendor sgmii_api_pon0_force_{sgmii,hsgmii}() PMA bring-up: pulse
the serdes + XSI-MAC clock-domain reset, then program SSR3/WAN_CONF and the
rate-specific PMA registers (the reset clears SSR3/WAN_CONF, so they must be
written after it), saving/restoring the MAC global config across the reset.
Dispatch the SGMII or 2500Base-X init from pcs_config() by interface for the
PON port, so the link comes up at either copper speed.
Signed-off-by: Benjamin Larsson <benjamin.larsson@genexis.eu>
Signed-off-by: Matheus Sampaio Queiroga <srherobrine20@gmail.com>
Only advertise the higher-rate PHY interfaces (2500BASEX, 10GBASER,
USXGMII) when the GDM port is actually configured for them. An RTL8221B
attached in SGMII mode (1G copper) otherwise sees 2500BASEX in
host_interfaces and forces its serdes to 2500Base-X rate-match, which never
links against an SGMII PCS.
Signed-off-by: Benjamin Larsson <benjamin.larsson@genexis.eu>
Signed-off-by: Matheus Sampaio Queiroga <srherobrine20@gmail.com>
The USB and PCIe serdes (GDM3 external ports) have a real phya so their
analog is handled by set_phya_mode(), but mainline never programs the
rate-adapt/AN/PCS-control values nor pulses their clock-domain reset, so the
serdes link to the SoC never establishes. Port the vendor
sgmii_api_{usb0,pcie0,pcie1}_force_hsgmii() bring-up: a shared helper writes
RATE_ADAPT_CTRL_0/AN0/CTROL_6 and pulses RST_CFG with the per-port reset bits
(PCIe0 0x12000, PCIe1 0x24000, USB 0x48000), saving/restoring the MAC global
config across the reset. Dispatch it by PCS type in the 2500Base-X path.
Signed-off-by: Benjamin Larsson <benjamin.larsson@genexis.eu>
Signed-off-by: Matheus Sampaio Queiroga <srherobrine20@gmail.com>
Wire up the EN7523 GDM3 USB serdes port (a third RTL8221B on the bitbang
MDIO bus). The USB port is the third device on GDM3, so grow the per-port
device array to 3, and fix the USB source-port plumbing to match the DT
eth-port reg (6): get_sport()/get_vip_port() map USB at nbq==6, and the RX
get_dev_from_sport() maps the USB source port to device index 2. PCIe0/PCIe1
(dev 0/1) are unchanged.
Signed-off-by: Benjamin Larsson <benjamin.larsson@genexis.eu>
Signed-off-by: Matheus Sampaio Queiroga <srherobrine20@gmail.com>
The EN7523 PON SerDes SGMII-rate PMA setup is required not only for
PHY_INTERFACE_MODE_SGMII, but also for PHY_INTERFACE_MODE_1000BASEX. Some
SFP/copper modules are resolved by phylink as 1000Base-X while still using the
same 1.25G line rate on the host SerDes side. Without running the SGMII-rate
PON PMA sequence in that mode, the link can be reported as up while no traffic
reaches the XSI/GDM2 path.
Also keep the PON PCS link_up() path active when in-band negotiation is
enabled. Unlike the other EN7523 PCS instances, the PON path still needs
link_up() to apply the resolved speed to the PCS rate-adapt/force-speed state.
This fixes the case where the SFP reports 1G/full link but the EN7523 XSI/GDM2
RX counters stay at zero.
Signed-off-by: Matheus Sampaio Queiroga <srherobrine20@gmail.com>
The EN7523 has no airoha-npu module/firmware, so PPE hardware flow
offload never engaged: airoha_ppe_offload_setup() returned -ENODEV and
the FOE table stayed empty (software routing, high CPU).
Make the PPE work CPU-direct on EN7523, matching the working vendor
(IOWRT stock) firmware whose registers/FOE entries were captured via
devmem/hw_nat. Verified end to end: an iperf3 stream forwarded through
the device shows 0% softirq / ~95% idle on the CPU and ~99% of packets
bypassing the CPU (0 retransmits), versus 100% software-routed before.
The required pieces:
- NPU bypass: when airoha_npu_get() fails, run airoha_ppe_hw_init()
once and proceed CPU-direct (eth->npu stays NULL so the commit/stats
paths skip the NPU); guard re-setup with a per-ppe offload_setup_done
flag so it does not re-fire (and re-request the npu module) per flow.
- 64-byte FOE entry mode (PPE_ENTRY_SIZE 64, 512 on-chip SRAM entries):
the EN7523 PPE search engine only operates in 64-byte mode. Drop the
trailing meter word / rsv2[] from the FOE structs so they fit 64B.
- Program the PPE config registers to the vendor values in hw_init
(GLO_CFG / FLOW_CFG / IP_PROTO_CHK / TB_CFG / TB_HASH_CFG and the
KA / MIRROR / L2-bridge registers).
- FOE entry PORT_AG = 0 on EN7523 (vendor ib2=0x240 vs mainline 0x3e240).
- Egress MTU (the gate that kept hw forwarding from ever engaging):
REG_PPE_MTU and REG_WAN_MTU0 limit the egress *L2 frame* length, but
mainline programmed them with netdev->mtu (the L3 payload limit), so
every full-size 1514-byte forwarded frame was bounced to the CPU with
HIT_BIND_EXCEED_MTU. Add the L2 overhead (Ethernet header, up to two
VLAN tags, PPPoE and FCS). WAN_MTU0 is the gate for wan-port egress;
PPE_MTU is set generously for all FPs in hw_init since the hardware-
forwarded path can egress on an FP other than the programmed port
index - both must be wide enough or offload silently falls back to
the CPU.
- Bind UNBIND entries: the EN7523 hardware auto-creates an UNBIND entry
and samples packets as HIT_UNBIND, so commit the matching pending flow
for any non-BIND state (INVALID or UNBIND), not only INVALID.
- Fix the EN7523 USB/GDM3 source-port (nbq 6) and allow a third GDM dev.
Signed-off-by: Benjamin Larsson <banan@ludd.ltu.se>
Signed-off-by: Matheus Sampaio Queiroga <srherobrine20@gmail.com>
GDM3 (the EN7523 e650 "lan4" port) rides the USB (SSUSB) serdes via the
usb_pcs PCS (compatible "airoha,en7523-pcs-usb", driver type
EN7523_PCS_USB), not the PON PCS. 941-01 only brings up the PON serdes
(its analog PMA init is gated on res->setup_pon and the PON PMA mapping on
data->type == EN7523_PCS_PON), so the USB serdes never gets its
XSI-MAC/serdes clock-domain reset.
The result: the USB PCS digital layer is configured and link/AN train
("link up" at the copper speed), but the MAC/serdes RX datapath is never
reset into a working state, so the frame engine receives zero frames
(GDM3 FE RX counter stays 0; lan4 fails at every copper speed).
The vendor sgmii_api_usb0_force_{sgmii,hsgmii}() pulse SCU_RST bits 15+18
around a save/restore of the PCS MAC global config to bring the RX datapath
up. Port just that reset for the USB PCS (the digital PHYA / rate-adapt /
AN / PCS control writes are already done by the common pcs_config path);
run it after the PCS digital config, matching the vendor order.
Signed-off-by: Benjamin Larsson <banan@ludd.ltu.se>
Signed-off-by: Matheus Sampaio Queiroga <srherobrine20@gmail.com>
Hardware NAT offload through the EN7523 GDM3 port (the USB/XSI HSGMII
serdes LAN port, e650 "lan4") blackholed every offloaded frame while
GDM1/GDM2 worked and software forwarding through GDM3 was fine.
Comparing the FOE entry built by this driver against the one the vendor
firmware programs for the same flow (via hw_nat -g) shows the egress
info-block-2 differs only in the destination queue:
vendor downlink (->GDM3): INFO2=0x266 PSE_PORT=3, PSE_QOS, NBQ=6
mainline downlink (->GDM3): INFO2=0x260 PSE_PORT=3, PSE_QOS, NBQ=0
GDM3 is the USB serdes port, whose source-port queue is nbq 6 (the same
value the RX source-port path maps to HSGMII_LAN_7523_USB_SRCPORT). With
NBQ=0 the PPE targets a PSE port-3 queue that the USB-serdes output never
services, so the frame is dropped. The driver only set IB2_NBQ for DSA
ports, leaving GDM3 at 0.
Set IB2_NBQ=6 for EN7523 GDM3 egress. The vendor offloads this path at
942 Mbit/s; with this fix the mainline driver hardware-forwards GDM3
flows instead of blackholing them.
Signed-off-by: Benjamin Larsson <banan@ludd.ltu.se>
Signed-off-by: Matheus Sampaio Queiroga <srherobrine20@gmail.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
merbanan
Sirherobrine23
ToDo
@merbanan I had to revert airoha_eth, and when I re-enabled
NETIF_F_IP_CSUMandNETIF_F_TSOI had no TCP network traffic; several packets were being sent out of sequence or out of order, but ICMP was working normally.Something else I'm seeing is IPv6, it works occasionally, but it must be a problem on my end. Another thing I'm noticing in Wireshark is multiple retransmissions, ipv6 icmp working normally
@@ -1152,5 +1152,5 @@* the MT7988 SoC. Trapped frames will be forwarded to the CPU port that* is affine to the inbound user port.*/if (priv->id == ID_MT7531 || priv->id == ID_MT7988 ||priv->id == ID_EN7581 || priv->id == ID_AN7583)same here
@@ -2588,5 +2588,5 @@/* Allow mirroring frames received on the local port (monitor port). */mt7530_set(priv, MT753X_AGC, LOCAL_EN);/* Enable Special Tag for rx frames */if (priv->id == ID_EN7581 || priv->id == ID_AN7583)@merbanan i'm surprised that my switch is working without adding
|| priv->id == ID_EN7523Well I am using the EN7581 settings so I think you can get away with alot. It just wont work optimally.
@@ -491,0 +518,4 @@if (airoha_is(eth, en7523)) {/* map GDMP sram to fe */airoha_wr(eth->gdmp_regs, 0x74, 3);@merbanan this is fist build with
gdmpenabled in my code and workingDo you get ~250mbit tx now ?
Openwrt -> Computer: 620~812Mbps
Computer -> Openwrt: 1.05~2.10Mbps
router
computer
It seems the PPE will be tweaked later; some things appear to be working, but there's a lot of packet loss with PPE/NPU enabled
I am getting over 200mbit from the SoC tx path. There must be something missing in the code.
@@ -606,3 +666,3 @@break;case 0x10 ... 0x14:case 0x8 ... 0x14:port = 0; /* GDM1 */I think this hunk is bogus. 0x10-0x14 should be correc.t
@@ -1957,2 +2066,2 @@qid = skb_get_queue_mapping(skb) % ARRAY_SIZE(qdma->q_tx);tag = airoha_get_dsa_tag(skb, dev);if (skb->len > 2048)goto error;Get rid of this. It was just debug code.
@@ -1979,2 +2097,3 @@tcp_hdr(skb)->check = (__force __sum16)csum;msg0 |= FIELD_PREP(QDMA_ETH_TXMSG_TSO_MASK, 1);if (!airoha_is(qdma->eth, en7523))msg0 |= FIELD_PREP(QDMA_ETH_TXMSG_TSO_MASK, 1);This is unneeded.
@@ -627,1 +655,4 @@static const struct airoha_npu_soc_data an7583_npu_soc_data = {.use_memremap = false,.extra_cores = true,.num_cores = 8,This can be 2-6 depending on the model of the SoC. A dts property would be better in this case.
If the cores actually are fused off is unclear but thermals must be respected.
but from
computer->routeris slowbut download is okay
and with NPU enable is okay
Hmm I was able to get 200mbit. Are you still having issues with tx?
I was away for the weekend, I got back on Monday and didn't even have time to mess with the kernel. I haven't had much time to look at the pinctrl driver yet, I'll try it today, And I'll also try to take a look at the xPON phy code today
I'll test it with gdmp disabled to see if there's any change, but I don't think there will be much of a difference in speed
Out of the box from current tree I get ~250 mbit.
That's much better, but why is the upload so slow, while the download seems to reach almost GbE speeds?
I'm away from home and I don't know when I'll be back. I have the router with me, but I don't know when I'll be able to test it. Could you send me your settings so I can test them when possible?
There are no settings. I just start iperf3 -s on the router and do the test. One thing that might cause the issue is that I think TSO is broken. My Realtek network card seems to ignore that the MTU is huge so it just works anyway. Maybe that is why you have issues.
Regarding low tx performance it might be this dsa tag mem move that is redundant.
Anyway the ref software gets like 350mbits. So it is possible to get more but the target is to get hardware acceleration going and then it doesnt matter anyway. 250mbit is enough to handle the control traffic.
So, from what I understand, the upload speed won't exceed 350Mbps without hardware acceleration on the switch for wireless and on the switch for CPU?
I'd like to be able to test iperf3 at stock speeds to see what speed it's currently running at.
Well I would expect that more engineering would be able to beat the ref driver. Top gives 70% idle.
For example I think that the we also only use one core. At least we only trigger interrupts on one core.
So IMO there is more performance to be unlocked.
Ok, I found one thing now. But it should be possible to get more performance. This only fixes TCP, udp seems to be capped at 84.5Mbits/s.
Just add back the missing TSO flag.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/airoha/airoha_eth.c?h=v6.19-rc1#n1939
That one was missing from the main code. Now I get this:
This is good, it makes it more acceptable, but in terms of internet access, when I tested with https://speed.cloudflare.com without TSO msg, I got around 200-320Mbps download and 30-60Mbps upload.
I have a 600Mbps download and 300Mbps upload connection, I don't have another Ethernet device to test the switch locally 🙃🙃
Yeah, there is something else also. If I disabled TSO in hwcaps I only get like 100mbits/s and the cpu is far from running at 100%. TSO is just hardware acceleration kicking in.
@@ -605,3 +672,3 @@port = 2; /* GDM3 */break;case 0x10 ... 0x14:case 0x8 ... 0x14:This should be reverted.
@@ -1660,0 +1753,4 @@airoha_fe_clear(qdma->eth, REG_GDM_INGRESS_CFG(port->id),GDM_STAG_EN_MASK);}The following 2 lines should be removed.
from this
to this?
Those lines should be removed.
@@ -1015,3 +1083,3 @@airoha_qdma_rmw(qdma, REG_TX_IRQ_CFG(id), TX_IRQ_THR_MASK,FIELD_PREP(TX_IRQ_THR_MASK, 1));FIELD_PREP(TX_IRQ_THR_MASK, 0x20));Revert this also.
@@ -37,6 +37,8 @@#define TX_DSCP_NUM 1024Wouldn't it be good to add this here?
0a55a19aa2/xx230v/src_output/opt/bba/bba_3_0_platform/sdk/en7529/modules/private/qdma/EN7516/qdma_bmgr.c (L11-L20)I guess, I am not convinced all this is good (ie the raf code ring buffer sizes). I think all this queue stuff is over engineered from the hardware side. Some of the queues need to be large but the others will only allocate unnecessary memory.
If we ever get to adding GPON support then yes we maybe need to differentiate the sizes of the descriptor (dma) rings. If we add a printout there:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/airoha/airoha_eth.c?h=v6.19-rc1#n1956
We will notice if we ever run out of descriptors.
Anyway, the networking part is now better then what the reference software can reach but the question is what happens with the wifi performance. We might need to tune some parameters when wifi gets in the mix.
We need to get the PPE working properly, and get the NPU working with the MT76 as well. Currently, the Wi-Fi is working at the best upload and download speeds possible on the LAN, and communication between devices is normal, as I can get 1.2Gbps~880Mbps on the 5GHz wireless band
with Flow offloading enabled
CPU utilization
stock router is strange compared with now
(this is in stock firmware)
(this in stock -> openwrt)
I guess the cpu performance is ok for now. Will you update the openwrt PR?
Yes, I will, but I have to resolve a problem with pinctrl, the device is crashing and restarting after 45Secs
Here you should split out the mt7530 parts and send those upstream. They are ok, it is all the other stuff that will be difficult. But splitting out things into smaller parts is always the best way forward.
@@ -1654,3 +1745,3 @@if (netdev_uses_dsa(dev) || port->id > 2)airoha_fe_set(qdma->eth, REG_GDM_INGRESS_CFG(port->id),GDM_STAG_EN_MASK);GDM_STAG_EN_MASK);Redundant hunk
Anyway my main point is that it will take alot of time to get everything upstream and we need to start that process. Divide and conquer, take small and easy parts and then go from there. I am not sure how we should handle the difference in position of the dma descriptor members. This is something I think we till get an answer from the kernel devs. But to get there we need patch set that is easy to review. So split out the mt7530 parts and the npu stuff. The phy change should be its own patch also. From there we start chipping off airoha_eth.c into a patch set with like 90% easy stuff and 10% of the tricky parts.
I suggest you start with sending the phy path upstream. It is tiny and easy to review.
I will have to make a patch for mt76 to activate wed on mt7915
Sirherobrine23 referenced this pull request2026-01-24 11:08:02 +00:00
Hi @merbanan, @lilmayofuksu tested the ethernet on the EN7562, here's the iperf test:
@merbanan needs this large qdma size?
ecb65624e5/target/linux/airoha/dts/en7523.dtsi (L34-L42)I'm having trouble loading initramfs due non free memory
I am quite sure that we can reduce the buffer allocation quite a lot. Maybe you can look at the memory allocation after boot up. The NPU memory reservation can temporary be removed also.
I've noticed that if the traffic goes through the cpu (wan port), I can only get around 500mbps
I ran the speed test on OpenWrt to check the network speed (speedtestcpp and speedtest-go installed). Between the interfaces (WAN -> LAN), at least 60 to 80% of the traffic between them is expected. Wireless traffic should be about 70% of what arrives on the WAN.
@merbanan the npu boot sequence is quite different from v2, v2 has more definitions
522a0ca806/include/global_inc/modules/npu/wifi_mail_type.h (L57-L85)while v1 has
4d76b59039/sdk/en7529/release_bsp/UNION_EN7523_GLIBC_7915_7915_ActiveEthWan_demo/global_inc/modules/npu/wifi_mail_type.h (L61-L78),Currently, we call
airoha_npu_wlan_init_memorywhen the mt76 module is loadedThe log we should have:
By configuring it to be set even before the module loads, we have this:
4d76b59039/sdk/en7529/linux-4.4.115/include/ecnt_hook/ecnt_hook_fe.h (L1784-L1793)Look at the end of this file and you'll see that it's also freezing after the switch interfaces come up
I have some NPU-related information. Apparently the NPUs access the console port uart directly. Lines with [CX] (X=0-3) are emitted directly from the NPU cores running the loaded code.
If the following is run:
devmem 0x1ec0c194 32 0x00000001 (any non zero value).
The NPU log output to the console stops.
The NPUs seems to be RiscV 32 based. Ghidra can partially disassemble the firmware.
I still don't know what's happening, but when airoha_eth loads, it freezes the entire system trying to access something on the NPU. I'll take a closer look at what's going on
0 => Enable NPU UART Log
1 => Disable NPU UART log
522a0ca806/econet_public/arch/arm/mach-econet/ecnt_npu.c (L704-L708)crashing after this
@merbanan I tested it and made several changes to the NPU code. The entire system crashes when the switch is enabled, but when I disable the switch, it doesn't crash. and it always crashes at
[ 17.287891] mt7530-mmio 1fb58000.switch wan: configuring for phy/internal link mode. Regarding the NPU on the mt76 for themt7915e, I will still have to change a few things:I ran tests today, and I'm still having problems with the switch. If I boot with only one cable connected to LAN3, I get traffic, but if I use more than one cable, it doesn't detect the connection on any of the switch ports
But the LEDs light up when I connect the cables and blink initially when connected
The analog parts are always tricky. What is the result if you only calibrate rext?
I had a problem with my script to applying patches, but I just uploaded commit i'm using
I'm seeing mt7530 drivers in the mt7621 and they use these interrupts:
interruptsshould not start with0I looked at the dtsi and interrupt-parent is missing.
GIC_INT <-> SPI_37 <-> MT7530_INT <-> 1,2,3,4
This is how the interrupt routing needs to be.
What do you mean? I don't understand. The interrupt is on the eth:
2b693a6bf8/target/linux/airoha/dts/en7523.dtsi (L639-L640)Will I need to add it to the switch?
The MT7530 switch is connected to the GIC interrupt controller pin 31 (not 37).
The 1G switch port phys are connected to the MT7530 switch interrupt controller.
I am unsure if this node will resolve to the correct interrupt controller (MT7530). If cat /proc/interrupts show that the mt7530 interrupts are allocated to the phy ports then everything is fine. If not then the interrupt parent is needed.
When the port phy emits an interrupt is travels to the the GIC via pin 31, then the mt7530 interrupt handler is run to handle the event.
this is interrupts in xx230v:
LGTM. But the dtsi should disable the phys and the dts should enable the used ports.
b58177150ato92609bdc3b92609bdc3btodaee516910daee516910to3069f60542503d0ff11btocd8c2512abcd8c2512abto3069f60542the Ethernet driver seems to be having some kind of problem, but I haven't yet identified where
and in the npu same:
3069f60542tobb30e68e37bb30e68e37todb790e36ec@merbanan i had to do a rollback to commit
470ae207b6...c3f3209d67of the ethernet driver to boot normaly but ethernet driver no working in en7529 SoC's, on en7562 working but hw offload stop working with TCP packet with hw offload without rollback commitEN7529CT Bootlog with rollback commit
10c24861d1toc0bea29f43c0bea29f43to5a2e2608195a2e260819toa766e9204ea766e9204etoabac5a43b1abac5a43b1to2fff451466728b2776d4to23acbe6fa2@@ -553,12 +614,13 @@ static int airoha_qdma_fill_rx_queue(struct airoha_queue *q)q->queued++;nframes++;offset += AIROHA_RX_HEADROOM;@merbanan
I had to remove that part because the driver not having network traffic. I didn't have to make many changes with the commit airoha_en7523/openwrt@dda777dd44
23acbe6fa2to9ec90a52399ec90a5239to58b92e371558b92e3715to16bf7a886516bf7a8865tob61f1f3a2ab61f1f3a2ato52092d6ac7@merbanan
The en7523 PPE supports both 64-byte and 80-byte files, so why don't we use the 80-byte file since it's supported by the en7523?
and from what i've seen, the an7581 and an7583 are already using 80 bytes by default
I wonder if the airoha_ppe and friends support 64byte at all. Anyway we probably should use that same as an7581 for now at least.
from what I've seen in the code, only the en7523 and the mips SoCs support 64 bytes, the an7581, an7583, and an7552 force 80 bytes in the PPE, and the EN7523 has both.
They support it as much as a providing a bit to toggle it.
I will be adding the values for 7523_80Bytes, then I will also take a look at hw_offload through the NPU
Should I continue with 80 or 64?
80, we can always change back if we need the ram for some reason.
okay
4dba462531to39d9b6841f39d9b6841ftof7f93b63a3f7f93b63a3toac0acfff1fcomputer:
openwrt:
Can you try adding the LRO patches posted by lorenzo?
As far as I know, they are already included here, and I have already added the en7523
i added a print dump to airoha_ppe_foe_get_entry_locked, and it's returning a completely empty table:
ac0acfff1ftod6f46892f0This is for the AN7581 but might work on EN7523 also.
it's returning the same values in raw_hwe that i added in ppe_debugfs, it's all coming back as zero.
d6f46892f0toca70a218e0i added some changes, now it seems the entries are being added to the PPE, but I don't recognize some addresses, so I can't consider it working
i say this because my IPv6 is disabled on the local network
furthermore, I achieved stability in the NPU initialization by changing MEMREMAP_WB to MEMREMAP_WC in devm_memremap
Entries
i just added dev_info to the push of entries in the PPE and we are having the data inserted incorrectly in the PPE
ppe
airoha_ppe_foe_flow_commit_entry/sys/kernel/debug/ppe/entries
ca70a218e0to33a58913c333a58913c3to9941ce9a549941ce9a54to8ec31f73538ec31f7353to25fa0a541a@merbanan I added your mt76 patcher for the NPU's RX, and that's it for now. I'll test it with the NPU firmware from the xx230v, because the Heingard one doesn't work with my xx230v's wireless chip
my laptop:
25fa0a541atofc3c0a8425fc3c0a8425to33da58c29d5719b0a676to33da58c29dWhen the PPE rules are working properly we can start looking into the wifi acceleration via WED and NPU. Alot of things needs to be wired in properly but in theory the same logic that is used in AN7581 for wifi offload can be used.
The
ppe/entriesis being populated, but the offload is still going to the CPU, so I'm being misled here 😩We need proper tools to look at the rules. And of course the PPE rules have another bit packing on EN7523...
Lots of PPE config registers seem to differ abit also.
Have you added WED support also? Or are those patches not yet merged?
Your patches caused a kernel panic with WED, but the NPU wouldn't finish configuring the ring, so I removed the patchers
Based on what I have from
hw_nat/, I realized this, I added some, but it seems that some files are missing from the TP-Link GPLs that contain the codes@merbanan i got to that part, besides having a speed 100mbps higher than what I'm paying for, the CPU usage by qdma is quite variable, but probably because of the logs in uart.
new tests without uart logs
local tests (Mikrotik mt7621 -> xx230v -> laptop)
e466df2fd8to9bf6f49282@merbanan now sfp working in hex s with changes i added
Bootlog
\o/
@merbanan confirm if working with u devices
Just merge the change as a new commit. If all is good later we can squash the commits. As long as it is a nice small commit it is easy to bisect. I'm going for the PPE so I'm not going to test any new code right now.
Okay, I'm noticing that network traffic isn't working very well from gdm3 to gdm1 (switch), but from gdm3 to gdm2 it is working, but without the PPE
The is something to look at after the PPE is working.
b3f7d0a972tobfe037d726@merbanan I think this test in mkt hexS
It seems that gdm2 and gdm3 aren't communicating very well with gdm1
Is device to gdm2/gdm3 pings working well ?
We need to add the xsi mac resets also. Right now the code toggles the reset regs. I'm not sure the reset driver has the support.
214b35bd92toac69130e0aOn HexS I get decent speed via the WAN directly on openwrt, but if I use lan2 the traffic doesn't go to TCP/UDP, it reaches openwrt, but doesn't go to the wan port on gdm3
Is it working well from the device?
The (en8801sn) phy -> gdm3 pcie1 -> wan sounds like broken phy setup. Try the new kernel driver for it.
gdm1 -> wan should work fine but 1000Base-X might need additional code for the driver. Have you requested the Hex GPL packge? It should be in there.
In my tests before the new changes, with only the patches I sent earlier, it was like this:
iperf -c 192.168.1.10 -R)Ok, my device have the usb-serdes connected to gdm3 so I should hit this issue also. I'll get there eventually. There might still be an issue with the serdes code.
GDM1 (LAN2) -> GDM3 PCIE1:
GDM1: LAN2 -> LAN5
GDM3 -> GDM2
GDM{1,2,3} -> Openwrt host
GDM1:
GDM2 -> Openwrt Host
GDM3 PCIE1:
This is a broken generated rule. The rule written sends the packets somewhere where they are dropped. Eventually it times out then some traffic gets through when it it learning the rule again. And then the broken state repeats. Might be a bad nbq id.
Can you run linux shell on the vendor software ?
No, not on RouterOS, it sends me to its limited shell
I made the request, but they sent the 2022 RouterOS GPL, without any content about Econet/Airoha in that GPL, so I don't have much information about it
77127f3d5etocf59175bfdcf59175bfdto8af48e1ab18af48e1ab1to1cf05aeaacThe EN7523 PON PCS has phya=INVALID, so mainline never initialises the analog serdes PMA. The attached RTL8221B drives an SGMII (1.25G) serdes for a 1G copper link and a 2500Base-X (3.125G) serdes at 2.5G; without the matching analog PMA bring-up the serdes link never establishes and the XSI-AE MAC stays in local-fault with no traffic. Port the vendor sgmii_api_pon0_force_{sgmii,hsgmii}() PMA bring-up: pulse the serdes + XSI-MAC clock-domain reset, then program SSR3/WAN_CONF and the rate-specific PMA registers (the reset clears SSR3/WAN_CONF, so they must be written after it), saving/restoring the MAC global config across the reset. Dispatch the SGMII or 2500Base-X init from pcs_config() by interface for the PON port, so the link comes up at either copper speed. Signed-off-by: Benjamin Larsson <benjamin.larsson@genexis.eu> Signed-off-by: Matheus Sampaio Queiroga <srherobrine20@gmail.com>The USB and PCIe serdes (GDM3 external ports) have a real phya so their analog is handled by set_phya_mode(), but mainline never programs the rate-adapt/AN/PCS-control values nor pulses their clock-domain reset, so the serdes link to the SoC never establishes. Port the vendor sgmii_api_{usb0,pcie0,pcie1}_force_hsgmii() bring-up: a shared helper writes RATE_ADAPT_CTRL_0/AN0/CTROL_6 and pulses RST_CFG with the per-port reset bits (PCIe0 0x12000, PCIe1 0x24000, USB 0x48000), saving/restoring the MAC global config across the reset. Dispatch it by PCS type in the 2500Base-X path. Signed-off-by: Benjamin Larsson <benjamin.larsson@genexis.eu> Signed-off-by: Matheus Sampaio Queiroga <srherobrine20@gmail.com>GDM3 (the EN7523 e650 "lan4" port) rides the USB (SSUSB) serdes via the usb_pcs PCS (compatible "airoha,en7523-pcs-usb", driver type EN7523_PCS_USB), not the PON PCS. 941-01 only brings up the PON serdes (its analog PMA init is gated on res->setup_pon and the PON PMA mapping on data->type == EN7523_PCS_PON), so the USB serdes never gets its XSI-MAC/serdes clock-domain reset. The result: the USB PCS digital layer is configured and link/AN train ("link up" at the copper speed), but the MAC/serdes RX datapath is never reset into a working state, so the frame engine receives zero frames (GDM3 FE RX counter stays 0; lan4 fails at every copper speed). The vendor sgmii_api_usb0_force_{sgmii,hsgmii}() pulse SCU_RST bits 15+18 around a save/restore of the PCS MAC global config to bring the RX datapath up. Port just that reset for the USB PCS (the digital PHYA / rate-adapt / AN / PCS control writes are already done by the common pcs_config path); run it after the PCS digital config, matching the vendor order. Signed-off-by: Benjamin Larsson <banan@ludd.ltu.se> Signed-off-by: Matheus Sampaio Queiroga <srherobrine20@gmail.com>1cf05aeaacto8180e76ac9View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.