Banana Pi BPI-R4 BPI-BE14 Wi-Fi7 NIC module

Banana Pi Router design BPI-R4(MT7988)
203

I guess something went wrong with bundling the bin files there.

root@bpi-r4:/lib/firmware/mediatek/mt7996# ls -alh /lib/firmware/mediatek/mt7996/
total 3.0M
drwxr-xr-x  2 root root 4.0K Jun 16 09:49 .
drwxr-xr-x 12 root root 4.0K Aug 20  2024 ..
-rw-r--r--  1 root root    0 Aug 20  2024 mt7996_dsp.bin
-rw-r--r--  1 root root 7.5K Aug 20  2024 mt7996_eeprom.bin
-rw-r--r--  1 root root    0 Aug 20  2024 mt7996_eeprom_233.bin
-rw-r--r--  1 root root  23K Aug 20  2024 mt7996_rom_patch.bin
-rw-r--r--  1 root root    0 Aug 20  2024 mt7996_rom_patch_233.bin
-rw-r--r--  1 root root 504K Aug 20  2024 mt7996_wa.bin
-rw-r--r--  1 root root    0 Aug 20  2024 mt7996_wa_233.bin
-rw-r--r--  1 root root 2.5M Aug 20  2024 mt7996_wm.bin
-rw-r--r--  1 root root    0 Aug 20  2024 mt7996_wm_233.bin

EDIT: added it manually and sadly the patch does not fix the issue it seems

EHT bw <= 80 MHz, max NSS for MCS 8-9: Rx=3, Tx=3
EHT bw <= 80 MHz, max NSS for MCS 10-11: Rx=3, Tx=3
EHT bw <= 80 MHz, max NSS for MCS 12-13: Rx=3, Tx=3
EHT bw=160 MHz, max NSS for MCS 8-9: Rx=3, Tx=3
EHT bw=160 MHz, max NSS for MCS 10-11: Rx=3, Tx=3
EHT bw=160 MHz, max NSS for MCS 12-13: Rx=0, Tx=0
EHT bw=320 MHz, max NSS for MCS 8-9: Rx=0, Tx=0
EHT bw=320 MHz, max NSS for MCS 10-11: Rx=0, Tx=0
EHT bw=320 MHz, max NSS for MCS 12-13: Rx=0, Tx=0

To be sure:

root@bpi-r4:~/mt7996# uname -a
Linux bpi-r4 6.10.0-bpi-r4-main #10 SMP Tue Aug 20 20:26:27 UTC 2024 aarch64 GNU/Linux

should be from after the patch was applied, correct?

1 Like
204

oh, seems that curl does not download the files completely…maybe some kind of redirect edit: yes, curl needs -L param to follow redirects…pushed it, pipeline is finished

maybe some more patches are needed… maybe this (only searched the patches in dir for HT)? https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/refs/heads/master/autobuild/autobuild_5.4_mac80211_release/mt7988_wifi7_mac80211_mlo/package/kernel/mt76/patches/0010-mtk-mt76-mt7996-fix-EHT-Beamforming-capability-check.patch

how should the output look like?

btw. i saw that firmware was updated, but without much comment if 2+3+3 is supported…i will ask for it and report back

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/?id=2ebe7d63331e371fac638aae1a117940fac5d66c

i saw also that some patches are sent to upstream

https://patches.linaro.org/project/linux-wireless/list/?series=248597

205

Yeah, I’m also curious about this. In short, do we need some patches in OpenWRT to enable mt7996 or we can just rename/make symlink for the firmware files to files with _233.bin and it will work?

Also I spotted new firmware is available for mt7996 - kernel/git/firmware/linux-firmware.git - Repository of firmware blobs for use with the Linux kernel (linux-firmware: update firmware for MT7996 - kernel/git/firmware/linux-firmware.git - Repository of firmware blobs for use with the Linux kernel)

206

Good afternoon @Franco W. I know that you have to compile it yourself every time you make an image, I did it before with libreelec and coreelec, so it will be similar here, I am currently struggling with the image you shared

