BenCranston

I don't have a v7 board to test on, but thanks for the work. will this get pulled into the nightly armbian kernel builds?

@Pali Yes! The patches are working great for me. I ended up switching to the beta kernel builds and got them that way. Trying to build the kernel with the Arabian tools and incorporate the patches was beyond me. I see the cpu actively switching between the various clock rates and the performance test indicate I'm getting 1GHz clock now. Things have been really stable with no trouble to report.

Sweet. thanks. building kernel from your source tree now.

@Pali I'd love to test. Is there a process I should be following to get these patches installed? I've setup the armbian build environment and can create the installation packages, but not sure how to apply patches into that for testing. Thanks for the help.

I know the OP is talking about leveraging the video acceleration, so I wanted to throw in a few of my experiences... For a faster desktop experience (which is not what I understand is the focus of Armbian) you want to install the fbturbo_drv Xorg driver. Instructions for that can be found here: http://linux-sunxi.org/Xorg This works with or without the Cedar and MALI drivers. Typical desktops used on ARM platforms don't use compositing and therefore get no real boost from these drivers. the Cedar (vdpau) driver is the one for accelerated video playback. It uses the NEON functions. T

Absolutely! As it turns out my issue (I'll argue the driver still has a *bug* but will 100% concede it has nothing to do with Arabian or your excellent built) was that my access point was allowing for the legacy 802.11b data rates. Once I limited it to only 802.11g data rates, then the radio in the Banana Pro works great. the issue is really deep in the driver and not limited to the brcmfmac driver as it would fail with the ap6210 driver on older kernels as well. I tried several of the LeMaker posted or linked distros and they all had the same issue. An AP supporting the old 802.11b data

good morning everyone. I have some good information to pass along from the testing.. It's working! I can associate to my AP now without an issue. What was the *fix* or *workaround*? I had to disable 802.11b legacy speed support in my Access Point, that was all. For whatever reason, with the "b" speeds active, it would have a fit. Didn't matter if the SSID was encrypted or open. once I turned the "b" speeds off the radio would associate. So that tells me there is an issue somewhere in the driver for the radio that is causing it not to be able to associate to an AP if legacy spe

ok, here's some more information.. I went back to 4.4.1 and had the same issue with the integrated broadcom radio. For kicks I hooked up a USB RealTek radio and it works just fine. so the core WiFi sub-system is working, it's directly related to the broadcom radio hardware/drivers. I wonder if the .dtb file has something goofy in it. I do remember having this working with one of the LeMaker OS loads back with a 3.4 kernel. is there a way to port the old "fex" files into a "dtb" ? Am I using the terminology correctly? Let me go back to the Jessie 3.4.110 load and see if that changes anyt

Greetings all! I'm working to get my BananaPro (LeMaker board) up and running with Armbian 5 (Armbian_5.04_Bananapipro_Debian_jessie_4.4.3.raw) just downloaded to a fresh SD card. The radio is discovered and appears to be at least tolerated by the drivers. I've modified and recompiled as directed, the boot.cmd as such to point to the bananapro.dtb file directly: setenv bootargs "console=tty1 root=/dev/sda1 rootwait rootfstype=ext4 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p6