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? 
@11132
All below packages updated with latest commit from jeffys repo.
I’ve successfully boot up midstream kernel, currently testing it and could use it as my daily image
if stable enough. (can wait without everything supported for now)
I made detailed step by step image building instructions here in case some would be interested.
I didn’t test image building from dist like debian, but it should be possible as described on official archwiki
Boogie ol’ buddy ol’ pal, did you upload the image to some location?
While trying to install official pancsf mesa drivers, I noticed this error during build:
Checking if "-mtls-dialect=gnu2" runs: DID NOT COMPILE
Found pkg-config: /usr/bin/pkg-config (1.8.1)
Run-time dependency vdpau found: YES 1.5
Program glslangValidator found: YES (/usr/bin/glslangValidator)
Run-time dependency libomxil-bellagio found: YES 0.9.3
Run-time dependency libva found: YES 1.18.0
Header "va/va.h" has symbol "VASurfaceAttribDRMFormatModifiers" with dependency libva: YES
Run-time dependency libclc found: YES 0.2.0
mesa/meson.build:795:0: ERROR: Feature android-libbacktrace cannot be enabled: `-D android-libbacktrace=enabled` makes no sense without `-D platforms=android`
A full log can be found at /home/etienne/setup/hw_necromancer/rock5b/mesa-pancsf-git/src/build/meson-logs/meson-log.txt
==> ERROR: A failure occurred in build().
Aborting...
makepkg -si 151.76s user 17.31s system 76% cpu 3:40.52 total
anyone experienced same build error or any idea about what could be causing this?
Thanks for the contribution, i have added the link to the first post.
The information in this thread and several others are really piling up, it would be great if we had some form of wiki just like Sunxi has. Is radxa/rockchip people somehow interested in maintaining a wiki. I think thats a solid idea.
Thanks build worked 
Havn’t looked into graphics side much yet, but just launching gnome I’ve noticed quite high CPU usage so maybe GPU accel wasn’t used, plus interface didn’t feel very smooth.
My current biggest concern is this
modprobe zram
modprobe: FATAL: Module zram not found in directory
I was using that feat in previous kernel, to enable swap ram compression and double my 8GB ram
as I build quite massive web stuff which consumes lots of memory .
I don’t know much about kernel stuff …so not sure if this unsupported feature in midstream kernel
For now I’m back to old kernel until I can make it work. If someone has an idea about that.