bpi-r4_bookworm_6.10.0-main.img.gz

I had problems with yours @schuschu and I have left it aside.

I am a complete novice who is trying to get used to Debian and later Ubuntu.

I come from OpenWrt and Windows and there I know how to handle all the files and configurations perfectly, but this is very different.

Thank you all for your support, I hope to slowly understand and compile it myself.

207

Could be that more patches are needed but which one of the 199 is the question. I am somewhat tempted to try to build the kernel module out of tree and see if it actually loads (not sure if your 6.10-mt76 also uses openwrt’s code or what that branch is referring to).

What I see with the mtk vendor SDK build (not SinoVoip with MP4.0, just MediaTek) is this (which means for all MCS levels up to QAM4096 aka MCS13 I have up to 3 spatial streams/NSS

EHT bw <= 80 MHz, max NSS for MCS 8-9: Rx=3, Tx=3
EHT bw <= 80 MHz, max NSS for MCS 10-11: Rx=3, Tx=3
EHT bw <= 80 MHz, max NSS for MCS 12-13: Rx=3, Tx=3
EHT bw=160 MHz, max NSS for MCS 8-9: Rx=3, Tx=3
EHT bw=160 MHz, max NSS for MCS 10-11: Rx=3, Tx=3
EHT bw=160 MHz, max NSS for MCS 12-13: Rx=3, Tx=3
EHT bw=320 MHz, max NSS for MCS 8-9: Rx=3, Tx=3
EHT bw=320 MHz, max NSS for MCS 10-11: Rx=3, Tx=3
EHT bw=320 MHz, max NSS for MCS 12-13: Rx=3, Tx=3

Although I may have used the rootfs that came with my BPi R4 (the block2mtd hack they are using to run jfffs2 of an sdcard seems to need a patch which meant that I am not 100% certain what firmware version was running when that iw list was taken.

208

It seems that EHT issue is fixed with patch series above…can you try to remove the single patch above and apply full series?

Wait for confirmation that new firmware supports 233 variant too,so we can drop the 233 patch and testing firmware

209

Good morning, yesterday I got the latest version of Ubuntu that was in the wiki files on a card that I saved, so I can access the menu via UART to be able to do the installation. Right now my son is preparing Ubuntu for me, which will not be installed anywhere, but it will be ready.

Since you use the Debian branch, I will then prepare a card for my son to leave ready to be able to do the installation.

Thanks for your advice, I will also try to do my compilations, but I am sure that they will be of very little contribution on my part since I am a newbie, both in Debian and in Ubuntu.

210

I applied the patch series (Linux wireless - Patchwork) against your pre EHT fix commit (a5f209f3f88daf5bacaab883ca30d16d88ff0506) using the firmware from mediatek (autobuild/autobuild_5.4_mac80211_release/package/kernel/mt76/src/firmware/mt7996 - openwrt/feeds/mtk-openwrt-feeds - Gitiles). The same firmware did not cause a crash before so this is not helping I guess.

[  378.077684] mt7996e_hif 0001:01:00.0: vgaarb: pci_notify
[  378.093610] mt7996e_hif 0001:01:00.0: assign IRQ: got 114
[  378.109800] mt7996e_hif 0001:01:00.0: enabling bus mastering
[  378.126733] mt7996e_hif 0001:01:00.0: vgaarb: pci_notify
[  378.142721] mt7996e 0000:01:00.0: vgaarb: pci_notify
[  378.157607] mt7996e 0000:01:00.0: assign IRQ: got 111
[  378.172755] mt7996e 0000:01:00.0: enabling bus mastering
[  378.266741] mtk-pcie-gen3 11300000.pcie: msi#0x1 address_hi 0x0 address_lo 0x11300c00 data 1
[  378.292070] mtk-pcie-gen3 11310000.pcie: msi#0x1 address_hi 0x0 address_lo 0x11310c00 data 1
[  378.336895] mt7996e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20240809122254a

[  378.451241] mt7996e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20240809122249
[  378.507647] mt7996e 0000:01:00.0: DSP Firmware Version: ____000000, Build Time: 20240809121650
[  378.543296] mt7996e 0000:01:00.0: WA Firmware Version: ____000000, Build Time: 20240809122214
[  378.947736] mt7996e 0000:01:00.0: registering led 'mt76-phy1'
[  378.965615] ------------[ cut here ]------------
[  378.979424] WARNING: CPU: 1 PID: 4885 at net/wireless/core.c:668 wiphy_register+0x3e8/0x998 [cfg80211]
[  379.007303] Modules linked in: mt7996e(+) mt76_connac_lib mt76 mac80211 libarc4 cfg80211 fuse ip_tables x_tables [last unloaded: mt7996e]
[  379.044256] CPU: 1 PID: 4885 Comm: modprobe Not tainted 6.10.0-bpi-r4 #1
[  379.064286] Hardware name: Banana Pi BPI-R4 (DT)
[  379.078074] pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  379.098883] pc : wiphy_register+0x3e8/0x998 [cfg80211]
[  379.114262] lr : ieee80211_register_hw+0x768/0xc64 [mac80211]
[  379.131468] sp : ffffffc0834235e0
[  379.141356] x29: ffffffc0834235e0 x28: 0000000000000000 x27: 000000000000000e
[  379.162688] x26: 0000000000000001 x25: 000000000000000c x24: ffffffc079a1a998
[  379.184019] x23: ffffffc0799f73d8 x22: 0000000000000005 x21: 0000000000000001
[  379.205351] x20: ffffff80084e0000 x19: ffffff80084e03c0 x18: ffffffffffffffff
[  379.226682] x17: 000000003aced0ce x16: 000000000f7a9162 x15: 0000000000000001
[  379.248014] x14: ffffff8008e09100 x13: 00000000000001c4 x12: 0000000000000001
[  379.269345] x11: 0000000000000000 x10: 0000000000000002 x9 : 0000000000000064
[  379.290676] x8 : 0000000000000000 x7 : 0000000000000013 x6 : 0000000000000000
[  379.312007] x5 : 0000000000000001 x4 : ffffffc079afb4f8 x3 : ffffffc079afb4f0
[  379.333338] x2 : ffffffc079afb4c8 x1 : 0000000000000002 x0 : ffffffc079afb4b0
[  379.354669] Call trace:
[  379.361956]  wiphy_register+0x3e8/0x998 [cfg80211]
[  379.376295]  ieee80211_register_hw+0x768/0xc64 [mac80211]
[  379.392453]  mt76_register_device+0x180/0x3c8 [mt76]
[  379.407289]  mt7996_register_device+0x62c/0x6ec [mt7996e]
[  379.423436]  mt7996_pci_probe+0x334/0x5d0 [mt7996e]
[  379.438017]  pci_device_probe+0xa0/0x144
[  379.449733]  really_probe+0xc0/0x38c
[  379.460402]  __driver_probe_device+0x7c/0x15c
[  379.473411]  driver_probe_device+0x40/0x110
[  379.485899]  __driver_attach+0xf4/0x1fc
[  379.497347]  bus_for_each_dev+0x74/0xd0
[  379.508795]  driver_attach+0x24/0x30
[  379.519463]  bus_add_driver+0x110/0x234
[  379.530912]  driver_register+0x60/0x128
[  379.542359]  __pci_register_driver+0x44/0x50
[  379.555110]  mt7996_init+0x70/0x1000 [mt7996e]
[  379.568390]  do_one_initcall+0x44/0x260
[  379.579840]  do_init_module+0x60/0x220
[  379.591031]  load_module+0x1d20/0x1de4
[  379.602220]  init_module_from_file+0x84/0xc4
[  379.614968]  __arm64_sys_finit_module+0x20c/0x344
[  379.629015]  invoke_syscall+0x48/0x118
[  379.640207]  el0_svc_common.constprop.0+0x40/0xe8
[  379.654257]  do_el0_svc+0x20/0x2c
[  379.664148]  el0_svc+0x34/0xdc
[  379.673258]  el0t_64_sync_handler+0x13c/0x158
[  379.686266]  el0t_64_sync+0x194/0x198
[  379.697195] ---[ end trace 0000000000000000 ]---
[  379.766973] mt7996e 0000:01:00.0: probe with driver mt7996e failed with error -22
[  379.789396] mt7996e 0000:01:00.0: vgaarb: pci_notify
211

Since the patches are now in openwrt, however, I can verify that todays snapshot works correctly.

     EHT MAC Capabilities (0x0300):
             NSEP priority access Supported
             EHT OM Control Supported
     EHT PHY Capabilities: (0xea6d927e20600c7e):
             320MHz in 6GHz Supported
             NDP With  EHT-LTF And 3.2 µs GI
             SU Beamformer
             SU Beamformee
             Beamformee SS (80MHz): 3
             Beamformee SS (160MHz): 3
             Beamformee SS (320MHz): 3
             Number Of Sounding Dimensions (80MHz): 2
             Number Of Sounding Dimensions (160MHz): 2
             Number Of Sounding Dimensions (320MHz): 2
             Ng = 16 SU Feedback
             Ng = 16 MU Feedback
             Codebook size (4, 2) SU Feedback
             Codebook size (7, 5) MU Feedback
             Triggered SU Beamforming Feedback
             Triggered MU Beamforming Partial BW Feedback
             Max Nc: 2
             Common Nominal Packet Padding: 2
             Maximum Number Of Supported EHT-LTFs: 17
             Support of MCS 15: 1
             Non-OFDMA UL MU-MIMO (80MHz)
             Non-OFDMA UL MU-MIMO (160MHz)
             Non-OFDMA UL MU-MIMO (320MHz)
             MU Beamformer (80MHz)
             MU Beamformer (160MHz)
             MU Beamformer (320MHz)
     EHT MCS/NSS: (0x33333333333333333300000000):
     EHT bw <= 80 MHz, max NSS for MCS 8-9: Rx=3, Tx=3
     EHT bw <= 80 MHz, max NSS for MCS 10-11: Rx=3, Tx=3
     EHT bw <= 80 MHz, max NSS for MCS 12-13: Rx=3, Tx=3
     EHT bw=160 MHz, max NSS for MCS 8-9: Rx=3, Tx=3
     EHT bw=160 MHz, max NSS for MCS 10-11: Rx=3, Tx=3
     EHT bw=160 MHz, max NSS for MCS 12-13: Rx=3, Tx=3
     EHT bw=320 MHz, max NSS for MCS 8-9: Rx=3, Tx=3
     EHT bw=320 MHz, max NSS for MCS 10-11: Rx=3, Tx=3
     EHT bw=320 MHz, max NSS for MCS 12-13: Rx=3, Tx=3```

EDIT: works correctly may be wrong, its 6GHz and 2.4GHz for the interfaces, not sure where my 5GHz went...
212

Possibly the new firmware does not support the 233 yet,or it has not yet pulled the latest version yet…i guess you use mainline,right?

213

yes I just took your 6.10-main branch and checked out before the last commit (the EHT one).

EDIT: openwrt is just todays snapshot so yeah main but I guess I now have to borrow some EHT patches for hostapd since that is still not in openwrt -.-

214

I played around with today’s snapshot which includes the patches and latest firmware and found the following:

Applying the two patches from the ongoing ath12k support (Add ath12k - WCN7850 - opensource driver/firmware support by januszdziedzic · Pull Request #15945 · openwrt/openwrt · GitHub) and manually openwrt’s scripts to generate the hostapd.conf with a hammer I finally have it…

root@OpenWrt:~# iw dev phy1-sta0 station dump
Station 9e:ad:b7:2b:4f:3d (on phy1-sta0)
        inactive time:  4230 ms
        rx bytes:       18875197
        rx packets:     23817
        tx bytes:       29013546
        tx packets:     25615
        tx retries:     804
        tx failed:      804
        beacon loss:    0
        beacon rx:      1074
        rx drop misc:   0
        signal:         -45 [-49, -50, -48] dBm
        signal avg:     -44 [-48, -50, -47] dBm
        beacon signal avg:      -44 dBm
        tx bitrate:     3843.1 MBit/s 320MHz EHT-MCS 9 EHT-NSS 2 EHT-GI 0
        tx duration:    8214725 us
        rx bitrate:     2594.0 MBit/s 320MHz EHT-MCS 4 EHT-NSS 3 EHT-GI 0
        rx duration:    2195435 us
        last ack signal:-46 dBm
        avg ack signal: -45 dBm
        airtime weight: 256
        authorized:     yes
        authenticated:  yes
        associated:     yes
        preamble:       long
        WMM/WME:        yes
        MFP:            yes
        TDLS peer:      no
        DTIM period:    2
        beacon interval:100
        short slot time:yes
        connected time: 115 seconds
        associated at [boottime]:       45.388s
        associated at:  1724350689782 ms
        current time:   1724350801451 ms```

3 spatial streams, using ETH over 320MHz (sadly over the current distance only MCS below the new QAM4096, this log is from the client but server is of course the same, both BPi R4).

root@OpenWrt:~# iperf3 -c 192.168.1.1 -t 3600
Connecting to host 192.168.1.1, port 5201
[  5] local 192.168.1.232 port 36568 connected to 192.168.1.1 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  3.25 MBytes  27.2 Mbits/sec    0    165 KBytes
[  5]   1.00-2.00   sec  3.12 MBytes  26.2 Mbits/sec    0    198 KBytes
[  5]   2.00-3.00   sec  3.00 MBytes  25.2 Mbits/sec    0    198 KBytes
[  5]   3.00-4.00   sec  3.00 MBytes  25.2 Mbits/sec    0    198 KBytes
[  5]   4.00-5.00   sec  3.00 MBytes  25.2 Mbits/sec    0    198 KBytes
[  5]   5.00-6.00   sec  2.88 MBytes  24.1 Mbits/sec    0    198 KBytes
[  5]   6.00-7.00   sec  3.00 MBytes  25.2 Mbits/sec    0    198 KBytes
[  5]   7.00-8.00   sec  2.75 MBytes  23.1 Mbits/sec    0    198 KBytes
[  5]   8.00-9.00   sec  3.00 MBytes  25.2 Mbits/sec    0    198 KBytes
[  5]   9.00-10.00  sec  3.00 MBytes  25.2 Mbits/sec    0    198 KBytes
[  5]  10.00-11.00  sec  3.00 MBytes  25.2 Mbits/sec    0    198 KBytes
[  5]  11.00-12.00  sec  3.00 MBytes  25.2 Mbits/sec    0    198 KBytes
[  5]  12.00-13.00  sec  2.88 MBytes  24.1 Mbits/sec    0    198 KBytes
[  5]  13.00-14.00  sec  3.00 MBytes  25.2 Mbits/sec    0    198 KBytes
[  5]  14.00-15.00  sec  3.00 MBytes  25.2 Mbits/sec    0    198 KBytes
[  5]  15.00-16.00  sec  3.00 MBytes  25.2 Mbits/sec    0    198 KBytes
[  5]  16.00-17.00  sec  3.00 MBytes  25.2 Mbits/sec    0    198 KBytes
[  5]  17.00-18.00  sec  3.00 MBytes  25.2 Mbits/sec    0    198 KBytes
[  5]  18.00-19.00  sec  3.00 MBytes  25.2 Mbits/sec    0    198 KBytes
[  5]  19.00-20.00  sec  2.88 MBytes  24.1 Mbits/sec    0    198 KBytes

I think there is something wrong here, as adding a monitor mode interface reveals I am still sending in 802.11a (OFDM) instead. Using a Intel B200 as client gives me 400Mbps in one direction (Intel sending) but still, fairly terrible.

On the plus side, in HE mode (WiFi 6e) I can confirm its doing well so maybe its the things I did to openwrt to enable BE/EHT support

- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]  85.00-86.00  sec  75.8 MBytes   635 Mbits/sec
[  7]  85.00-86.00  sec  77.6 MBytes   651 Mbits/sec
[  9]  85.00-86.00  sec  65.9 MBytes   553 Mbits/sec
[ 11]  85.00-86.00  sec  61.2 MBytes   514 Mbits/sec
[SUM]  85.00-86.00  sec   280 MBytes  2.35 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -

