one question on this.
If I use your 5.4 branch with Arch Linux will it help with a working wifi as client and AP?
you have to use patches from wifi-branch, not -rc or any other
also you need wmt-tools and maybe my wifi-script for initialization
https://drive.google.com/open?id=15lHk7IEyVyQdYzVfvPvV-3jMhz7GSL7p
simply unpack this after installing dnsmasq and hostapd (any maybe uninstall wpasupplicant if installed)
wmt-tools+script+conf.zip
then adjust conf/script to your ip-configuration (change subnets for interface and dhcp-range)
ap-mode is done by writing A into control-device in script, change this to 1 to get client-mode
I was doing my debugging on OpenWRT so it is possible to have OpenWRT + krenel 5.4 + wifi. But it’s not that simple.
Firstly upstream OpenWRT sticks to using LTS kernels, so it is 4.14 for 18.06.x and 4.19 for 19.x releases. So using other kernel versions requires either a lot of changes/patches to OpenWRT that will be really hard to maintain or building kernel separately from OpenWRT and implanting it into the SD/eMMC. When I need to test new kernels with OpenWRT I stick to second approach.
Secondly, at was already written in this forum several times wifi driver for R2 is a big pile of smelly substance. It does not stick to using normal cfg80211 ways to do things and requires some additional non-standard configuration steps for wifi interfaces to appear. What it means is that we can’t simply use openwrt’s generic cfg80211 support, we will have to patch it somewhat to support R2 wifi driver specifics.
Thirdly, additional configuration steps I mention require using wifi driver specific tools. There’s source code avaialble for these tools so it is possible to compile them for OpenWRT but if we’re talking about “out of the box support” and “good user experience” we would also have to create an opkg package for these utilities.
Bottom line is that while it is certainly possible to implement (pt.2 and 3 are not that hard, pt.1 is but it is not required) I don’t see much profit from having it implemented. It is hard to expect stable wifi experience when we use driver of such quality. There are other more stable wifi hardware options available for R2. So spending time on implementing thing that won’t have much practical sense is something with really low priority on my list of things to do.
@spikerguy you can also extract wifi-patches from 4.14-main and 4.19-main (afair i had already removed feature-branches)
4.14-main:
frank@frank-G5:/media/data_fast/bpi/kernel/BPI-R2-4.14$ git log --oneline -- drivers/misc/mediatek/
4873a180960c (tag: CI-BUILD-20190112215322-4873a180960c) [BT] fix Bluetooth
7f7e9b3aa677 (tag: CI-BUILD-20181123125903-7f7e9b3aa677) mtk wifi: Ensure no NULL refs passed
ee7516478daf (tag: CI-BUILD-20181117140700-ee7516478daf) [wifi] disabled some debug-messages
33570b3aff16 [gcc] gcc8-patch by Dominik Koch
984d46ee9a87 fixed mt6625l using Major-Device-Number of SPI (153 => 155)
f5b5b7516d79 decreasing debug-level of Wifi-driver
124c82243f59 updated defconfig (issue #11), added option in build.sh for changing defconfig
c5b81e053998 changed defconfig (removed some defaults in wlan,added vlan-basics) fixed warning in mtk-combo-driver added branch to kernel-image-name
956607e2f2a2 patches for BT
e6b369a5ade1 merge mt6625l wifi driver
in 4.19 i had splitted driver-folder with changes outside
frank@frank-G5:/media/data_fast/bpi/kernel/BPI-R2-4.14$ git log --oneline -- drivers/misc/mediatek/
c0603006d7f0 (tag: CI-BUILD-20190112215205-c0603006d7f0) [BT] fix Bluetooth
203a5a7727a8 [gcc] gcc8-fixes by Dominik Koch + nic_rx-patch from https://bugs.linaro.org/show_bug.cgi?id=3823
ce8c582c6121 [wifi] adding driver-folder
frank@frank-G5:/media/data_fast/bpi/kernel/BPI-R2-4.14$ git log --oneline -- drivers/watchdog/mtk_wdt.c
0c22407b3b75 (tag: CI-BUILD-20190825_155925-0c22407b3) disable watchdog prints
83ffbaceffed [wifi] adding wifi-related changes outside driver-directoryThank you for the detailed explanation. I agree with you that it is not feasible to maintain it separately.
Currently I was just following the pre-compiled kernel by you. I haven’t gotten time to update my PKGBUILD to build a kernel from your branch. I hope I can give it a try this weekend. As for Arch I try to make whole pkg including boot and kernel. Qemu is too slow thats why I try on the device itself. Ill try to see how i can arrange a fan over the cpu and compile with atleast ‘-j 3’.
Thanks for all the support.
Did you mean qemu-arm userspace + chroot here? If yes - I’m wondering why is it too slow for you. My experience using it - and I use it a lot for compiling stuff targeting Raspberry Pi 1/2/3 and Orance Pi PC - shows that with modern enough CPU (Ryzen 7 2700x for my case) and if you’ve got plenty of ram compiling speed is way faster (like, 3-4x times faster when compiling complex things like linux kernel) under qemu compared to what I got even on considered to be “powerful” ARM boards like RPi3/4.
You have to assign multiple cpu-cores, ram as much as you can and a filesystem on fast storage to get fastest results…
you don’t use my build.sh? It uses multithreading (using x threads for x cpu-cores) by -j
I compile most things natively with crosscompiler without vm…only for some special things like older uboot (is now fixed) i used a vm
Native cross-compiler is a best case scenario w.r.t. speed of compilation. But it might be sometimes tricky next to impossible to get certain software to build in cross-compile environment. Next in line from the speed viewpoint IMO is using qemu-arm-user + chroot on linux system. And trailing are full-blown qemu-based arm VM or compiling natively on the target boards. Things might change as really powerful arm64 boards start to appear on the market like nVIDIA Jetson Nano devboard. New Qualcom arm SoCs also seem to be promising in terms of raw CPU power per watt.
But let’s get back to the thread’s topic. I suspect that this question might be more on a rhetorical side but still: I’m wondering about the origin of this wifi driver code and it’s “upstream/vendor support” status. Looking at it I guess its origin is internal Mediatek’s drivers team and it was initially (and mainly) targeted at Android. And then it seems that codebase was quickly hacked’n’slashed by someone (Sinovoip? Mediatek themselves?) to be able to run more or less fine under linux. My concerns here are that we’re having an affair here with a big pile of looking to be cryptic and unsupported code that we would never be able to transform into upstream-able state. Might it be that there’s some better version of this codebase somewhere out there in the wild (Mediatek linux team maybe?) which would be a better target to spend our efforts on?
yes code is taken from android because chip is designed for smartphones and tv-boxes like the amazon echo (afair dot 2) (i think code is taken from there…it seems very similar)
and modified/ported by garywang (was in bpi-team some time ago) to 4.9 where i picked it up for 4.14 and higher
I’ve found no other driver or any technical document which may allow rewriting the driver
1 Like
That’s unfortunate 
. I believe you were in close contact with Mediatek linux team, don’t you? Maybe it would be possible to ask them if there are any chances in getting at least documentation-wise support to help implement upstream-able driver for the chip? There are upstream drivers for other Mediatek chips in kernel that had been implemented somehow. I wonder what to do from our - power users - side to make it happen for R2 onboard chip too.
Yes qemu in general utilizes full power of the cpu but only use a fracture of it to compile that’s what I have heard for senior devs who I have been working with on compiling kernel for arm devices.
Last when I used my Intel x64 laptop with i7 and 8gb Ram, to compile and package a kernel for manjaro it usual took 10-12 hrs aarch64. And when i compiled the same on thev actual sbc it took only 2 and half hours to compile on ‘-j 4’ while I tried on latest 6core sbc with '-j 6’and it took only 1 and half hours. Since then I always use native device to compile with good heatsink and active cooling like a temporary fan while compiling.
Using the manjaro-arm-tools we extra the rootfs and nspawn into it and compile. Nspawn is chroot on steroid lol that’s what its official introduction says.
As R2 is my first armv7 device I need to compile and package the kernel on it. Hopefully I should make time this coming week and have a stable arch built for it with my repo so next time user I just need to upload latest kernel package from my repo and it should upgrade without having to reflash everything again, thanks to rolling release method.
How much times does it take for you to compile on ryzen?
Test conditions
For tests 1 and 2: compiling under VirtualBox 6.0.12 running on a Windows 10 host with CentOS 7 x86_64 guest. Storage on emulated ICH9 SATA, fixed size VDI stored on the Samsung 970 NVMe SSD. 24GB of RAM and 16 “cores” are assigned to VM performing compilation. Ccache is turned off to measure real compile time.
For test 3: compiling on BPi R2 running Frank’s kernel 4.14 + CentOS 7 AltArch armv7hf-32 userspace. Storage is Kingston Hyper-X 256Mb SATA SSD. Board has heatsink coupled with active cooling attached to its main chip.
Test 1: cross-compiler:
# time ./build-lx2.sh kernel -j8
...
INSTALL net/bluetooth/rfcomm/rfcomm.ko
DEPMOD 5.4.0-rc1-bpi-r2-5.4-wifi
real 4m9.797s
user 24m32.951s
sys 3m25.645s
# ./build-lx2.sh clean
# ./build-lx2.sh kernel -j12
...
DEPMOD 5.4.0-rc1-bpi-r2-5.4-wifi
real 4m4.098s
user 24m15.441s
sys 3m26.028s
Test 2: qemu-arm-static + raspbian chroot:
# time ./build-native-lx2.sh -j16
...
DEPMOD 5.4.0-rc1-bpi-r2-5.4-wifi
real 29m39.971s
user 206m4.247s
sys 8m57.999s
Test 3: compiling on BPi R2
To be updated: compile process started at the same moment as test 2. Test 2 had finished about 5 minutes ago while on R2 process is still ongoing and from emitted messages (filenames being compiled) it looks like it is about half-completed. Will post results later when done.
Preliminary conclusions
Nothing surprising really. Cross-compiler running in native environment is a fastest one which you would expect comparing horsepower of 2nd gen Ryzen 2700X with mobile-grade CPU we’ve got in R2. Qemu userland arm-static is way slower compared to cross-compiler which is again not that surprising - compiling process implies a lot of new process startups which is the most costly operation for binfmt-invoked qemu-user emulation. Speed is 30 minutes vs 4 minutes for cross-compiler, i.e. it’s more than 7x times slower. Still it is faster than compiling on the board itself which makes it viable choice if project you’re compiling don’t play well with cross-compiling. What is left to be determined is the difference in speed between BPi R2 with 4 core ARM CPU and 4GB of RAM vs qemu-arm-static userland running on 8 core Ryzen 2700X with 24GB of RAM. Speed of the storage may be treated as approx the same for the conditions of the test as for both cases it is a pretty fast SSD which is not a limiting factor here.
Test 3 Results:
# time ./build-native-lx2.sh kernel -j4
...
DEPMOD 5.4.0-rc1-bpi-r2-5.4-wifi
real 63m25.571s
user 225m18.085s
sys 13m45.945s
Conclusions
qemu-arm-static for test conditions outlined above is 2x+ times faster compared to compiling on the board itself. Both qemu and native compiling on the board are hugely slower (like 7x+ and 15x+) than cross-compiling on the same hardware.
1 Like
Back to topic…
Found out that huawei mediapad t3 also uses this chip,but did not yet found driver in source
But it’s also android (7) where i guess it also uses kernel 3.18, driver package seems to be the BG2-W09, which is same driver…
So it means driver is also targeted at android so in best case scenario it will be the same thing we’ve got now on hands and more probable is that it won’t compile for linux at all as you mentioned that @garywang had modified/ported Android driver to linux 4.4/4.9 as a first step. Oh well, it might be a proper thing then to at least take sources we’ve got and patch them to be buildable as an out-of-tree module (the same way it is done in linux kernel backports thing). Building it as a module is in any case a hard requirement if we want it to work with openwrt - they do use out of tree 80211n stack from backports so to have this driver working in openwrt with stock openwrt kernel it needs to be a module linked with backports cfg80211n.
i also think that workung on (my) current codebase will be the best we can do and enable module building and tidy up. Here are you more expert.
I currently fighting with r64 uboot and emmc (but i think i found the problem…have to make some tests after patching mmc-driver)
Can I use any pre-compile kernel from your git with a working wifi ? If so then which one? Also advice which branch should I use in case I want to compile it on my own with a working wifi and stable version? I plan to build a new image for Arch Linux this week.
Please advice. Thanks.
Precompiled only for 4.14 and 4.19. All others need to be compiled (-wifi branch)
if you want to try last wifi-enabled kernel: https://github.com/frank-w/BPI-R2-4.14/tree/5.4-wifi
1 Like
Thanks creating a PKGBUILD for this, Will try to compile kernel along with boot 
Will put it on my repo maybe so just updating the kernel from the repo can keep the OS updated
Thanks for your work.