Ethernet #2
No Assignees
Notifications
Due Date
No due date set.
Blocks
Reference: airoha_en7523/kernel#2
Reference in New Issue
Block a user
4d76b59039/sdk/en7529/linux-4.4.115/arch/arm/boot/dts/en7523.dts (L348-L363)4d76b59039/sdk/en7529/linux-4.4.115/arch/arm/boot/dts/en7523.dts (L298-L304)Files
4d76b59039/sdk/en7529/linux-4.4.115/arch/arm/mach-econet/ecnt_frame_engine.c4d76b59039/sdk/en7529/linux-4.4.115/arch/arm/mach-econet/ecnt_xsi.cqdma_dev consume
4d76b59039/sdk/en7529/linux-4.4.115/qdma_dev.i (L62496-L65608)External comments
I am getting packet data through to the CPU now. But it is not correctly mapped to the correct interface. I am seeing ARP and stuff.
00:02:48.104438 IP 192.168.1.100 > OpenWrt.lan: ICMP echo request, id 139, seq 5, length 64
00:02:48.104561 IP OpenWrt.lan > 192.168.1.100: ICMP echo reply, id 139, seq 5, length 64
00:02:49.128439 IP 192.168.1.100 > OpenWrt.lan: ICMP echo request, id 139, seq 6, length 64
00:02:49.128562 IP OpenWrt.lan > 192.168.1.100: ICMP echo reply, id 139, seq 6, length 64
00:02:50.152444 IP 192.168.1.100 > OpenWrt.lan: ICMP echo request, id 139, seq 7, length 64
00:02:50.152568 IP OpenWrt.lan > 192.168.1.100: ICMP echo reply, id 139, seq 7, length 64
EN7523 CPU can now RX
You can send me the patcher so I can test it when I receive the xx230v.
Yeah, I will. I'll try to sort out tx now.
4d76b59039/sdk/en7529/linux-4.4.115/arch/arm/boot/dts/en7523.dts (L295)b8dc284d66/target/linux/airoha/dts/en7523.dtsi (L398)Why are the values different?
I fucked up I think.
Lovely, I was getting hangs after 100s of packets. This setting assigns sram over to the fe block. So I guess it get upset because of that.
devmem 0x1fbf9074 that needs to be 3.
Ok, still hangs after a while. Probably has to do with the descriptor allocation/queues.
Ok, 74 -> 0x74 is probably needed.
Ok, much better. Ping seems stable now.
Ok, I'm gonna do some other stuff for the time being. Validate my changes when you get your device.
okay
Ping flood from my computer.
GDMP_DATA_SELto change yep?7147d32347/drivers/net/ethernet/airoha/airoha_eth.c (L504-L510)Yes.
This:
https://econet-linux.pkt.wiki/hardware/EN751221/frame-engine
and the following page 125
https://drive.google.com/file/d/1iZMXhaKoSO1bupRaXUShmNzj9Hj6n9Th/view
describes how things are connected and work.
On the EN7523 it has the WED connected via the GDM3 though and the port indexing has other meanings. But basically there is a PSE with different blocks connected to the PSE ports. And the QDMA is passing packets (descriptors) around.
so it will be something like this
This is the list of ports on the PSE and the component first connected to the port. Other things can be connected after it.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/airoha/airoha_eth.h?h=v6.18-rc4#n114
A somewhat interesting gathering of information.
https://github.com/RuijieNetworksCommunity/openwrt-en75xx/blob/en7562-24.10/en7562ct.md
The router just arrived, I'm going to start building OpenWRT with the patchers to test it, but I'll probably only send the results tomorrow morning (Brazilian time)
Bootlog file: boot_openwrt_2025-11-10_22-10.log
boot_openwrt_2025-11-11_13-16.log
@merbanan i changed this
sportmap and not get moreairoha_eth 1fb50000.ethernet: airoha_qdma_rx_process() free frag:598f0598ee/drivers/net/ethernet/airoha/airoha_eth.c (L624-L651)log
The port mask is 4 bits. It can never hold 0xFFFF. With different SoC configurations I think we should replace it with a table per SoC instead. Then we can load the correct SoC table during init. With 4 bits we only have 16 elements per SoC and a function call gets translated to a lookup table instead.
ping -f 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
.......^C
--- 192.168.1.1 ping statistics ---
1291673775 packets transmitted, 1291673768 received, 5.41932e-07% packet loss, time 176568864ms
rtt min/avg/max/mdev = 0.085/0.118/19.833/0.025 ms, pipe 2, ipg/ewma 0.136/0.127 ms
So I dropped 7 packets during a 2 day ping flood. I think the buffer handling is fine. Just need to route packets in the PSE properly.
No reported drops internally in the PSE either.
Okay, I'll remove the 0xffff, but after I changed that I was able to receive the packets without drops or significant loss when pinging in both directions
#define QDMA_ETH_RXMSG_SPORT_MASK GENMASK(24, 20)
5 bits. Still it should be a table.
0x16,0x17,0x18 are mapped to HSGMII ethernet macs on the EN7523.
The hsgmii wan port sport value is missing and I cant find it. EN7523 have 4 HSGMII MACS.
Maybe add a specific lookup value that prints out unknown sports.
I found these values:
Much of the en7512 code should be compatible.
cjdfound this GPL, which has several/all of the private code, and I also noticed that it is quite similar to some code I found within the xx230v GPLIt probably has something to do with the hsgmii wan port
aea3a43562/tclinux_phoenix/modules/private/ether/en7512/eth_en7512.h (L460-L480)I found this here:
aea3a43562/tclinux_phoenix/modules/private/xpon/inc/pwan/gpon_wan.h (L32-L45)I managed to get a small amount of network traffic, but then it freezes somewhere on airoha_eth
But then it stopped. I've attached the log for you to take a look at if you want
I confirm the issue. ICMP seems to work fine. UDP might also work but TCP has issues.
I compared a working iperf3 tcp setup with a non working and it seems the tcp headers work fine but the payload was different.
tcpdump from device
wireshark from computer
09 != 08
So the tx path has issues with regard to where it collects the tcp packet data.
Do we need to map the TCP here?
83d8f2e66e/drivers/net/ethernet/airoha/airoha_eth.c (L157-L219)No VIP and IFC are filters that are active in the HW accelerated data forwarding path.
83d8f2e66e/drivers/net/ethernet/airoha/airoha_eth.c (L2103-L2105)I have
len = skb_headlen(skb)+4;in my code here.
This gives me properly sized packets but it is a highly dubious change. And it also seems the data is mapped incorrectly. Most likely we have some buffer alignment issue. Maybe the skb->data pointer needs an +4 offset also.
I'll be away from home this weekend, I'll only be able to test it when I get home on Monday
+4 to the data pointer did not work.
Well the transmit function outputs what's in the data buffer.
hexdump in kernel on DUT:
and tcpdump on lan2 on same device
So tcpdump says that the last byte in the skb data should be 09 but the dump of the buffer before transmit says it is 45.
I didn't make much progress today, but the responses on TCP increased, albeit altered
boot_openwrt_2025-11-17_19-16.log
I have been tracing the buffers and the xmit function in the driver gets the same data as higher level transmit functions. It seems the network data buffer is transmitted before the buffer is ready. The TCP header transmission is fine, it is just that the data seems to be ready much later. Can you try with adding some of the linux kernel configuration options from AN7581?
What would they be?
And moving the device out of the bridge makes it work even less.
I can ping from the device but not too the device. I think the change brakes ARP.
Im not sure. I just make a diff between the different kernel configs in the openwrt tree.
I don't think this detachment works on the EN7523; I'm tinkering with it to see if that's the problem.
870b0c8bf0/drivers/net/ethernet/airoha/airoha_eth.c (L1987-L1993)It's strange, but the TCP packets are working, but there's packet retransmission.
So the dump of the skb data buffer in tcp_transmit_skb(), shows different data compared to the output of tcpdump.
Call trace:
[ 213.875713] unwind_backtrace from show_stack+0x10/0x14
[ 213.875737] show_stack from dump_stack_lvl+0x50/0x64
[ 213.875760] dump_stack_lvl from airoha_dev_xmit+0x70/0x890
[ 213.875785] airoha_dev_xmit from dev_hard_start_xmit+0xa4/0xec
[ 213.875808] dev_hard_start_xmit from sch_direct_xmit+0x8c/0x30c
[ 213.875829] sch_direct_xmit from __dev_queue_xmit+0x7e4/0xd7c
[ 213.875847] __dev_queue_xmit from dsa_user_xmit+0x114/0x1a8
[ 213.875870] dsa_user_xmit from dev_hard_start_xmit+0xa4/0xec
[ 213.875890] dev_hard_start_xmit from __dev_queue_xmit+0x200/0xd7c
[ 213.875910] __dev_queue_xmit from br_dev_queue_push_xmit+0x68/0x190
[ 213.875928] br_dev_queue_push_xmit from br_forward_finish+0x90/0x9c
[ 213.875940] br_forward_finish from br_dev_xmit+0x2c4/0x4cc
[ 213.875958] br_dev_xmit from dev_hard_start_xmit+0xa4/0xec
[ 213.875979] dev_hard_start_xmit from __dev_queue_xmit+0x200/0xd7c
[ 213.875999] __dev_queue_xmit from ip_finish_output2+0x1e0/0x700
[ 213.876020] ip_finish_output2 from ip_output+0x4c/0xa0
[ 213.876037] ip_output from __ip_queue_xmit+0x174/0x47c
[ 213.876054] __ip_queue_xmit from __tcp_transmit_skb+0x538/0xbc0
[ 213.876075] __tcp_transmit_skb from tcp_write_xmit+0x36c/0x1764
[ 213.876096] tcp_write_xmit from __tcp_push_pending_frames+0x30/0x10c
[ 213.876117] __tcp_push_pending_frames from tcp_sendmsg_locked+0xa6c/0xcf0
[ 213.876135] tcp_sendmsg_locked from tcp_sendmsg+0x28/0x40
[ 213.876147] tcp_sendmsg from sock_write_iter+0x94/0xe4
[ 213.876167] sock_write_iter from vfs_write+0x3ac/0x42c
[ 213.876190] vfs_write from ksys_write+0x8c/0xc4
[ 213.876208] ksys_write from ret_fast_syscall+0x0/0x4c
I looked at this and while it is not really needed it looks like it does the correct thing.
I installed python and transmitted raw packets. If I remove lan2 from the bridge the package buffer looks very different from what I am trying to transmit.
i noticed that difference too, something I'm experiencing within
airoha_dev_xmit->airoha_get_dsa_tag, the end of the full buffer is completely different.Computer (wireshark):
router in
870b0c8bf0/drivers/net/ethernet/airoha/airoha_eth.c (L1987-L1993)No it looks fine, but it wont transfer.
With DSA active the MTK sp-tag is inserted. And then in the outgoing path it is removed again.
boot_openwrt_2025-11-18_21-03.log
eth0_21_31.pcapng
So the data path works like this. The internal switch is connected to the PSE GDM1 port. The MT7530 switch port 6 is connected to the GDM1 and then port 2 is connected to the world.
When I trace the counters with the bridge down it disables the traffic somehow. If I disable the bridge the packet gets through. So if the bridge is active the interface will not work as the switch will block the traffic.
Now synthetic packets sent towards my computer work fine.
But pinging an ip set on lan2 will not work.
The whole linux network stack just seem broken. If I go out of bridge mode and go directly on the interface I get a direct RST as a response from the TCP connection.
The problem is probably with the DSA working with TCP packets, or something is invalidating the packets in
airoha_eth, TCP and UDP packets are being processed irregularly somewhere in the drivers ofairoha_ethormt7530The sk_buff struct has different length parameters. There might be an issue in the rx path of the driver (airoha_qdma_rx_process).
I did have to adjust the tx path with the +4:
The rx_process might need to get a length value correction also. If the networking stack gets badly formed sk_buffs from the driver then it sort of makes sense that the rest of the stack gets confused.
skb_linearize_cow(skb);
Add that somewhere in the tx path and the correct data should be present.
It worked with SSH, but now we have the problem of processing freezing after the PSE buff runs out.
UDP
TCP
Computer test
Okay, so something I noticed is that I first need to access the router via SSH before I can open any HTTP requests, so something is still not working correctly. However, it is functional; on the local connection, I am getting almost 1 Gbps from the network interface, and my internet speed is almost fully reached (I have 600 Mbps, which is what I get on the main router). Besides that, I haven't had any other problems so far. Another thing is that Flow offloading type as Hardware or Software is very slow for now.
Openwrt:
Computer
Is this necessary, i removed/commented it out and had no more problems with the driver or packages?
480d374450/drivers/net/ethernet/airoha/airoha_eth.c (L490-L493)New iperf test
Computer
Openwrt
wan -> Wireless
TX cant do fragmented skbufs. The dma engine just wont work. So I have to dig into the ref software and setup everything exactly like they do. Then maybe fragmentation starts working.
I dont think it matters until we want to get more speed. I just follow the ref code.
I reverted some changes you made to
airoha_ethand I took a quick test it. Tonight I'll leave iperf running so I can test it, but I find it strange that the upload speed has become so slowdev->hw_features = NETIF_F_IP_CSUM | NETIF_F_RXCSUM |
NETIF_F_TSO6 | NETIF_F_IPV6_CSUM |
NETIF_F_SG | NETIF_F_TSO |
NETIF_F_HW_TC;
If you remove NETIF_F_SG you should get better performance.
It all boils down to a tricky error with the qdma engine. This +4 should not be needed and I am trying to work around that. NETIF_F_SG is a good option to have and it would keep the driver logic mostly the same.
Can you run sys memrl 1FB54018 on ref software?
I'm going to change the rootfs to stock so I can log in via SSH and UART
@merbanan I applied your changes to my code, I don't know why, but when I use
gdmpI lose network traffic with an one SSH connection, then I lose all traffic on both TX/RX, but when I removegdmpmy network traffic becomes completely stable, but with limited upload (computer -> Openwrt || Openwrt -> Internet)I've traced the issue to the switch or phy. The driver is mostly ok.
I changed a few things in DSA and got a slight increase in upload speed.
Patch in DSA
if you look at the traffic in wireshark, is it clean or is there lots of errros ?
My last test with iperf3
Yeah that is the same issue I also have. It looks like it is some kind of switch configuration.
With UDP test
I discarded my changes in the DSA, tested it now without the modifications and it's the same thing, we'll have to look at the PHY
I tried with a 10mbit link and still get bad frames out of the device. I looked at the byte counters and they checked out.
The data path from the cpu is GDM1 tx -> ESW port 6 rx -> ESW port 2 tx.
sh /gsw_diff.sh
Ping
PING 192.168.1.100 (192.168.1.100): 56 data bytes
RXDIFF: 0x62 TXDIFF: 0x62
On working ref I get RXDIFF: 0x62 TXDIFF: 0x66.
So I think the switch configuration has something to do with it.
Today I got the GPL for xx530v v2, it's another SOC from the Econet/Airoha family, not same to v1
AN7551 is a stripped down AN7581.
Ok, I was able to get one proper packet through but then things started to crash. I had to dump all the registers of the ref software internal switch and write them to the openwrt port. I have made alot of changes all over so it will take some time to figure out what is needed.
devmem 0x1fb5b600 32 0x205e33b
That makes the +4 in the tx path redundant.
There are still issues with the passing traffic though. Iperf3 gives bad results.
#define MT753X_PMCR_P(x)
#define MT7530_TXCRC_EN_P6 BIT(26)
#define MT7530_RXCRC_EN_P6 BIT(25)
It is bit 25 that needs to be set somewhere.
devmem 0x1fb5b0ec 32 0x2
#define MT7530_DBGGCR 0x30EC
#define TXFC_LPICHK BIT(5)
#define LPDET_RDYFIX BIT(4)
#define PSON_RDYFIX BIT(3)
#define PSOFF_RDYFIX BIT(2)
#define CPORT_RXG_BUSY BIT(1)
#define TX_LKOFF_ENDCHK BIT(0)
CPORT_RXG_BUSY needs to be set.
Now I get a quite clean steady 100mbit transfer.
And with the revert of some patches i get the following:
iperf3 -c 192.168.1.1 -R -t1000
Connecting to host 192.168.1.1, port 5201
Reverse mode, remote host 192.168.1.1 is sending
[ 5] local 192.168.1.100 port 53064 connected to 192.168.1.1 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 31.0 MBytes 260 Mbits/sec
[ 5] 1.00-2.00 sec 30.4 MBytes 255 Mbits/sec
[ 5] 2.00-3.00 sec 28.0 MBytes 234 Mbits/sec
[ 5] 3.00-4.00 sec 32.2 MBytes 271 Mbits/sec
[ 5] 4.00-5.00 sec 33.3 MBytes 279 Mbits/sec
[ 5] 5.00-6.00 sec 30.8 MBytes 259 Mbits/sec
[ 5] 6.00-7.00 sec 25.3 MBytes 212 Mbits/sec
[ 5] 7.00-8.00 sec 28.0 MBytes 235 Mbits/sec
[ 5] 8.00-9.00 sec 30.9 MBytes 259 Mbits/sec
[ 5] 9.00-10.00 sec 35.6 MBytes 298 Mbits/sec
[ 5] 10.00-11.00 sec 27.6 MBytes 231 Mbits/sec
[ 5] 11.00-12.00 sec 26.6 MBytes 223 Mbits/sec
[ 5] 12.00-13.00 sec 27.6 MBytes 231 Mbits/sec
[ 5] 13.00-14.00 sec 35.1 MBytes 294 Mbits/sec
[ 5] 14.00-15.00 sec 37.8 MBytes 317 Mbits/sec
[ 5] 15.00-16.00 sec 28.6 MBytes 240 Mbits/sec
[ 5] 16.00-17.00 sec 29.7 MBytes 249 Mbits/sec
[ 5] 17.00-18.00 sec 38.7 MBytes 324 Mbits/sec
[ 5] 18.00-19.00 sec 26.1 MBytes 219 Mbits/sec
[ 5] 19.00-20.00 sec 33.7 MBytes 283 Mbits/sec
[ 5] 20.00-21.00 sec 38.5 MBytes 323 Mbits/sec
[ 5] 21.00-22.00 sec 33.0 MBytes 277 Mbits/sec
devmem 0x1fb5b0F0 32 0xFF00
#define MT7530_CKGCR 0x30F0
#define LPI_TXIDLE_THD GENMASK(15, 8)
#define CKG_TXIDLE BIT(5)
#define CKG_RXLPI BIT(4)
#define CKG_LNKDN_PORT BIT(1)
#define CKG_LNKDN_GLB BIT(0)
MT7530_CKGCR should be set to 0xFF00
This does not seem to affect traffic
From what I understand, you did this on the mt7530 driver
I have a messy work tree. But I think this should be enough for the traffic. IRQ routing seems fishy though.
interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
That is the correct irq for the switch. And I was able to get interrupts when connecting/disconnecting ethernet cables in the ports.
I think it should hook up to the same irq handler logic as the EN7581.
That didn't work. Before I left on Friday, I tested it, and there's still a lot of packet loss, so it didn't work.
Command:
iperf3 -c 192.168.2.1 -R -t1000Patch
dts
External iperf server:
iperf3 -c 138.199.4.1 -R -t100Off topic
Hardware offloader on
test 2:
Can you show the boot log and the following:
devmem 0x1fb5b0ec
devmem 0x1fb5b0F0
?
I think these settings are not applied properly.
mt7530-mmio 1fb58000.switch lan2: Link is Up - 100Mbps/Half - flow control offThis sounds bad.
Client:
iperf3 -c 192.168.2.1 -t25 -RI had forced the link to 100mbps on my computer
99% of the time, if you end up with half duplex something is wrong.
What speeds do you get without -R?
1Gbps:
100mbps full
100Mbps half, no traffic
If I switch back to
209, the interrupt will give me those speeds.iperf3 -c 192.168.2.1 -t25 -RWell I would say that this is working quite well. Will you update the openwrt PR with these changes?
I will, but which interrupt should I leave?
31interruptAre you saying that you get slower speeds with the 31 interrupt configured? That should not be possible.
SoC Interrupt 31 should not be triggering at all. Look at /proc/interrupts. If it is triggering then something is fishy with the enabling of interrupts. I validated manually.
What does devmem 0x1FB5F008 say?
When everything is working properly we should get proper interrupts from when something changes with the phy.
[ 64.776455] mt7530-mmio 1fb58000.switch lan1 (uninitialized): PHY [mt7530-0:09] driver [Generic PHY] (irq=POLL)
[ 64.793774] mt7530-mmio 1fb58000.switch lan2 (uninitialized): PHY [mt7530-0:0a] driver [Generic PHY] (irq=POLL)
[ 64.806081] mt7530-mmio 1fb58000.switch lan3 (uninitialized): PHY [mt7530-0:0b] driver [Generic PHY] (irq=POLL)
[ 64.818353] mt7530-mmio 1fb58000.switch wan (uninitialized): PHY [mt7530-0:0c] driver [Generic PHY] (irq=POLL)
These lines should change to real irqs.
Anyway update the PR with the interrupt set at 209 if you dont get it working. I'll pull your changes and look into the issue.
31interrupt:209interrupt:LGTM
I will be finishing the other drivers, and as soon as I'm done I will be pushing them to both repositories
I don't know if this will help, but this is the /proc/interrupts file in stock
Commit:
e526ec1965Stock
offloading enabled
iperf3 -c 192.168.2.1 -t25 -Riperf3 -c 192.168.2.1 -t25offloading disabled
iperf3 -c 192.168.2.1 -t25 -Riperf3 -c 192.168.2.1 -t25Full log
I added the en7523 to
mtk-ge-soc.c, and removed the alterations you requested, but my TCP packets are requesting retransmission, although ICMP is working normallyI dont follow which ips are what and what direction you do things. TCP retransmission is bound to happen if you max out the link somehow.
I only test with the router are 192.168.1.1 and the computer client at 192.168.1.100. I then run iperf3 from the computer.
In either direction, because I can't get TCP/IPv6 from either the OpenWrt side or the computer, only IPv4
The same applies to UDP/IPv6
I thought you had it working. Anyway this is the code I am using +
devmem 0x1fb5b0ec 32 0x2
devmem 0x1fb5b0F0 32 0x0000FF00
devmem 0x1fb5b600 32 0x205e33b
Your mt7530 changes should make the memsets unneeded.
I confirm I get the same speeds as you.
Try disabling
GDMP, this may restore the upload speed.But the code looked ok :( I'll have to debug more tomorrow.
I'll test it with gdmp enabled and disabled
I am so sorry (cant understand it to me this amount of time to find this):
Get rid of that line and you should get ~200mbit tx.
All in all while the code works the complete patch needs to be reworked. I think the MT7530 patches are good to go. For Openwrt I think this type of patch is going to be accept.
Are you up for sending this code up stream?
Also phy irq support is missing. And the dtsi should be cleanup like the an7581.dtsi has been.
I already removed it, so I don't know what it could be
see the pull request (#9)
This is how things are connected in the frame engine on the EN7523.
@merbanan, please clarify something for me, wasn't
irq=POLLsupposed to have been changed?Correct, something must be missing when resolving the irq path, I am guessing it is the MT7530/EN7523 integration code. I am still rebuilding my setup so I can not test yet.
now re-enable NPU
That looks wrong.
NPU Enabled gettings my max speed in https://speed.cloudflare.com/
Well everything is passing via the cpu. NPU should not do anything.
74e58d4a82/econet_public/arch/arm/mach-econet/ecnt_scu.c (L84)74e58d4a82/econet_public/arch/arm/mach-econet/ecnt_scu.c (L1317)I enabled hardware Flow offloading type. Before enabling it, I had 323Mbps Tx and Rx.
These are speed tests I ran on speed.cloudflare.com
if I'm not mistaken, the NPU handles part of the network traffic on the switch and wireless (tx ring)
Check the cpu while doing an iperf test through the device. I am quite sure the NPUs are not involved at all.
You're right, but CPU usage has dropped significantly; it used to be 20-27%, and now it's around 16-22%
Well it seems the hw off-load (eth) is working then. I need to write the tools so we can look at the active ppe rules.
And wifi tx off-load is still within reach.
I'm having problems with the NPU again. The whole system freezes after the interface starts up. If I disable it, it works normally again, but without the NPU and hardware offloading disabled and with the total speed reduced
Well what happens if you only disable the NPU? I think the memory that the npu cores touch is not properly reserved from the os.
If I disable it, the whole system works normally, without system freezing
Yeah, can you test loading the driver but not starting the cores? I think they simply corrupt the kernel internal structures or act on non zeroed buffer memory.
It is very hard to figure out what the issue is in this case. If you are able to find gpio 8/9 you should be able to enable the npu uart mux and see if there is any output from the npu driver. But this is all hard problems. I do have a ref board where I should be able to connect this but I dont see a path forward where this issue is getting fixed by being able to observe the npu uart.
The best way forward imo is to disable the npu for now and focus on the WED implementation. The MT7622 support should be possible to port to the en7523 code.
this boot
Make sure you power cycle the device. The wifi driver npu support might need disabling also.
The mt7915 not have NPU and wed currently in OpenWRT builds, only mt7996
I disabled core boot and had no problem with the NPU, boot log:
I disabled cores 3 and 4 and get the NPU active again, but if I enable cores 3 and 4, the system freezes, and if I enable even core 3, the system freezes before even starting the network interface
core 1, 2 and 3 boot
core 1 and 2 boot
mt76 crashing
[ 7.741737] airoha_wed1: error status=00080000
You need to look in the all the mt76 patches I uploaded to see what is needed for working WED support.
Sirherobrine23 referenced this issue2026-01-24 11:08:02 +00:00
One question, what do I need to do to make the PPE return correct values to
entriesandbind?I looked at the register space for AN7581 and EN7523 and they are very similar. Can you instrument the code and print out the addresses that the code tries to read?
get this with this changes:
There is no ppe2 on the EN7523.
Total amount of forwarding rules are 512 sram and 16k dram.
I've reverted some things here that were accidentally replaced, and I'll revert the information from the PPE
state return this
@merbanan
revert the patchers I had applied to the npu, and today I'm having problems with the Ethernet where the whole system is freezing when I try to access a any website. I haven't tested reverting to last week's commits yet
view video in attachaments
I added patch for calibration for switch and fix dts switch interrups (I misspelled
interrupt, instead ofinterrupts)but now the leds are not blinking and the wan interface is not identifying the connection
If you leave out the calibration part does that help?
I'll see now, first I'll go up to pr commit
Now there is no network traffic at all, but the LEDs are blinking again
Those should not be needed and should be handled by the led configuration of the phy driver.
When I wrote a phy driver for AN7581 I often ended up in a non working state.
Start with just case REXT: and then add modes until it stops working to track down the parts that brakes the data link.
I will be locking this issue for new conversations, let's keep the conversations going in PR #9