I’m always using OpenWrt Snapshot (master branch currently with kernel 6.12).
(I won’t use any other kernels)
do you have also the other 2 patches applied? in sdk there are still all 3
I don’t know what other 2 patches you’re referring to.
In OpenWrt Snapshot (master branch kernel-6.12), many MTK patches are missing for 6.12. So to begin with any interesting porting work for me, I had to port some “fundamental patches” (many patches like close to 50+). Otherwise, compile will fail. You can find what patches I ported in the BIG thread over OpenWrt forum.
I think only two patches mentioned in this thread are needed for 9K support unless compile fails.
I gave it the last chance a moment ago and seems a quick profit.
The Root Cause
mt7530 driver was initialised faster than mtk_eth_soc driver. Hence, conduit->max_mtu is default, ~1500. mtk_eth_soc tried to and did initialise max_mtu to 9K with the MTK patches but was too late. Hence, the nonfatal error messages on startup:
mt7530-mmio 15020000.switch: nonfatal error -34 setting MTU to 1500 on port 0
mt7530-mmio 15020000.switch: nonfatal error -34 setting MTU to 1500 on port 1
mt7530-mmio 15020000.switch: nonfatal error -34 setting MTU to 1500 on port 2
mt7530-mmio 15020000.switch: nonfatal error -34 setting MTU to 1500 on port 3
Change mt7530 drivers to modules work for me in OpenWrt Snapshot. And I think it’ll work for you in stock kernel too (wrt eliminating the nonfatal errors on startup), @frank-w
For OpenWrt Snapshot, there is an extra hurdle, mt7530 drivers are always built-in by default. Let’s see what I ended up with later.
I think my contribution on this issue will stall here for the time being.
HTH
See my branch i linked…the first 9k patch needs another as base. I thought you use upstream openwrt with only the 9k patches,but it sounds like you use the mtk sdk too.
Using mt7530 driver as module will break functionality in tftp tests. Just to ignore non-fatal errors? If your 9k tests are positive with these errors then i have to find out difference to your codebase. And it is not this non-fatal error.
No. It’s not MTK SDK. It’s OpenWrt Snapshot with a small hand-picked subset of MTK patches.
What tftp tests? Please elaborate.
I suggested one solution that I think it will work (and works for me). Other people are welcome to suggest alternative solutions.
I can’t perform any 9k tests. I don’t have 9k usage setup. As I said at the beginning, 9k is not important for me. I’ve already spent more time than I should on this issue.
Which patches? Maybe i miss some? But I’m working on mainline linux tobhave a chance for upstreaming the changes.
I do most tests via tftp to not install kernel hundrets of times to sdcard with everytime removing and inserting the card.
But it was working (you could set mtu at least) for you also with the non-fatal warnings,right? So Module only fixes these warnings
I shared mtk patches in this big thread: A new dual 10G router based on Filogic 880 (Banana Pi BPi-R4) - #1250 by kvic - Hardware Questions and Recommendations - OpenWrt Forum
Was absent for a year in that thread. Rejoined around October. Mostly me posting. Should be easy to spot all relevant patches.
I know I know. As I suggested to you on the other day, get familiar with OpenWrt and starting porting to OpenWrt first to quickly get familiar with a patch. Trivial effort as Mtk patches are based on OpenWrt. Then port it to vanilla Latest kernel.
Mt7530 driver as a module won’t cause any problem in such scenarios.
It didn’t cause me any problems so far.
(Posted from phone. Formatting might not be right)
And i already responded that this will not solve the problem not knowing which patches are needed for some function. Why should i change openwrt to then porting again to vanilla linux? I see patches in openwrt and sdk and start porting.
It does because module is then not part of the kernel. I know you thinking about loading full openwrt over tftp,but this is independ of my way where i just load the itb for building and downloading time reasons.
If we do not port needed patches to mainline, openwrt devs have to port them again and again and no other user can use them. If we port and send to mainline all users have the benefit. Openwrt devs have less to port and other users can use features too.
So please tell me:
- can you set mtu to more than 1500 on mac and dsa ports?
- how exactly (iproute2),maybe need to increase cpu port before user port?
- which patches have you applied to your codebase exactly? There are sone links to sdk patches,but it is unclear how your codebase looks like. I also found no openwrt code repo in your github.
- you can help me getting necessary things into linux but please do not tell me that i should use openwrt.
Perhaps u need time to wrap around your head. Your existing workflow looks super inefficient to me. How many patches you upstreamed in the past year?
All included in OpenWrt sysupgrade.itb so it’s you-problem.
I can’t recall how many times l’ve upgraded over tftp in the past two months. Many many time.
Yes. Hence, enthusiasts or perhaps ‘subsidized ’ contributors should have a super efficient workflow. Either drive mtk or yourself to upstream patches as many and fast as possible.
“Hear, hear” I vote for mainline linux, for the obvious reasons.
But not for fit or itb…
1 Like
I guess more than you…
i’m a bit further…as the max-mtu is set in mtk-open (currently increased MTK_MAX_RX_LENGTH_9K to 9728 as chatgpt suggests 
), i have to first set the mac to up before i can set the mtu. my previous attempt was in thinking port must be down for setting mtu.
# ip link set eth2 mtu 9000 up
Error: mtu greater than device maximum.
root@bpi-r4-v11:~
# ip link set eth2 up
[ 81.110502] mtk_soc_eth 15100000.ethernet eth2: configuring for inband/usxgmii link mode
[ 81.131844] mtk_soc_eth 15100000.ethernet eth2: mtk_open: set max-mtu of mac #2 to 9702 (9K+XGMII)
root@bpi-r4-v11:~
# [ 82.797432] mtk_soc_eth 15100000.ethernet eth2: PHY [i2c:sfp1:11] driver [RTL8221B-VB-CG 2.5Gbps PHY (C45)] )
ip link set eth2 up[ 82.867423] mtk_soc_eth 15100000.ethernet eth2: switched to inband/2500base-x link mode
root@bpi-r4-v11:~
# ip link set dev eth2 mtu 9000
root@bpi-r4-v11:~
#
same for lan3 (dsa-port):
root@bpi-r4-v11:~
# ip link set eth0 up
[ 39.581306] mtk_soc_eth 15100000.ethernet eth0: configuring for fixed/internal link mode
[ 39.589491] mtk_soc_eth 15100000.ethernet eth0: mtk_open: set max-mtu of mac #0 to 9702 (9K+XGMII)
[ 39.589520] mtk_soc_eth 15100000.ethernet eth0: Link is Up - 10Gbps/Full - flow control off
root@bpi-r4-v11:~
# ip -d link show dev eth0
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 12:1d:a9:8e:54:fb brd ff:ff:ff:ff:ff:ff promiscuity 1 allmulti 0 minmtu 68 maxmtu 9702 addrgenmod
root@bpi-r4-v11:~
# ip link set dev lan3 mtu 9000
root@bpi-r4-v11:~
#
3 Likes
But I think you’re paid for the job while I’m not. No?
Also majority of your upstreams in 2025 are DTS changes which are very low hanging fruit. If you’re really paid for the job, you need to do better than that.
Lol, no i do all in my free time.
And yes dts is not such complex,but this are only the parts i upstreamed lately, not other things i did which are not upstreamed yet e.g. debugging for R4Pro,RSS/LRO,where most parts are not visible to users.
What is your contribution here? Posting links to sdk is not coding too 
i don’t see any benefit of your postings & harassing people off topic and always putting injury on your words is just depressing.
2 Likes
And your post is not beneficial to anybody except you’re personally attacking me. Perhaps you should live up to your own words.
My apologies to anyone who felt I’m harassing him/her. Not my intention and I’ll stop.
I do agree even technical communication is not effective on this forum. It seems there is language barrier or people just didn’t understand what other side is talking about.
@rmandrad was pointing me to some (network) patches in past similar to you in your linked openwrt thread.
Can we please come back to topic?
In the meantime i tested the jumbo-patches. I can set mtu to 9000 (max-mtu is set on interface-up,imho it would be better doing this in probe if possible), but do not get traffic working after that. Mtk told me that “network” needs to be restarted to reallocate the rx buffers (i will try link down/up later). Then i try to find out how we can do the necessary parts in change_mtu callback.