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
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?
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.
# 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
# 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
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.
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.
# 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
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.
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
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.
Frank, I spent some time toying with the driver code we’ve got on hands.
Please take a look at this PR:
Thank you very much for your help.Does it now work as module?
Well, it is mixed experience. I hadn’t hit any explicit driver bug/problem when running as module compared to running built-in. But it looks like there’re some kernel memory corruptions happening occasionally when running as a module which mainly manifest themselves as fake ext4 errors being detected causing root file system to be remounted read-only. Finding the cause for this one would be a nightmare I guess.
oh, thats bad…does it also happen when builtin after your modifications? any idea how to debug this?
this problem in my head i think it’s better to clean code a bit…have posted some other comments
frank-w in kernel build bpi-r2_5.4.0-rc5-merged wat features are supported ?