The linux-vim kernel (package to install: linux-vim).
While sound is supported when using the linux-vim kernel the system gets unresponsive after a short while when using Panfrost driver which enables hardware-accelerated OpenGL graphics rendering (package to install: mesa-git). When using the linux kernel it is the other way round: Panfrost is stable but sound is not supported.
So, at the moment there are still some limitations with both kernels but I am sure sooner or later this problem will be fixed by @spikerguy and/or @Strit (they have already asked other developers for support regarding this problem).
At the same time Manjaro comes in three branches:
stable
testing
unstable
While the stable branch offers older kernels and older versions of software packages which are meant for daily usage, testing and unstable branches brings you newer kernels and software packages but your system might crash from time to time because it uses software which is still in development/not fully tested.
You can switch branches with the following command: sudo pacman-mirrors -aS <branch> && sudo pacman -Syyu
where <branch> is āstableā, ātestingā or āunstableā.
You can find my .dtb which is working with @spikerguyās new linux-vim image and has ethernet and sound here: http://ge.tt/5gstu593
This makes for a nice theory/hypothesis to test. I will do it also on my box (I have the power up gpu errors on at least Manjaro (which has kernel 5.9.0-2) but I donāt recall about the others; weāll see.)
With the governor=āperformanceā in Manjaro-ARM-VIM3-KDE 20.11 running for 30 minutes so far no screen glitches. Looks like it works to resolve screen flashes/glitches in Manjaro-ARM-VIM3.
Interesting to test. My experience is on GT King Pro (Rev. A) āPanfrost error powering up gpu L2 and error powering up gpu Shaderā on Armbian Bullseye/Ubuntu or Manjaro=ARM-VIM3 images if:
use āmeson-g12b-ugoos-am6.dtbā
use āmeson-g12b-gtking-pro.dtbā from the first mainline I have file size 50K
use āmeson-g12b-gtking-pro.dtbā (file size 75,301 bytes) from Manjaro-ARM-VIM3-KDE-Plasma-5.9.0-2 20.11 surprising it have error
If I use a copy āmeson-g12b-gtking-pro.dtbā that I keep from one of the Armbian image (canāt exactly remember from which version most like from Odroid N2 image which cannot boot on GT King Pro but surprising have āmeson-g12b-gtking-pro.dtbā it usually have not Panfrost error that is why it is my go to dtb. I am currently using the Armbian version on the Manjaro-ARM-VIM3-KDE-20.11 kernel 5.9.0-2 image.
Great work TheMojoMan.
Sorry for all the the trouble that Iām given you, but can you share again your dtb in another hosting service.
I donāt now why but seems that Iām not able to download your file from http://ge.tt/5gstu593 no matter what browser I use.
Thanks
I now ran each of these images for one hour with governor=ondemand (surfing and watching youtube videos) and experienced no glitches or freezes.
dtb: For both these images I have used the dtb for Ugoos supplied with the image (meson-g12b-ugoos-am6.dtb). In the Armbian dtb I have made one small change of a parameter (the speed of the SDIO-bus, to get WiFi/AP6398S working, see this post). The Khadas dtb is āpristineā (since Khadas applies some patch which has the desired effect, this one I think).
gpu power up: For both these images I have the error messages (in dmesg)
panfrost ffe40000.gpu: error powering up gpu L2
panfrost ffe40000.gpu: error powering up gpu shader
Thus, I have no glitches (on these images) to correlate with either governor, dtb or gpu power-up errors, and I have no successful gpu power-up to correlate with dtb either. (But, of course, I have Manjaro awesomeness so Iām happy anyway.)
Earlier I did mentioned that on the Manjaro-ARM-VIM3-Xfce linux-kernel 5.9.9-2 (not linux-vim) not having that frequent screen flashes/glitches compared to the Manjaro-ARM-VIM3-KDE-Plasma 20.11.
I am using Manjaro-ARM-VIM3-Xfce linux-kernel 5.9.9-2 (not linux-vim) right now and there is hardly any screen flash/glitch 20 minutes and the governor is neither āondemandā or āperformanceā. The governor=āscheutilā.
[jfl@GTKPro ~]$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
schedutil
[jfl@GTKPro ~]$ uname -a
Linux GTKPro 5.9.9-2-MANJARO-ARM #1 SMP Fri Nov 20 12:30:37 UTC 2020 aarch64 GNU/Linux
A brief history on how I ended up in to linux-kernel 5.9.9-2. This image from you (Tripole) Manjaro-ARM-xfce-vim3-20.11.img_xz linux-vim kernel 5.9.0-1. I do encounter kernel panic on linux-vim kernel 5.9.0-1 and had to split on a reasonable large system update (upgrade to linux-vim kernel 5.9.0-2), to 3 smaller updates using the Package Manager to avoid kernel panic. Before splitting the uprades during the system upgrade kernel panic occurs and it corrupted the USB drive and I have to re-burn the image again.
I wanted to check if upgraded to a higher kernel is any performance improvement and especially looking for better stability (meaning less frequent kernel panic/freeze on GT King Pro). On the stable branch the only higher kernel available is linux kernel 5.9.6-1 (no other linux-vim kernel was available on stable branch) so I switch linux-vim kernel 5.9.0-2 to linux kernel 5.9.6-1 (as expected no sound).
After that I read that Panfrost can run on S922X linux kernel without crashing (from TheMojoMan) and Strit suggested I should try mesa-git 21.0.0 but it does not work with linux kernel 5.9.6-1 (it requires LLVM11 if not mistaken). Have to switch to ātesting branchā if I want to try out mesa-git 21.0.0. Surprising with Stable kernel 5.9.6-1 I was able to uprade to Testing linux-kernel 5.9.8-1 successfully in one go (I think overall around 800MB upgrade overall) luckily the kernel panic happened after the successful upgrade. The system seems more stable and the next upgrade without kernel panic to the current kernel 5.9.9-2. Tried Panfrost with mesa-git, mesa-arm-git and mesa-panfrost-git and now back to non-Panfrost with mesa 20.2.2-2. How I ended up with governor=āschedutilā I have no idea.
I canāt remember encountering any kernel panic with kernel 5.9.9-2 so far (just few around 20 hours usage over last few days).
Edit: With linux kernel 5.9.9-2 with āmeson-g12b-gtking-pro.dtbā from linux kernel itself, NO Panfrost error on boot up.
No sound on mainline linux kernel 5.9.9-2 or 5.9.6-1. I even tried using odroid-alsa-1-3-aarch64.pkg.tar.zst from archlinuxdroid repo but unsuccessful on getting sound on mainline linux kernel.
Just an update with the governor=āschedutilā, no screen flashes/glitches for the past 1hr 35mins.
From my testing of Panfrost with mesa-git, mesa-arm-git and mesa-panfrost-git, Panfrost runs on GT King Pro with linux-kernel 5.9.9-2 quite well, but I feel that it lag a bit but not bad (when you run glmark2-es2 the CPU usage is very low compared to without Panfrost eventhough without Panfrost the score is better). Take note NO Sound on mainline linux kernel as far as I know hopefully someone can find a solution. No sound on video is no fun!
But In Firefox 83 if you turn-on/enable Webrender or layers.acceleration.force.enabled option (using about:config) and play YouTube Video on it, it freeze and dmesg will give Panfrost gpu error.
But according to Spikerguy and TheMojoMan Panfrost is not stable on linux-vim kernels currently.
Yes I can boot and run without problems. Errors were found when video decoding (2D acceleration) and continued until reboot.
.
I managed to get driver up with linux-vim 5.9.0 and mesa-git 20.3 with panfrost powering errors. When upgrading panfrost errors disappeared. From there have random freezes. I will update to latest stable and try cpupower if freezes remain,
Earlier post by Spikerguy, did warned that linux kernel 5.9.0-1 do have memory leak and can cause issue on Panfrost. Check the Panfrost for Bifrost GPUs - Big improvements started by TheMojoMan.
Can safely say with governor=āschedutilā in Manjaro-ARM, there is NO Screen Flashes/Glitches (2hr 30min no screen glitches at all).
Just found some info on governor=āschedutilā, from lwn.net " Improvements in CPU frequency management"
"The other important change is to introduce a new CPU frequency-scaling governor, schedutil, that makes decisions based on utilization as measured by the scheduler. The cpufreq_update_util() call that the scheduler makes whenever it updates the load average already carries information about the calculated load on the current CPU, but no governor uses that information. schedutil changes that. It doesnāt change much though.
schedutil still only performs updates at the same rate as the current code, so it doesnāt try to address the interactive responsiveness problem, and doesnāt try to be clever about realtime or deadline threads. All it does is use the load calculated by the scheduler instead of the average load over the last little while, and optionally imposes that frequency change instantly (directly from the scheduler callback) if the driver supports it.
This is far from a complete solution for power-aware scheduling, but looks like an excellent base on which to make cpufreq more responsive to sudden changes in load, and more aware of some of the finer details that the scheduler can, in theory, provide."
I just check ā/etc/default/cpupowerā with the Manjaro-ARM-VIM3 KDE Plasma 20.11 kernel 5.9.0-2 there is not option to set governor=āschedutilāā¦ Wanted to try whether with governor=āschedutilā on this Manjaro-ARM-VIM3 KDE Plasma 20.11 kernel 5.9.0-2 solve the screen flahes/glitches issue.