As you can see, iperf3 now manages about 2.35Gbps using 4 processes (number of cpus) and TCP.

Can anyone tell me if this makes sense (added a perfectly fine hostapd.conf from openwrt, well the channel was replaced) as per https://www.spinics.net/lists/hostap/msg12298.html:

ieee80211be=1
channel=37
op_class=137
he_oper_centr_freq_seg0_idx=31
eht_oper_centr_freq_seg0_idx=47
215

updated firmware seems not supporting the 2-3-3 variant yet as i get a trace when i try to load it

[   16.285424] mt7996e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20240809121753
[   16.330776] mt7996e 0000:01:00.0: DSP Firmware Version: ____000000, Build Time: 20240809121650
[   16.374227] mt7996e 0000:01:00.0: WA Firmware Version: ____000000, Build Time: 20240809121718
[   16.758458] mt7996e 0000:01:00.0: eeprom load fail, use default bin
[   16.766004] mt7996e 0000:01:00.0: registering led 'mt76-phy0'
[   16.772394] ------------[ cut here ]------------
[   16.777019] WARNING: CPU: 2 PID: 2939 at net/wireless/core.c:668 wiphy_register+0x3b0/0x8d4 [cfg80211]
[   16.786365] Modules linked in: mt7996e(+) mt76_connac_lib mt76 mac80211 libarc4 cfg80211 fuse ip_tables x_tables
[   16.796545] CPU: 2 PID: 2939 Comm: systemd-udevd Not tainted 6.10.0-bpi-r4-mt76_eht #1
[   16.804451] Hardware name: Banana Pi BPI-R4 (DT)
[   16.809057] pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   16.816007] pc : wiphy_register+0x3b0/0x8d4 [cfg80211]
[   16.821166] lr : ieee80211_register_hw+0x708/0xc30 [mac80211]
[   16.826936] sp : ffffffc084d335f0
[   16.830239] x29: ffffffc084d33640 x28: 0000000000000001 x27: 0000000000000000
[   16.837367] x26: 000000000000000e x25: 000000000000000c x24: 0000000000000005
[   16.844493] x23: ffffffc079a1ba60 x22: ffffffc0799f8448 x21: 0000000000000001
[   16.851618] x20: ffffff80123c0000 x19: ffffff80123c03c0 x18: ffffffffffffffff
[   16.858743] x17: 00000000a53707a1 x16: 000000005037c37e x15: 0000000000000000
[   16.865868] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000002
[   16.872993] x11: 7f7f7f7f7f7f7f7f x10: 0000000000000064 x9 : 0000000000000000
[   16.880119] x8 : 0000000000000013 x7 : 0000000000000000 x6 : 0000000000000001
[   16.887244] x5 : ffffffc079afe4c8 x4 : ffffffc079afe4f8 x3 : 0000000000000000
[   16.894368] x2 : ffffffc079afe4f0 x1 : 0000000000000002 x0 : ffffffc079afe4b0
[   16.901495] Call trace:
[   16.903931]  wiphy_register+0x3b0/0x8d4 [cfg80211]
[   16.908743]  ieee80211_register_hw+0x708/0xc30 [mac80211]
[   16.914161]  mt76_register_device+0x164/0x2d4 [mt76]
[   16.919120]  mt7996_register_device+0x614/0x6f8 [mt7996e]
[   16.924527]  mt7996_pci_probe+0x33c/0x5d4 [mt7996e]
[   16.929406]  pci_device_probe+0x9c/0x140
[   16.933325]  really_probe+0xc0/0x390
[   16.936891]  __driver_probe_device+0x7c/0x15c
[   16.941238]  driver_probe_device+0x3c/0x110
[   16.945410]  __driver_attach+0xf0/0x1f8
[   16.949235]  bus_for_each_dev+0x78/0xd8
[   16.953064]  driver_attach+0x24/0x30
[   16.956629]  bus_add_driver+0x110/0x234
[   16.960456]  driver_register+0x5c/0x124
[   16.964282]  __pci_register_driver+0x4c/0x58
[   16.968542]  mt7996_init+0x70/0x1000 [mt7996e]
[   16.972988]  do_one_initcall+0x44/0x260
[   16.976816]  do_init_module+0x60/0x21c
[   16.980559]  load_module+0x1f3c/0x206c
[   16.984300]  init_module_from_file+0x88/0xcc
[   16.988559]  __arm64_sys_finit_module+0x1a0/0x388
[   16.993252]  invoke_syscall+0x48/0x114
[   16.996994]  el0_svc_common.constprop.0+0xc0/0xe0
[   17.001689]  do_el0_svc+0x1c/0x28
[   17.004997]  el0_svc+0x34/0xd8
[   17.008046]  el0t_64_sync_handler+0x120/0x12c
[   17.012391]  el0t_64_sync+0x194/0x198
[   17.016043] ---[ end trace 0000000000000000 ]---
[   17.055646] mt7996e 0000:01:00.0: probe with driver mt7996e failed with error -22
[   17.063145] mt7996e 0000:01:00.0: vgaarb: pci_notify

