Your panfork is definetely not working,
Your mpp is working
Your rga is not working.
But dont know the root causes, dmesg and journalctl -f may give more insights about rga.
I think rga support at least which version of rga is working is also kernel dependant. Still im not the expert on neither of topics. I can only solve issiues by trial and error.
etienne@alarm ~ % uptime
14:34:55 up 21 days, 21:40, 2 users, load average: 1.00, 0.90, 0.81
Not bad for a dev server Iām using every day for my work and several docker containers running in background.
Hopefully it doesnāt get the PD issue @boogiepop had. Building a UPS for that board could prevent that I guess.
Here is a small script that auto updates the dynamic libraries to the latest commit available in the git repo.
For the rest of the system you can still, sudo pacman -Syu.
They see me rolling, they hatin:
echo y | LANG=C yay -S --removemake --needed --noprovides --answerdiff None --answerclean None --mflags "--noconfirm" \
mesa-panfork-git \
mpp-git \
ffmpeg-mpp \
ffmpeg4.4-mpp \
kodi-nexus-mpp-git \
kodi-nexus-mpp-git-tools-texturepacker \
kodi-nexus-mpp-git-eventclients \
kodi-nexus-mpp-git-ffmpegdirect \
kodi-addon-inputstream-adaptive-git \
kodi-addon-pvr-iptvsimplea new set of packages: when you install libmali-radxa-g610-bin for AUR, this will install gl4es and libdri2to3 and a runner libmali script similar to armbianās malirun.
With that script you run specific application with blob drivers. ie:
libmali glmark2
to run the libmali with wayland you should use libmaliw instead of libmali
This will only work with X and XWayland. Wayland seems to have problems. But i think if you need blob drivers, wayland is not the way to go.
This can work both on X and Wayland, however depends on the applications thats being run
Below is the SS for glxgears and glmark (notice GLvendors):
And below is the AetherSX2 emulationg God of War2 PS2 game both on X and Wayland.
I have abused the upscaling up to 2.75 to 1408x1408, the frame is rock solid 50fps. (dont mind about the peak in the SS thats because me taking a screenshot.)
I am not a game person but this looks quite promising to me, however i dont have anything to compare to.
Gow2 PS2 on Wayland
Gow2 PS2 on X11
it feels like i am spamming this thread but here is the news.
@Googulator created a mid-stream kernel based on linux mainline 6.2 where you can see what is supported here.
This kernel also supports very early implementation of pancsf kernel drm driver created by collabora.
Besides the kernel driver, mesa also initially provided support for pancsf in this branch.
You can use below packages to test out pancsf in your rock5b.
mesa-pancsf-git
linux-rk3588-midstream
I have tested them myself, pancsf in its current shape glitchy, however midstream kernel seems to be working ok.
If you want to try them out you can use above packages.
As always obligatory archlinux neofetch SS with linux 6.2 kernel:
PS: i did not AUR those packages, since i am not sure about their lifecycles as of yet so curretly only pkgbuild files.
why dont you makes an .img with all those things rock and ready? You seem to know quite a bit about ArchLinux. (I dont but Iām tempted to try) Looks good.
Ok ill make an image 
Awesome, glad to see exciting news about kernel and gpu drivers. Iām very tempted to try 6.2, just Iām using my current arch install for my work so may try on different SSD.
So if we want to switch all beta but official we should install mesa-pancsf-git , linux-rk3588-midstream which will replace radxa based kernel, and panfork unofficial gpu drivers right?
Just a friendly note that PVTM does not work on midstream kernel yet, so your CPU will be slightly slower (up to 10% for a single core) on this kernel at the moment.
It does work since itās a HW feature and also living inside the firmware (the boot BLOB loading stuff on an MCU inside the SoC to control the hardware). Due to the differing OPP tables the A55 are overclocked and the A76 remain at lower clockspeeds. But by simply increasing the supply voltages depending on the silicon quality inside the SoCs thereās no reason why the A76 couldnāt clock up to 2.4 GHz regardless of what the cpufreq OPP define since PVTM will take the voltage + silicon quality + temperature to decide at which clockspeed the cores run.
See the two Rock 5B entries here: https://github.com/ThomasKaiser/sbc-bench/tree/master/results/reviews
And for the OPP tables there:
Another interesting difference is idle consumption (measured with same setup directly after a reboot):
Thanks for the detailed testing. The idle power consumption is a huge regression, is this due to the extra voltage added to the a55 cluster, or simply the power management is missing for the rest of the soc?
The A76 cores does perform at the same level of performance despite what the system reports the current frequency isā¦ So we should never trust the system reported values on RK3588 boards right?
Canāt build linux-rk3588-midstream, patch files wonāt open for some reason. āNo such file or directoryā.
Reading @Googulator notes, Iām curious to see if my set up, as currently configured, will actually work with this kernel. Iām running my rock5b in display port alt mode with a single cable powering the 5b as well as providing 4k video and sound. The power sources is from Gigabyte M32U 4k monitor rated only @18w. With the current kernel everything works fine.
One other thing, Iām running the standard FFmpeg with mpp-git. When I switch to FFmpeg-mpp it doesnāt build.
libavutil/hwcontext_vulkan.c:363:7: error: āVK_EXT_VIDEO_DECODE_H264_EXTENSION_NAMEā undeclared here (not in a function); did you mean āVK_EXT_VIDEO_ENCODE_H264_EXTENSION_NAMEā?
363 | { VK_EXT_VIDEO_DECODE_H264_EXTENSION_NAME, FF_VK_EXT_NO_FLAG },
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| VK_EXT_VIDEO_ENCODE_H264_EXTENSION_NAME
CC libavutil/intmath.o
libavutil/hwcontext_vulkan.c:364:7: error: āVK_EXT_VIDEO_DECODE_H265_EXTENSION_NAMEā undeclared here (not in a function); did you mean āVK_EXT_VIDEO_ENCODE_H265_EXTENSION_NAMEā?
364 | { VK_EXT_VIDEO_DECODE_H265_EXTENSION_NAME, FF_VK_EXT_NO_FLAG },
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| VK_EXT_VIDEO_ENCODE_H265_EXTENSION_NAME
make: *** [ffbuild/common.mak:81: libavutil/hwcontext_vulkan.o] Error 1
make: *** Waiting for unfinished jobsā¦
==> ERROR: A failure occurred in build().
Abortingā¦
Thanks again for your help and ongoing efforts to get Arch going on the 5b. Much appreciated.
this error seems to be due to an old version of ffmpeg-mpp, for some reason you should be using some cached or old version. Can you send the full output of, (of course you need yay for this)
yay -S ffmpeg-mpp --answerclean All --needed
I have noticed that i have made a stupid typo when giving the default config file. Fixed in the latest commit, if you do git fetch and pull and afterwards
makepkg -s
should do the trick
Actually thomasās sbcbench is using a very smart tool called āMhzā. This can very closely measure the cpu frequency.
Yep, just makepkg -si, and it will already ask if they should be replaced with mesa and linux kernel. 1 thing important though. You still need to adapt the extlinux.conf to point out to the right location. I have also prepared a template for this under /boot/extlinux/extlinux.arch.template. You can directly use it but make sure you have adopted the UUID of the rootfs partition.
append root=UUID=**CHANGEME** earlycon=
I donāt know exactly but did some further testings right now (quite time consuming), Iām testing with an Armbian image that combines @Googulatorās kernel with Radxaās/Rockchipās u-boot/BLOBs. As such situation with mainline u-boot might be completely different but I donāt even know whether this works or not.
At least in this special scenario (RKās BSP u-boot and firmware BLOBs combined with the 6.2 midstream kernel) it looks like this when clocking the DRAM at 2112 MHz and keeping the CPU cores at ~400 MHz:
Idle consumption vs. cpu4 being fully loaded with cpuminer (taskset -c 4 /usr/local/src/cpuminer-multi/cpuminer --benchmark --cpu-priority=2):
So at least the difference is the same and we already know that clocking the DRAM between 528 MHz and 2112 MHz makes up for a 500-600 mW difference. The 6.2 midterm kernel currently lacks a DMC driver or it is not active as such these 500-600 mW higher idle consumption are to be expected.
For the remaining ~1500mW difference I would suspect RKās u-boot bringing up the hardware in a state that is expected to be controlled afterwards by RKās BSP kernel but this stuff is missing with the midstream kernel (yet).
Applies to every RK35xx SoC right now as long as itās running RKās BSP bootloader (u-boot + BLOBs) since then PVTM does its own thing. By tweaking the DVFS OPP tables one can convince PVTM to clock higher. Thatās why on my RK3588 with @Googulatorās kernel and the overvolted A55 OPP the little cores clock north of 1900 MHz. And the same can be done with the A76. @amazingfate for example managed to get them clocked beyond 2700 MHz just by tweaking the supply voltages. The cpufreq driver still reports 2400 MHz while in reality itās way above or below.
But all of this only works as long as RKās BSP u-boot + boot BLOBs are in place and with a true mainline bootloader situation something different might happen (thatās why I think Collaboraās Sebastian has eliminated the DVFS OPP beyond 2.2 GHz).
I had fiddled around a long time in mainline uboot specially on rockchip and allwinner machs, what uboot mainline does in SPL and TPL is only configuring the DMC registers (along with boot device config if enabled). For the older series of rockchip it is even very dummy that it sets hard coded Zmq and timings, for 3399 at least it is more advanced and it actually trains on some fast timings when possible. According to my memory all rockchip SOCs use a very well known IP core (which i forgot the name) burned in their ASICs. So thats the point with TPL because uboot needs some proper stack to wotk with.
From design POV i think it would be too costly to replace the internal MCUs firmware on the board initialization, instead i would expect the SRAM to have the mcuās code emdedded in the SOC irreplacably through the bootcode. Yet in this case, i would speculate having uboot mainline tpl or rkbin tpl would make a difference. I would vote for kernel to configure some memory mapped region to configure to activate whatever part is missing.
Actually i had written a great tool to manipulate the SOC registers directly from the userspace bypassing the kernel totally with using mmap. It was particularly useful for reverse engineering old broken tablets, but in this case would be usefull to compare how different kernels and bootloaders configure the SOC registers.
I donāt think Rockchip blobs are involved at all; PVTM is managed by a pair of kernel drivers named clk-pvtm and rockchip-pvtm. These arenāt present in midstream - Sebastian has probably removed the higher clocks since PVTM would be required for knowing when itās safe to enable them.
EDIT: looks like itās just rockchip-pvtm; clk-pvtm is unused and its DT compatible ID ārockchip-clcok-pvtmā (sic) canāt be found in our DTS, or indeed any other Rockchip DTS I could find.
Hmmā¦ I simply adjusted three values in the OPP tables and turned this
cpu0-cpu3 (Cortex-A55): OPP: 1800, Measured: 1934 (+7.4%)
cpu4-cpu5 (Cortex-A76): OPP: 2208, Measured: 2200
cpu6-cpu7 (Cortex-A76): OPP: 2208, Measured: 2200
(Sebastians OPP tables overvolting the A55 and limiting the A76 to just 925.0 mV) into this:
cpu0-cpu3 (Cortex-A55): OPP: 1800, Measured: 1800
cpu4-cpu5 (Cortex-A76): OPP: 2208, Measured: 2335 (+5.8%)
cpu6-cpu7 (Cortex-A76): OPP: 2208, Measured: 2335 (+5.8%)
I just reopened the Github issue to not further hijack this thread with esoteric DVFS/PVTM stuffā¦
[quote=āboogiepop, post:1, topic:13851, full:trueā]
this patch plz your AUR package
Did you make an image? If so, where can I download? 