i have no problem with wifi7, except that the signal strength is not the best, running openwrt snapshot. but the wifi strength is no problem for me coz i live in a small 2 room flat 
when it comes to support and software... i assume all chinese manufacturers give a sh*t about the software, have a look at rk3588 :> would be such nice hardware but .. the software is so extremely bad that FOSS devs create that now for mainline, since 2 years or so... its china hardware. wonderful specs but the software... jesus. those hardware pieces could be so nice if the producers would bring some effort into mainlining their stuff
Yeah, perhaps not. Someone talked about the potential to use either CAKE or fq_codel with the hardware offloading on one of these modern network SoCs recently, but I don’t remember if it was regarding the MT7988A or Qualcomm’s similar offering.
I haven’t seen a need for that regardless, but I figured it could be an awesome feature if it was indeed possible. The possbility of using HW QoS is also pretty nice though, so this is a nice step forward regardless. 
I have a question regarding the USB port of the BPI-R4:
- It seems that it only supports USB 2.0 speed (Hi-Speed, ~40 MiB/s). Why?
- The Sinovoip / BananaPi docs clearly say USB 3.2 (which is, according to the MT7988A datasheet, slang for USB 3.2 Gen 1, ~5 Gbit/s). So does the (official, taken from these docs) image the seller of the board used.
- lsusb shows two “xhci-hcd” xHCI Host Controllers. One should be integrated into the M.2 Key B slot, which can support either PCIe 3.0 x 1 or USB 3.2, but not both at the same time. The other should be the USB-A socket at the rear side of the board. So on the software side, the usb host controllers and drivers seem to be properly in place.
I used the following “fio” command to test this with an external USB SATA drive plugged in (which works fine on my PC, reaching speeds of ~5 Gbit/s):
fio --rw=write --name=IOPS-write --bs=1024k --direct=1 --filename=/dev/TESTDEVICE --numjobs=4 --ioengine=libaio --iodepth=32 --refill_buffers --group_reporting --runtime=60 --time_based
==> Does anyone know what’s up?! My board revision is v1.1 and I’m starting to get the feeling this port is actually just a USB 2.0.
Did you try running lsusb -t? It would show the current device bitrate.
Roger that, Houston:
lsusb -t
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci-mtk/1p, 480M
|__ Port 001: Dev 002, If 0, Class=[unknown], Driver=hub/5p, 480M
|__ Port 004: Dev 003, If 0, Class=[unknown], Driver=cdc_acm, 12M
|__ Port 004: Dev 003, If 1, Class=[unknown], Driver=cdc_acm, 12M
|__ Port 005: Dev 004, If 0, Class=[unknown], Driver=[none], 480M
/: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci-mtk/1p, 20000M/x2
|__ Port 001: Dev 002, If 0, Class=[unknown], Driver=hub/4p, 5000M/x2
This is with a different stick (Zigbee) insertet at the moment, but the hub is clearly 480M.
I’m using the current OpenWRT stable.
Is this just me, or can other people confirm? It effectively cripples the USB port and is very different from what was advertised. I want to confirm whether this is misconfiguration on my side or a hardware problem.
Looking at the schematic, the external USB 3.2 hub is connected to both USB 2.0 and USB 3.2 root hubs.
Here’s my SSD enclosure (bottom line) seen as connected to the USB 3.2 root hub. I only got ~340 MB/s of linear throughput, but this JMicron chip doesn’t seem to play nicely with other Filogic+OpenWrt systems too.
root@home-rt-edge-1 ~ # lsusb -t
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci-mtk/1p, 480M
|__ Port 001: Dev 002, If 0, Class=[unknown], Driver=hub/5p, 480M
|__ Port 001: Dev 003, If 0, Class=[unknown], Driver=cdc_mbim, 480M
|__ Port 001: Dev 003, If 1, Class=[unknown], Driver=cdc_mbim, 480M
|__ Port 001: Dev 003, If 2, Class=[unknown], Driver=option, 480M
|__ Port 005: Dev 004, If 0, Class=[unknown], Driver=[none], 480M
/: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci-mtk/1p, 20000M/x2
|__ Port 001: Dev 002, If 0, Class=[unknown], Driver=hub/4p, 5000M/x2
|__ Port 004: Dev 003, If 0, Class=[unknown], Driver=uas, 5000M
Which of the devices in your lsusb listing is the ZigBee stick? See if the external drive ends up connected to the 480M or 20000M root hub.
Oh, this seems to be drive-specific! oO Let’s do this thoroughly:
When I tried with my USB-C M.2 enclosure (which contains a M.2 SATA drive), connected via a small USB-C-to-A adapter, I got the following output:
lsusb -t
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci-mtk/1p, 480M
|__ Port 001: Dev 002, If 0, Class=[unknown], Driver=hub/5p, 480M
|__ Port 004: Dev 006, If 0, Class=[unknown], Driver=uas, 480M
|__ Port 005: Dev 004, If 0, Class=[unknown], Driver=[none], 480M
/: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci-mtk/1p, 20000M/x2
|__ Port 001: Dev 002, If 0, Class=[unknown], Driver=hub/4p, 5000M/x2
The speed was about ~40 MB/s:
hdparm -Tt --direct /dev/sda
/dev/sda:
Timing O_DIRECT cached reads: 84 MB in 2.01 seconds = 41.73 MB/sec
Timing O_DIRECT disk reads: 126 MB in 3.02 seconds = 41.73 MB/sec
With a USB-stick (directly, meaning no enclose, no cables, no adapter - just a regular stick drive) I get this reported instead:
lsusb -t
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci-mtk/1p, 480M
|__ Port 001: Dev 002, If 0, Class=[unknown], Driver=hub/5p, 480M
|__ Port 005: Dev 004, If 0, Class=[unknown], Driver=[none], 480M
/: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci-mtk/1p, 20000M/x2
|__ Port 001: Dev 002, If 0, Class=[unknown], Driver=hub/4p, 5000M/x2
|__ Port 004: Dev 003, If 0, Class=[unknown], Driver=usb-storage, 5000M
Using a simple hdparm speed test yields ~150 MB/s!
hdparm -Tt --direct /dev/sda
/dev/sda:
Timing O_DIRECT cached reads: 282 MB in 2.01 seconds = 140.61 MB/sec
Timing O_DIRECT disk reads: 446 MB in 3.00 seconds = 148.46 MB/sec
Just to be sure, let’s do this with a classic 2.5” spinning hard drive in an Icybox USB 3-capable enclosure, again using the USB-C-to-A adapter:
lsusb -t
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci-mtk/1p, 480M
|__ Port 001: Dev 002, If 0, Class=[unknown], Driver=hub/5p, 480M
|__ Port 004: Dev 008, If 0, Class=[unknown], Driver=uas, 480M
|__ Port 005: Dev 004, If 0, Class=[unknown], Driver=[none], 480M
/: Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci-mtk/1p, 20000M/x2
|__ Port 001: Dev 002, If 0, Class=[unknown], Driver=hub/4p, 5000M/x2
Speed test:
hdparm -Tt --direct /dev/sda
/dev/sda1:
Timing O_DIRECT cached reads: 80 MB in 2.00 seconds = 39.95 MB/sec
Timing O_DIRECT disk reads: 54 MB in 3.11 seconds = 17.36 MB/sec
My conclusion: The §&$$$&! bastard USB-C-to-A mini adapter seems to not route all the pins, therefore forcing the USB hub to fall back to 2.0 speed! 
This appears to be a classic case of “shitty adapter ruins the day”.
Sorry for wasting everyone’s time! (and greetings from Germany to Germany, I see )
Just for my personal interest, what’s everyone’s speed record on the USB port? (I got nothing faster than my usb stick, which yields ~150 MB/s)
Not to Germany, it’s just the nickname. But regardless, greetings to you too. 
Actually, it’s good to know something like this could happen in a multi-root topology. Thank you for your testing.
Did you try to rotate the USB-C cable? Many if these USB-A to -C adapters will only work properly in one position.
Dear Banana users, I'd like to ask:
What's the current system stability situation with the MT7915 and MT7925 modules? If I order them from AliExpress and install OpenWrt 24.10.5, will I have any issues with system stability, signal noise, and range, or are there any other issues I should be aware of?.
The MT7925 has limited functionality in AP mode. Among other things, it does not support DFS, so there is no 160 MHz in the 5 GHz band. 6 GHz does not work either.
Then what would you recommend me? A be14 board + a patch for it or something else?
NO 
→ Please do not buy the current BE14 board from Banana Pi (it has noise issues that can reduce Wi-Fi range).
- There will be a successor to the BE14:
https://forum.banana-pi.org/t/bpi-be14-wi-fi7-nic-module-first-picture-of-the-upcoming-revised-be14/26485
If you really want it, wait for the new one…
In general, it depends on your needs:
- You mentioned the AW7915 from AsiaRF (Wi-Fi 6).
- It’s described as working (you may also want to consider the AW7916):
https://asiarf.com/product-category/wi-fi/wi-fi-module/wi-fi-mini-pcie/
Or you switch to Wi-Fi 7 APs:
- AW7990 (I’m not saying you should do that!)
Sticking with MediaTek modules is probably the easiest path.
There will also be Compex modules… but that won’t get any easier.
Oh yeah, you should know I'm a complete newbie to mini computers, but I'm actually interested in this topic. I just need a powerful mini PC like a router. There's no answer to the question why, I just need one. I'm bored.
I also don't know what the right thing to do is find fully working WiFi modules for this PC, but as I see it, there are a ton of problems. I need someone to tell me if I'm using this or that module, whether it has these or those problems, or not. But so far, I've learned that the BE14 board is a very bad product.
PS: So, regarding the AW7915, AW7916, and AW7990, will they work immediately after installing OpenWRT 25.10.5, or do I need to know something else?
tbh, banana is only good for sfp/lan but i would def stay away from it for any wifi related.
if you are bored then do like me → buy some merinos AP poe compatible (mr 30-42-52-74) with openwrt and hack them.
they are rock solid without issue with wifi 
And they are rock solid with MT7916 and MT7915E modules (and without original metal housing) - WiFi 6 is working just as it should be.
It is 24.10.5, and for MT7916 there is a bug concerning 6GHz you need to know how to handle (https://github.com/openwrt/openwrt/issues/17632). I don't know anything about AW7990 as I don't have one installed in my environment.
Do you need a router or a mini pc? Likely better options for the later...
Hello, I’m also dealing with latest openwrt images to burn them directly into emmc (without success by now).
Question about your procedure, after using the immortalwrt gpt tables I got this partition table (by the way you can use blockdev --rereadpt /dev/mmcblk0 to reread partition table and this way use partition devices instead of seek argument):
# lsblk -b --output NAME,SIZE,TYPE,PARTLABEL /dev/mmcblk0
NAME SIZE TYPE PARTLABEL
mmcblk0 7818182656 disk
├─mmcblk0p1 524288 part ubootenv
├─mmcblk0p2 2097152 part factory
├─mmcblk0p3 4194304 part fip
├─mmcblk0p4 33554432 part recovery
├─mmcblk0p5 314572800 part production
└─mmcblk0p128 4176896 part
So the command you used for flashing the bl31-uboot.fip has bs=512 seek=13312 which will point to recovery partition (512*13312=6815744 which is 524288+2097152+4194304).
Any advise on that? doesn’t seem it’s ok, but honestly I couldn’t make it work yet. Neither flashing it in the correct place.
nw, I was finally able to make it work. Wrote a procedure for OpenWRT here
Anyone else having issues with some SFP+ modules on 25.12? My DAC to my switch is fine, but the RJ45 adapter (I know, but my ISP only allows RJ45 connections to their ONT and I cannot replace it) is throwing errors. Downgrading to 24.10.5 immediately fixes it.