added EHT-patches and reverted the 233 firmware file selection

root@bpi-r4-v11:~ 
# uname -a
Linux bpi-r4-v11 6.10.0-bpi-r4-mt76_eht #1 SMP Fri Aug 23 11:42:49 CEST 2024 aarch64 GNU/Linux
216

From what I can tell OpenWRT mt76/firmware at master · openwrt/mt76 · GitHub does not contain the 2-3-3 firmware we are currently using in Debian, so I assume the firmware is fine, the driver side is the issue. I do get the same crash when I load the 2-3-3 firmware with the 12 patches applied (and your patch for the eeprom selection still in place)

EDIT: maybe we are lacking patches? I am terrible at reading stack dumps but could it be something like [RESEND] wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he - Patchwork

217

Oh,have not tested this yet,need to do that

WARN_ON (no null pointer deref) happens in wiphy_register while probe,i guess some field required there is not filled correctly.

and i can confirm it happens too when loading the 233 firmware

tested 6.11-rc5…233 firmware works, new firmware has same issue as old one (only 2 wifi-interfaces and message timeouts), warning also happens there with EHT patches

219

I just got my wifi 7 nic card, got it installed, moved the switch, wifi card lights up installed openwrt, installed Luci, but the wifi interface doesnt show up at all, what am I doing wrong??

