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

Thanks for the results, my cards made a detour back to china so I still cant test myself. Any chance you can test the “MLO Alpha Release” (assuming any of your client cards actually work with MLO)?

To remove the variable of your ISP/forwarding, you could run iperf3 on the Banana Pi (say iperf3 -s) and then measure directly from your client (iperf3 -c [IP]). It is also possible to use more than one concurrent TCP connection (e.g., -P 8 for 8 connections).

@frank-w do you know if the upstream mediatek code for the filogic880 runs on the Banana Pi as is or if one would have to start with the Sinovoip repo

Mainline misses some patches, when using daniels or my repo bananapi r4 works so far,but without rss/lro. Wifi card needs at least a patch i have in my repo and special firmware (both in my 6.10-rc branch),maybe more is needed for full support.

So if you want to use all features so far you need to use sinovoips version with the caveat that it is old and it’s hard to add newer drivers.

Sorry, upstream was not quite the right word here ^^. What I mean is, that in addition to sinovoip, mediatek also maintains a git which seems still based on the outdated openwrt 21.02 (it is the basis for sinovoips work after all), but unlike sinovoip they claim that MLO is “working” and from a quick glance there is a build target for the Banana Pi.

I am just not sure what the difference between the git repos from mediatek and sinipoip is other than that the latter seems 5 months old and include a patches for 2.5G ethernet.and the older mt7916 (i.e., asiarf) cards.

My Intel mini pc should support MLO I could do the test if anyone can find a link to the “MAC80211 MT76 Programming Guide v4.0”.

I tried iperf3 but it gives slow results (1Gbps) using as many concurrent connections as the number of threads.

i guess your phys are not initialized yet completely (because of missing patch/firmware for be14)

with both above (and of course hwmon/-thermal enabled) i get this with my board:

# cat /sys/class/ieee80211/phy0/hwmon4/temp1_input
# cat /sys/class/ieee80211/phy1/hwmon5/temp1_input
# cat /sys/class/ieee80211/phy2/hwmon6/temp1_input

wildcard-command also works

# cat /sys/class/ieee80211/phy*/hwmon*/temp1_input

addded patch+firmware to my 6.10-rc tree to allow wider testing

Is latest openwrt snapshot bpi r4 contain driver for be14 wifi 7 module ?

I completely agree with all your arguments. And the most annoying thing is that they simply begin to ignore everyone who asks too many clarifying questions. In principle, I am ready to wait, but then I would like my 2 QCA9880 to work as a temporary solution. Why they don’t work is unclear. No answers either

1 Like

Openwrt team working on supporting the module and underlaying wifi7 support,next release 24.x should include it


Where do i add the firmware & patches if you don’t mind me asking?

I added them to build_dir, but they seem to get overridden at build time, and staging_dir only shows the original mt7996 .bin files

afair you need to add them to the source (target/linux/mediatek/…), there must ne a patches-x.y dir…but i do not use openwrt so cannot help much here

1 Like

you can add the firmware either after installing to SD (in /lib/firmware/mediatek) or add them to $OPENWRT/files/lib/firmware/mediatek, where $OPENWRT is your build dir - but later one is discouraged. When you change something and do a make, those (binary) files that are changed will be overwritten. So if you change sources, it should produce the new binary files without extracting any archive over the changed file(s), but i am not 100% sure if there is not some sort of checksum-testing.

Kernel patches must be applied like frank-w said in target/linux/mediatek/patches-6.6

edit: just tested it myself. when you modify e.g. ./build_dir/target-aarch64_cortex-a53_musl/linux-mediatek_filogic/linux-6.6.35/drivers/net/wireless/mediatek/mt76/mt7996/init.c and execute make, it deletes those changed files and extracts the linux archive again. i know there was some sort of command like make kernel or make packages/kernel, but cant remember. this only recompiled the kernel without touching anything else.

edit #2: when changing sources, you need to use make target/linux/compile and make package/kernel/linux/compile instead of make only. When using the first two commands, changes to sources will be applied.

Patching in openwrt is a bit tricky (thats one of the main reasons i do not use it). It uses mainline mt76 not the one from linux kernel…so you have to add patch to the mt76 package somehow.

Thank you! I will give this a try, placing the firmware in lib/firmware/mediatek didnt work for me either when i tried, that was doing both methods via files in make and using scp once the device was booted.

Would it be possible to reiterate the throughput test while measuring the power consumption?

Is it currently possible to install a driver in openwrt to make the be14 wifi card work or maybe there is an image with driver to install from the manufacturer’s website to test this card?

