Igor

CONFIG_MALI_PWRSOFT_765=y has to be enabled, but then I don't get the picture on the screen. Continuing tomorrow.

BT headset connected, sound distorted (Chromium Youtube) BT keyboard works fine mali fails (user 10.6, kernel 10.4) video acceleration works fine don't have sound on HDMI, headset audio works Building with Midgard for Android fails with: drivers/gpu/arm/midgard/ipa/mali_kbase_ipa.c:582:22: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types] error, forbidden warning: mali_kbase_ipa.c:582 CC drivers/regulator/core.o scripts/Makefile.build:277: recipe for target 'drivers/gpu/arm/midgard/ipa/mali_kbase_ipa.o' failed make[4]: *** [drivers/gpu/arm/midgard/ipa/mali_kbase_ipa.o] Error 1 make[4]: *** Waiting for unfinished jobs.... This is fixed ... going further.

I'll push one small update ... midgard for Android is broken while for Linux builds. Need to run few tests later.

OK, let me know. I can verify normal Tinkerboard.

Perhaps when this is delivered: https://www.kickstarter.com/projects/bootlin/allwinner-vpu-support-in-the-official-linux-kernel Since they raised only around 30.000 EUR this might not be done.

You need to add module to the kernel or load it before network goes up ...

Driver quality is certainly not the problem of Armbian. Our supports ends with the possibility to compile the driver. We don't support 3rd party hardware and we are not Microsoft corporation with tens of thousands people but only a few amateurs. If driver sources are bad, there is nothing we can do about. Try another, different one, talk to chip maker, ...

Follow my advice. Install headers within armbian-config sudo apt-get install linux-headers-$(uname -r) This is the wrong way of installing headers.

No, that is not possible. When you install your own kernel, you have to freeze kernel updates in armbian-config to prevent updating from our repository.

Try this way - starting with a fresh image: armbian-config 1. Switch to beta repository, update 2. Install headers Then proceed with drive compilation this way: https://docs.armbian.com/User-Guide_Advanced-Features/#how-to-build-a-wireless-driver (you can skip the part for kernel headers install since you did that from armbian-config) Also, provide logs from armbianmonitor -u ... it might give us some clues why it's not working.

It's already funded and almost done, but that's low-level support. Somebody still needs to implement that into player(s). Could be. We don't deal with 3rd party hardware and I personally don't have many experiences with displays. First do extensive search https://www.armbian.com/search_gcse since it is possible somebody already solved this problem.

Video acceleration is not supported in modern kernel. It has to be developed first: https://www.kickstarter.com/projects/bootlin/allwinner-vpu-support-in-the-official-linux-kernel than implemented.

Perhaps peeking into the documentation first would save some time https://docs.armbian.com/Hardware_Allwinner/#how-to-reconfigure-video-output

Yes, but possible that upgrading will break since I forgot to merge few files. Now rebuilding once again - with new version.

We have DEV branch attached to mainline 4.14.y with a few patches on top, but I am not aware what works and what not. That must be some network/GitHub related issue.

Yes indeed. It will take another few hours to rebuild repository. Will see in the morning if everything went o.k.

It should be possible to build both kernels/images and they most likely still works fine. We just stop to maintain them. There are two kernels, stock 3.14 and 4.4 which is probably better to go for.

I guess my build optimizations are not working properly yet ...

https://github.com/ayufan-rock64/linux-build/blob/master/recipes/overclocking.md

H5 images are still experimental, while Core2 got on my desk this week Try rather those images: https://dl.armbian.com/nanopineo2/nightly/

O.K. Not touching development anymore. When you are done it can be dropped, right? For Bionic host dependencies only aptly hack is needed. Didn't find other problems. Here we might need little clarifications. It can also get messy - lots of branches - if we will have a separate branch for minor things.

OK. I am a bit confused now. How is the best to proceed from a current state?

IMO this is not needed for this case. DEV branches were designed for experimenting.

Can you attach things to the DEV branch that we can try to figure out together?

Oh, too bad then Boot menu for what? Choosing different kernels/OS?