I apologize for that! There’s also no mention of this limitation on Bananapi’s webpages, so it might “just” be on mainline.
Indeed the rabbit hole goes deeper. There’s this new thread over at Armbian where they looked into this issue (limited WiFi speed on BPi CM4 with the built-in rtl8822cs) and got it into the 100s of mbit/s: Slow WiFi speeds on Banana Pi CM4 - Banana PI CM4-IO - Armbian Community Forums
So I’ll look tomorrow what we can learn from that. If I do cat /sys/kernel/debug/mmc2/ios
it really is at 25MHz and 3v3 signalling, while according to the thread it’s possible to run it at 200MHz 1v8.
This would indeed be very promising. I will gladly test the changes on my device, if you have them ready.
OK I did the following tests so far, with the built-in WiFi on the A311D module (BPi CM4):
Mainline Driver
- Bumped the
max-frequency
of the&sd_emmc_a
node in the dts to 200MHz instead of 25MHz, and thevqmmc-supply
voltage to 1v8:
&sd_emmc_a {
/* ... */
cap-sd-highspeed;
sd-uhs-sdr50;
sd-uhs-sdr104;
max-frequency = <200000000>;
/* ... */
vmmc-supply = <&vddao_3v3>;
vqmmc-supply = <&vddao_1v8>;
}
- Added a post-power-on delay to
sdio_pwrseq
. According to the thread above this is necessary for stable 200MHz operation. But I will also test if 100MHz suffices:
sdio_pwrseq: sdio-pwrseq {
/* ... */
post-power-on-delay-ms = <200>;
};
- Removed the
amlogic,dram-access-quirk;
from the same node inmeson-g12.dtsi
. I will confirm again later if this is really necessary.
With only these devicetree changes, the mainline rtw88_8822cs driver already performs a lot better, I could get up to 54mbit/s down on Speedtest, and the random stalls seem to be gone. So I’ll look into the most stable combination of the above and we can include that in one of the next kernel package updates.
Alternative Driver
There’s also an alternative (vendor) driver here: GitHub - jethome-ru/rtl88x2cs: TRY RTW88 IN-KERNEL DRIVER FIRST ** Repo for rtl88x2cs driver
This driver compiles without changes on the device itself (just clone and make
). After that, I unloaded the mainline driver by doing sudo rmmod rtw88_8822cs
(and for good measure also all other rtw88_… modules).
Then, one can load this alternative driver:
insmod ./rtl88x2cs.ko
To my great surprise, I was then able to achieve 84mbit/s download rate on Speedtest.
I have forwarded these findings to Martin Blumenstingl who is working on the mainline driver—they said that there is still potential for optimizing it.
@moep I have pushed a patch that should improve the Wi-Fi speed on A311D. You can try it by doing sudo apt update
and sudo apt upgrade
(or just upgrading the kernel package) and rebooting. Do you get better speeds then?
You can also confirm that the update is in place by doing: cat /sys/kernel/debug/mmc2/ios
after a reboot to see if it is running at 100 MHz.
@minute this indeed already made a huge difference almost doubling the throughput to 50 Mbit/s.
I am willing to try even faster speeds
I think this is the max for the mainline driver, but not sure. Can you give the alternative driver a try (linked above)?
Hrm… I just backported the kernel with your new patches for bookworm and tested it on my A311D classic Reform and I cannot confirm your findings. I do not have the alternate driver loaded:
[josch@reform] ~ % lsmod | grep rtw88_8822cs | wc -l
3
[josch@reform] ~ % lsmod | grep rtl88x2cs | wc -l
0
But still my download speeds are far beyond 54 mbit/s:
I mean… I’m not complaing…
Here is a diff of my /sys/kernel/debug/mmc2/ios
before and after:
--- before 2024-09-16 23:11:13.336265391 +0200
+++ after 2024-09-17 05:59:56.490316523 +0200
@@ -1,10 +1,10 @@
-clock: 25000000 Hz
-actual clock: 25000000 Hz
+clock: 100000000 Hz
+actual clock: 99999999 Hz
vdd: 21 (3.3 ~ 3.4 V)
bus mode: 2 (push-pull)
chip select: 0 (don't care)
power mode: 2 (on)
bus width: 2 (4 bits)
-timing spec: 0 (legacy)
-signal voltage: 0 (3.30 V)
+timing spec: 6 (sd uhs SDR104)
+signal voltage: 1 (1.80 V)
driver type: 0 (driver type B)
This cannot be a difference between classic Reform and Pocket Reform because both have the A311D in it, no?
I just picked up a thermal pad to try this. Has it worked out in the mid-to-long term so far?
As for me, I have total of three thermal pads in place, one that came installed for the CPU, one I placed for WiFi module and the last one I have placed for power module.
These placement seems to keep WiFi going for days, so far. I do not plan to change unless there is new finding.
Thanks. Can I trouble you to identify the chips (Power module, and Wifi) that these need to go on top of, so that I can place them correctly? I haven’t had mine open since I put the Mvne drive in, and I’m not sure how obvious it’ll be for me.
I have thermal pads on the red rectangle marked chips in the photo below.
I do not know if this is a correct approach or not, but this strategy seems to be working for me.
Awesome, thank you. I’ll be trying this out tomorrow.
Wanted to note here that I’m getting acceptable results (~25Mbps) with a311d, the asiarf wifi card, and the antennas (Molex 208482) that came in the a311d upgrade kit (plugged into the asiarf card, naturally). I also ordered the ezurio atennas, I’ll report back when I install them.
I’ve also kept the stock antenna (Molex 146153) in-place and connected it to the a311d antenna connector furthest from the a311d chip. This provides noticeably better bluetooth than before, presumably because it’s not attempting to do bluetooth and wifi on the same ICs and antennas.
Did you mean MBps or Mbps as 25 Mbps would be not acceptable for a card that is capable of dual chain ac in the 5 GHz band. Even with overhead the net data rate should be around 270 Mbps. Even only with 2,4 GHz and 20 MHz channel width it should be much more than 25 Mbps.
I mean Mbps. This is worse but not dramatically worse than speedtest results from other devices I use day-to-day on my network. I’m sure there is a large number of other relevant factors, I suspect upgrading the antenna will help, and I’m sure you and I have different definitions of acceptable!
The MediaTek card from AsiaRF plus two Ezurio antennas gives me a nice 400Mbps, when the antennas are positioned correctly and the top case stays open a bit. Once its closed, it drops down to 200Mbps, but thats workable. There seems to be some periodic speed problem, but that might as well be my wifi in general.
tl;dr: antenna placement is crucial. Probably a bit more experimentation could yield drastic improvements.
Seems it was not really related to pads. There are locations where the WiFi locks up most of the time, locations where it is mostly OK for days but then keeps locking up for half a day or so, and then it’s OK again.
Installing the pads takes time so it’s likely that the problem is gone after installation when it’s temporary one.
Probable cause of lockups is some specific external condition like signal quality together with bug in driver/firmware.
While poor signal is a thing the driver/firmware also locks up preventing connection even when the signal quality improves.
Reloading the qcacld2 driver (in /opt, requires insmod -f) makes it possible to connect in situation when connection was not possible before.