The 233 firmware is only loaded with the mt76 patch…we currently try to find an easier way to add it to the source tree

And please make sure you connect at least antenna cables before starting the wifi-interface

Here is the power graph captured at 100sps with a FNIRSI FNB48S from when I plug the usb-c to the time I do the speedtest (the 14W peak). Note that I have a 10G ethernet SFP and a DAC to my ISP box connected to the R4. I also got a new speed record of 3248Mbps / 273Mbps during this run.

Power graph

1 Like

I’m trying to add Frank’s patch here but my devices can’t see the networks. The leds for each band are also off.

Some iperf3 tests from MP4 bpi image

Accepted connection from, port 49519
[  5] local port 5201 connected to port 49520
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  18.0 MBytes   151 Mbits/sec                  
[  5]   1.00-2.00   sec  14.2 MBytes   119 Mbits/sec                  
[  5]   2.00-3.00   sec  12.4 MBytes   104 Mbits/sec                  
[  5]   3.00-4.00   sec  14.6 MBytes   123 Mbits/sec                  
[  5]   4.00-5.00   sec  15.0 MBytes   126 Mbits/sec                  
[  5]   5.00-6.00   sec  14.5 MBytes   122 Mbits/sec                  
[  5]   6.00-7.00   sec  15.0 MBytes   126 Mbits/sec                  
[  5]   7.00-8.00   sec  14.5 MBytes   122 Mbits/sec                  
[  5]   8.00-9.00   sec  14.8 MBytes   124 Mbits/sec                  
[  5]   9.00-10.00  sec  15.3 MBytes   128 Mbits/sec                  
[  5]  10.00-10.04  sec   621 KBytes   126 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.04  sec   149 MBytes   124 Mbits/sec                  receiver

Accepted connection from, port 49515
[  5] local port 5201 connected to port 49516
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  78.8 MBytes   661 Mbits/sec                  
[  5]   1.00-2.00   sec  79.2 MBytes   664 Mbits/sec                  
[  5]   2.00-3.00   sec  85.7 MBytes   719 Mbits/sec                  
[  5]   3.00-4.00   sec  97.3 MBytes   816 Mbits/sec                  
[  5]   4.00-5.00   sec  85.1 MBytes   714 Mbits/sec                  
[  5]   5.00-6.00   sec   102 MBytes   858 Mbits/sec                  
[  5]   6.00-7.00   sec   118 MBytes   988 Mbits/sec                  
[  5]   7.00-8.00   sec   117 MBytes   979 Mbits/sec                  
[  5]   8.00-9.00   sec   120 MBytes  1.01 Gbits/sec                  
[  5]   9.00-10.00  sec   121 MBytes  1.02 Gbits/sec                  
[  5]  10.00-10.01  sec  1.52 MBytes  1.05 Gbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.01  sec  1006 MBytes   843 Mbits/sec                  receiver

Accepted connection from, port 49517
[  5] local port 5201 connected to port 49518
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   134 MBytes  1.13 Gbits/sec                  
[  5]   1.00-2.00   sec   141 MBytes  1.18 Gbits/sec                  
[  5]   2.00-3.00   sec   141 MBytes  1.19 Gbits/sec                  
[  5]   3.00-4.00   sec   143 MBytes  1.20 Gbits/sec                  
[  5]   4.00-5.00   sec   139 MBytes  1.17 Gbits/sec                  
[  5]   5.00-6.00   sec   137 MBytes  1.15 Gbits/sec                  
[  5]   6.00-7.00   sec   140 MBytes  1.17 Gbits/sec                  
[  5]   7.00-8.00   sec   140 MBytes  1.17 Gbits/sec                  
[  5]   8.00-9.00   sec   140 MBytes  1.17 Gbits/sec                  
[  5]   9.00-10.00  sec   139 MBytes  1.17 Gbits/sec                  
[  5]  10.00-10.02  sec  2.87 MBytes  1.22 Gbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.02  sec  1.36 GBytes  1.17 Gbits/sec                  receiver

Have not added led support yet…only support for the testing firmware…wonder why it does not work for you…daniel reports me that it does work so far.

Finally also got my 2 cards, I have not had the time to compile openwrt with patches for the 3 interfaces (and I guess I would still not get EHT mode in openwrt as it is?) but using the MP4 image I can confirm the “bug” of only seeing 1Gbps but at least I managed to test with a 10G SFP cable and its not iperf3 (almost the full 10G are reached).

Can anyone using a current openwrt snapshot with franks patches confirm they get higher numbers (I had ~1.5 with the devices next to each other like this using two mt7916 cards).