20240827_175816
20240827_1758161920×865 88.2 KB

220

Openwrt does not have yet support for be14 because we have only a test firmware

You find both patches here

In openwrt you have to patch mt76 package instead of kernel version. Then put firmware files to right folder (/lib/firmware/mediatek/mt7996/)

221

Right now OpenWrt (at least snapshot but since @mangus17 mentioned that he had to install Luci I assume that is what he is using) has the patches in their mt76 and firmware (already included by default) such that the card at least shows up but of course there is no WiFi 7 (i.e., 802.11be support in hostapd or Luci). At least it worked as WiFi 6E card last used the snapshot (6 days ago, see above).

@Mangus17 if you install pciutils and run lspci, does the card show up for you?

222

In my tests (6.11-rc5) the (updated) mainline firmware did not support be14…maybe openwrt did some workaround? Testing firmware i use for be14 cannot be added to official openwrt master tree (license unclear)

223

For all OpenWRT users: Here is a first “working” build that can be adapted by you => [Banana BPI-R4] Wifi7 status - #82 by danpawlik - For Developers - OpenWrt Forum

Did this with my steup and got a working 2-3-3 WiFi6 solution. As already mentioned, no WiFi7 support in OpenWRT right now due to missing commits in hostapd (https://w1.fi/cgit/hostap/plain/hostapd/ChangeLog).

1 Like