Ubuntu 20.02 & Mali Drivers

#28

Going back to Jammy & Wayland
With https://github.com/armbian/build/releases/download/22.11.0-trunk.0096/Armbian_22.11.0-trunk.0096_Rock-5b_jammy_legacy_5.10.72.img.xz
Plus current ppa still crashes and wondering if any updates on that? Still seems to be holding some packages back so maybe the ddr update is not in place.
@icecream95 If I build glmark2-es2-wayland and install it runs complete and ends with a Glmark2 Score 866
That is the normal like for like env I usually run glmark with no affinity or scheduler changes and less than I would hope for but hey it didn’t crash!
gg @icecream95 as things looking nearer

echo performance | sudo tee /sys/bus/cpu/devices/cpu[046]/cpufreq/scaling_governor /sys/class/devfreq/dmc/governor

1764

Bad bash script time

#!/bin/bash
glmark2-es2-wayland&
while :
do
        LOAD=$(cat /sys/devices/platform/fb000000.gpu/utilisation)
        echo "Current Load:"$LOAD
        TOTAL=$((TOTAL+LOAD))
        COUNT=$((COUNT+1))
        echo "Avg Load:"$((TOTAL/COUNT))
        sleep 1
done

Load on avg 41%

#29

What crashes? How? When you do what? Does anything appear in dmesg, the console, or journalctl?

Yup, that’s about what’s expected. It will take some work to change the driver so that work can be done in parallel between the CPU and GPU. With CSF the kernel doesn’t help with doing that as much as it did previously.

#30

I didn’t check that much as the repo glmark2-es2-wayland seems a catastrophic crash and locked up the wayland client.
I just compiled glmark2-es2-wayland with .waf and runs fine, so apols didn’t do any bug hunting as mostly used the Jammy Radxa image due to ArmNN as not sure if 22.04 is part of the repo (18.04/20.04 is)

The RK3588 is a low wattage powerhouse SBC for ML with the CPU & GPU and the 3rd option of the NPU that haven’t tried yet as not to optimistic about quite a few dmesg entries with the NPU.
With the amount of vendors and variations the rk3588 & rk3588s could become an extremely common platform.
Have you reached out to Alyssa and Mesa like Asahi Linya did with the M1 as a herd sharing and contributing to a mainline is likely going to be quicker and stronger than many all soloing?
In a perfect world Mfcc & Spectrogram 16Khz would be part of codecs and near load free but both Tensorflow & Pytorch have optimised C routines and strange why Arm opted for Python that can not be stressed how much it sucks for any DSP :slight_smile:
Many thanks for your time and input.

#31

Starting with Armbian_22.11.0-trunk.0096_Rock-5b_jammy_legacy_5.10.72.img
My sort of legacy thing I do as a check its all there sudo apt-get update && upgrade sudo apt-get install software-properties-common apt-utils git cmake build-essential autotools-dev autoconf libtool pkg-config reboot
Get the csf bin to lib/firmware
sudo add-apt-repository ppa:liujianfeng1994/panfork-mesa
update/upgrade
sudo apt install ubuntu-desktop
reboot

Log in to wayland
sudo apt-get install glmark2-es2-wayland
glmark2-es2-wayland

This time runs no prob but before on 2x different try I got a total catastrophic lockup and decided to compile by waf myself.
Guess not waf but just a spurious crash.

Still get artefacts on the background image but always ignored that.

Screenshot%20from%202022-11-05%2001-38-00
Screenshot from 2022-11-05 01-38-00.jpg1920×1080 346 KB

So dunno as tried it again expecting a crash and worked fine GLmark2 Score 872

Xubuntu 22.04.2 Setup and Experience
#32

On radxas debian, I cannot see mouse cursor on wayland gnome using @icecream95 's panfork, but the cursor is visible on KDE wayland(and weston), and I’m not seeing the graphic glitch that @stuartiannaylor is seeing on either desktop. I compiled panfork myself.

KDE wayland is having performance issue using OpenGL based compositors, the desktop will hang from time to time, and back to normal after 1 second or 2, but XRender works just fine. Firefox is also having such hanging issue even on XRender compositor. However, Gnome does not have such performance issue at all, although I cannot see the cursor, firefox is very smooth.

Weston works perfectly, performance is good, cursor is visible, just Weston itself is not so user-friendly and I don’t want to use it every day.

X11 works fine on both KDE and Gnome, although less performant than wayland on my 4K60 displays and I can see frame drops, but at least it does not have serious bugs that affects normal usage.

There is one thing that I’m using the mali_csffw.bin come with radxas debian, not the one in JeffyCN’s repo.

#33

mali_csffw.bin didn’t know there was a diff as using JeffyCN’s repo.

#34

The Radxas version seems to be an older version than the Jeff’s Repo ones, and I’m have some problems with Jeff’s in early days of testing so I used Radxas one.

#35

I don’t know to be honest as a bit confused by it all as not really my thing.
I am not sure where the source is for either or how they come into existence :slight_smile:
Using Jammy server from armbian with JeffyCn’s csffw and icecreams ppa with a sudo apt install ubuntu-desktop.
The background glitch is weird as it only seems to happen on the background and no where else, haven’t used it much but everything else seems to work and new windows don’t have similar glitches.
So I have always just ignored it.

It was purely curiosity to the performance as the mali seems to be only put under approx 40% load by what I presume is the gles driver whilst playing with ml and using openCl that can avg around 75% load on the mali.
I just thought Wayland might be more performant

OpenGL ES GPU pipelining
OpenGL ES exposes a synchronous rendering model to the application developer, despite
the underlying execution being asynchronous, whereas Vulkan exposes this
asynchronous nature directly to the application developer to manage. In either case it is
important that the application keeps the GPU fed with work, avoiding behaviors which
drain the pipeline and starve the GPU of work (unless the desired target frame rate has
been reached, of course).
Keeping the GPU busy not only means that you will get the best rendering performance
from the platform, but also that you avoid hitting performance oscillations caused by the
platform dynamic voltage and frequency scaling (DVFS) logic thinking that the CPU or
GPU is under-utilized.
Do
▪ Do not let the GPU go idle unless the target performance is reached.
▪ Pipeline any use of fences and query objects; don't wait on them too early.
▪ Use GL_MAP_UNSYNCHRONIZED to allow use of glMapBufferRange() to patch a safe
region of a buffer which is still partially referenced by in-flight draw calls.
▪ Pipeline any glReadPixels() calls to read asynchronously into a pixel buffer object.
Don't
▪ Use operations which enforce the synchronous behavior of OpenGL ES:
▪ glFinish()
▪ Synchronous glReadPixels()
▪ glMapBufferRange() without GL_MAP_UNSYNCHRONIZED on buffer still referenced
by a draw call
▪ Use glMapBufferRange() with
either GL_MAP_INVALIDATE_RANGE or GL_MAP_INVALIDATE_BUFFER; due to a
historical specification ambiguity these flags will currently trigger the creation of a
resource ghost.
▪ Use glFlush() because this may force render passes to be split; the driver will flush as
needed.
Impact
▪ Pipeline draining will, at a minimum, result in a loss of performance as the GPU will
be partially idle for the duration of the bubble.
▪ Possible performance instability, depending on the interaction with the platform's
DVFS power management logic.
Debugging
▪ System profilers such as DS-5 Streamline can show both CPU and GPU activity.
Pipeline drains of this nature are normally clearly visible as periods of busy time
oscillating between the CPU and GPU, with neither being fully utilized.

As I thought X11 was forcing all those don’t of synchronous operation as from what @icecream95 said that seems to be the problem with no parallelism with gpu/cpu as one is waiting for the other?
I was purely trying to get a best rough bench so will have to leave it to you 2. Apols :slight_smile:

In the DTB it seems to be declared as bifrost which don’t have a CSF so yeah I am totally confused at state of play :slight_smile:

	gpu@fb000000 {
		compatible = "arm,mali-bifrost";
		reg = <0x00 0xfb000000 0x00 0x200000>;
		interrupts = <0x00 0x5e 0x04 0x00 0x5d 0x04 0x00 0x5c 0x04>;
		interrupt-names = "GPU\0MMU\0JOB";
		clocks = <0x0e 0x05 0x02 0x115 0x02 0x116 0x02 0x114>;
		clock-names = "clk_mali\0clk_gpu_coregroup\0clk_gpu_stacks\0clk_gpu";
		assigned-clocks = <0x0e 0x05>;
		assigned-clock-rates = <0xbebc200>;
		power-domains = <0x4e 0x0c>;
		operating-points-v2 = <0x4f>;
		#cooling-cells = <0x02>;
		dynamic-power-coefficient = <0xba6>;
		upthreshold = <0x1e>;
		downdifferential = <0x0a>;
		status = "okay";
		mali-supply = <0x50>;
		mem-supply = <0x50>;
		phandle = <0x4d>;
	};
#36

I’ve been trying to debug that issue for a couple of days, but still don’t know how to fix it…

I don’t want to implement whatever hacks the blob is doing for Wayland, so improving the average GPU load will require some kernel changes. It’s still a while to get to that point, though.

The BSP kernel has three copies of Arm’s Mali kernel driver—one for Utgard (mali400), one for Midgard, and one for Bifrost (which also supports Valhall). Changes to the kernel driver for Valhall support went to the Bifrost source tree, so the GPU is marked compatible with the Bifrost kernel driver.

The Bifrost kernel and Valhall kernel downloads from Arm are identical.

#37

From the kernel’s perspective, (pre-CSF, “Job Manager”) Valhall is more
or less compatible with Bifrost

Was it the 1st/2nd gen Valhall that didn’t have a CSF and that is what is completely missing and this has been a complete confusion to me as its a pretty big change but still keeps the same Architecture name that I guess should be identified as mali-csf ?

There seems less of a change between bifrost & the 1st/2nd gen Valhall that did get a name change then 3rd gen Valhall comes with a substantially different CSF that really is not incremental as other Valhall additions to bifrost have been but does keep a same architecture name ?!?

So yeah I am totally confused and yeah the Bifrost kernel and Valhall kernel prob are identical and why the MaliG610 with no CSF coordination is only achieving 40% load.
Also we are on this BSP kernel of 5.10 that is totally out of wack with Mesa so guess also you are having to heavily backport.

The man in the middle of the CSF between cpu irq and gpu and a queue that isn’t waiting for completion should have a kernel implementation I presume but currently is being hacked into the userspace?

I am going to have to leave it to you @icecream95 but I am not really sure about soloing this as surely the herd of Mesa and alyssa are needed to pool resources?

#38

@stuartiannaylor @icecream95
Just curious, does HW video decoding work in any browser (e.g. FF or Chromium) with that Armbian+Mali driver combo under Wayland? I’m interested to give it a try soon.

#39

The only one that would work probably is the custom chromium provided by rockchip. The one shipped with radxa debian does not support wayland but rockchip said that the wayland patch does exist and some customers are using that, probably Khadas is ?

#40

I am not sure as was purely interested if the Wayland implementation helps with the current problems of balancing the cpu / gpu irq calls in the new command stream as would seem currently the Mali G610 is very underloaded as the parallelism doesn’t seem to exist at all so one is always waiting for the other and process seems serial.

Its @icecream95 who knows a huge amount as is prolific contributor and did much with OpenCL so is in a totally different league to me.

Put simplistically to what my limited brain can handle is the current drivers are a bit like the early Mali-FB-Dev drivers we had that did specific jobs but likely have loads of gotchas as it may not be plumbed into ’ VA-API’ which is how you get Chromium acceleration which I didn’t try. Its video accel really when browsing than 3d.

Because the Mali G610 is such a strong GPU currently for many the results are quite good, but really when looking at load we have a pretty terrible implementation.
I am sort of confused as the CSF & the third gen Valhall would seem a more significant change to its 1st&2nd gen Valhall are to the previous Bifrost they got a name change from.

cat /sys/devices/platform/fb000000.gpu/utilisation so to be honest until we get an optimised driver under the hood I haven’t even bothered testing Chromium.
The Mali is just a 3D Gpu and with video we also have hardware encoders to plumb in and again I am confused there as I thought a lot of work had been done on the state management of video encoder/decoder and the Hantro RKDec shared a lot of similarities but apparently not.

I think there might be considerable work needed on the Mali G610 driver and it could take some time but when using it with OpenCl load gets to 70% which might be near max due to the ArmNN & OpenCl layers using it in the above Wav2Letter example, but even that might even get more optimised.

I am not worthy or any where near the level of Icecream95 and was just curious to state of play and got loads of really great feedback. I am hoping some of the dmesg errors of the NPU get fixed so I can play with the NPU as not expecting anything imminent GPU wise.

I am also thinking this might be the fastest mainline adoption we will see due to the adoption of a large number of rk3588/rk3588s vendors and variations out there as really I would prefer to ditch the Rockchip BSP.

#41

The architecture name changes when the machine code representation used by the shader cores change:

Utgard had separate vertex and fragment shading cores, Midgard was VLIW with three vector units and two scalar units, Bifrost was VLIW with two scalar units, and Valhall uses a simple stream of eight-byte instructions.

So even if the entire rest of the GPU changes, only the shader cores matter for architecture naming.

But even looking at GPU structures, the Valhall GPUs are all very similar to each other, apart from CSF. Bifrost is much closer to Midgard than it is to Valhall in that regard, but the entire fragment processing pipeline from rasterization to blending is almost unchanged for the different Valhall generations.

#42

You know more than me but from past history and reading pretty sure Alyssa has mentioned Utgard->Midgard->Valhall was fairly incremental and that is it the CSF and implementation from what my lowly knowledge might be, seems to think that is less incremental and more of an architecture change than just additions.
Thats why we do have a working driver but still impeded due to no previous csf implmementation.

#43

All CSF does is replace the old Job Manager frontend with the Command Stream Frontend, so rather than having job description structures statically allocated, they are built up by a command stream that is Turing complete. An MCU is added to make this work better.

So previously there was (very simplified, and not how the driver actually does things, and the pointers should be GPU pointers):

struct job {
    struct job *next;
};

struct vertex_job {
    struct job header;
    uint32_t num_vertices;
};

struct vertex_job my_vertex_jobs[] = {
    {
        .header.next = &my_vertex_jobs[1].header,
        .num_vertices = 3,
    },
    {
        .num_vertices = 10,
    },
};

and now we have (again, simplified and not how things actually work):

uint64_t commands[] = {
    CMD_MOV_32(NUM_VERTICES, 3),
    CMD_VERTEX_JOB,
    CMD_MOV_32(NUM_VERTICES, 10),
    CMD_VERTEX_JOB,
};

That is a big change, yes, and one that affects the driver a lot, but most of the rest of the GPU is unchanged, and I suspect that the old vertex_job struct still exists behind the scenes.

Even from the driver side, I have made CSF mostly look like the old way of doing things, so the same code can often be used for both non-CSF and CSF GPUs.

Apart from one bug that can affect programs drawing a lot of vertices (so far I’ve only hit this in one Xscreensaver demo), most of the current driver shortcomings can be blamed on kbase rather than CSF.

#44

Yeah I don’t know how they will choose to implement it in the kernel and dunno maybe Allsya and Mesa have plans with the next gen Mali’s being the same and already out.
I presume the MCU can act like a very low latency asynchronous co-ordinator and queue and when employed we should see gpu loading of much more than the current 40%.
I presume the emulator and ‘gamers’ would be better on Android for a while as its already implemented but not opensource?
I actually ran Glmark2 on android and it gave a similar result but have no idea if the code base has any simularity as a bench.

1 Like
#45

Thank you very much for your work and detailed explanations about the mali driver.

I have been testing mali driver 23.0~panfork~csf this week and have also encountered crashes. I run lightdm and kodi in h264 video mode, the system spontaneously reboots stably at the video transition and after watching the video for more than 30 minutes.

journalctl:

Nov 20 11:17:22 rock-5b pulseaudio[2161]: module-x11-xsmp may not be loaded twice.
Nov 20 11:17:22 rock-5b pulseaudio[2161]: Failed to load module "module-x11-xsmp" (argument: "display=:0.0 xauthority=/home/konstantin/.Xauthority session_manager=local/rock-5b:@/tm>
Nov 20 11:17:22 rock-5b NetworkManager[1755]: <info>  [1668925042.4153] agent-manager: agent[775a0eb26c9baa47,:1.68/org.freedesktop.nm-applet/1000]: agent registered
Nov 20 11:17:22 rock-5b dbus-daemon[2181]: [session uid=1000 pid=2181] Activating via systemd: service name='org.gtk.vfs.UDisks2VolumeMonitor' unit='gvfs-udisks2-volume-monitor.serv>
Nov 20 11:17:22 rock-5b systemd[2151]: Starting Virtual filesystem service - disk device monitor...
Nov 20 11:17:22 rock-5b dbus-daemon[2181]: [session uid=1000 pid=2181] Successfully activated service 'org.gtk.vfs.UDisks2VolumeMonitor'
Nov 20 11:17:22 rock-5b systemd[2151]: Started Virtual filesystem service - disk device monitor.
Nov 20 11:17:22 rock-5b dbus-daemon[2181]: [session uid=1000 pid=2181] Activating via systemd: service name='org.gtk.vfs.MTPVolumeMonitor' unit='gvfs-mtp-volume-monitor.service' req>
Nov 20 11:17:22 rock-5b systemd[2151]: Starting Virtual filesystem service - Media Transfer Protocol monitor...
Nov 20 11:17:22 rock-5b CRON[1680]: pam_unix(cron:session): session closed for user root
Nov 20 11:17:22 rock-5b dbus-daemon[2181]: [session uid=1000 pid=2181] Successfully activated service 'org.gtk.vfs.MTPVolumeMonitor'
Nov 20 11:17:22 rock-5b systemd[2151]: Started Virtual filesystem service - Media Transfer Protocol monitor.
Nov 20 11:17:22 rock-5b dbus-daemon[2181]: [session uid=1000 pid=2181] Activating via systemd: service name='org.gtk.vfs.GPhoto2VolumeMonitor' unit='gvfs-gphoto2-volume-monitor.serv>
Nov 20 11:17:22 rock-5b systemd[2151]: Starting Virtual filesystem service - digital camera monitor...
Nov 20 11:17:22 rock-5b dbus-daemon[2181]: [session uid=1000 pid=2181] Successfully activated service 'org.gtk.vfs.GPhoto2VolumeMonitor'
Nov 20 11:17:22 rock-5b systemd[2151]: Started Virtual filesystem service - digital camera monitor.
Nov 20 11:17:22 rock-5b dbus-daemon[2181]: [session uid=1000 pid=2181] Activating via systemd: service name='org.gtk.vfs.AfcVolumeMonitor' unit='gvfs-afc-volume-monitor.service' req>
Nov 20 11:17:22 rock-5b systemd[2151]: Starting Virtual filesystem service - Apple File Conduit monitor...
Nov 20 11:17:22 rock-5b dbus-daemon[2181]: [session uid=1000 pid=2181] Successfully activated service 'org.gtk.vfs.AfcVolumeMonitor'
Nov 20 11:17:22 rock-5b systemd[2151]: Started Virtual filesystem service - Apple File Conduit monitor.
Nov 20 11:17:22 rock-5b dbus-daemon[2181]: [session uid=1000 pid=2181] Activating via systemd: service name='org.gtk.vfs.GoaVolumeMonitor' unit='gvfs-goa-volume-monitor.service' req>
Nov 20 11:17:22 rock-5b systemd[2151]: Starting Virtual filesystem service - GNOME Online Accounts monitor...
Nov 20 11:17:22 rock-5b dbus-daemon[2181]: [session uid=1000 pid=2181] Successfully activated service 'org.gtk.vfs.GoaVolumeMonitor'
Nov 20 11:17:22 rock-5b systemd[2151]: Started Virtual filesystem service - GNOME Online Accounts monitor.
Nov 20 11:17:22 rock-5b dbus-daemon[2181]: [session uid=1000 pid=2181] Successfully activated service 'org.freedesktop.thumbnails.Thumbnailer1'
Nov 20 11:17:22 rock-5b systemd[2151]: Started Thumbnailing service.
Nov 20 11:17:22 rock-5b dbus-daemon[2181]: [session uid=1000 pid=2181] Activating via systemd: service name='org.bluez.obex' unit='dbus-org.bluez.obex.service' requested by ':1.31' >
Nov 20 11:17:22 rock-5b systemd[2151]: Starting Bluetooth OBEX service...
Nov 20 11:17:22 rock-5b obexd[3022]: OBEX daemon 5.65
Nov 20 11:17:22 rock-5b dbus-daemon[2181]: [session uid=1000 pid=2181] Successfully activated service 'org.bluez.obex'
Nov 20 11:17:22 rock-5b systemd[2151]: Started Bluetooth OBEX service.
Nov 20 11:17:23 rock-5b pulseaudio[2161]: ALSA woke us up to write new data to the device, but there was actually nothing to write.
Nov 20 11:17:23 rock-5b pulseaudio[2161]: Most likely this is a bug in the ALSA driver '(null)'. Please report this issue to the ALSA developers.
Nov 20 11:17:23 rock-5b pulseaudio[2161]: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
Nov 20 11:17:24 rock-5b kernel: Bluetooth: RFCOMM TTY layer initialized
Nov 20 11:17:24 rock-5b kernel: Bluetooth: RFCOMM socket layer initialized
Nov 20 11:17:24 rock-5b kernel: Bluetooth: RFCOMM ver 1.11
Nov 20 11:17:26 rock-5b pkexec[3088]: pam_unix(polkit-1:session): session opened for user root(uid=0) by (uid=1000)
Nov 20 11:17:26 rock-5b pkexec[3088]: konstantin: Executing command [USER=root] [TTY=unknown] [CWD=/home/konstantin] [COMMAND=/usr/lib/update-notifier/package-system-locked]
Nov 20 11:17:26 rock-5b chronyd[1839]: Selected source 213.141.154.170 (1.ubuntu.pool.ntp.org)
Nov 20 11:17:26 rock-5b chronyd[1839]: System clock wrong by 26557.828622 seconds

The mali update has just arrived, I will continue to test further:

root@rock-5b:~# dpkg -l| grep -e panfork -e mesa
ii  libegl-mesa0:arm64                      23.0~panfork~csf~git221118.18db031~k     arm64        free implementation of the EGL API -- Mesa vendor library
ii  libgbm1:arm64                           23.0~panfork~csf~git221118.18db031~k     arm64        generic buffer management API -- runtime
ii  libgl1-mesa-dri:arm64                   23.0~panfork~csf~git221118.18db031~k     arm64        free implementation of the OpenGL API -- DRI modules
ii  libglapi-mesa:arm64                     23.0~panfork~csf~git221118.18db031~k     arm64        free implementation of the GL API -- shared library
ii  libglu1-mesa:arm64                      9.0.2-1                                  arm64        Mesa OpenGL utility library (GLU)
ii  libglx-mesa0:arm64                      23.0~panfork~csf~git221118.18db031~k     arm64        free implementation of the OpenGL API -- GLX vendor library
ii  mesa-utils                              8.5.0-1                                  arm64        Miscellaneous Mesa utilities -- symlinks
ii  mesa-utils-bin:arm64                    8.5.0-1                                  arm64        Miscellaneous Mesa utilities -- native applications

Tell me if there is anything I can do to help you get a good driver for mali G610 faster

1 Like
#46

What do you mean “reboots stably”? Does it start booting again without going through the normal shutdown process?

That can be an indicator of unstable RAM. Updating the bootloader supposedly fixes that, or you can try lowering the maximum frequency as a workaround:

echo 1560000000 | sudo tee /sys/class/devfreq/dmc/max_freq

#47

After the latest mali panfork update and possibly replacing the power supply with 20V ~ 3.25A, for the first time I managed to watch the 2 hour cartoon until the end without freezing and rebooting, thank you very much for your work.

So I already have a second rock 5b board that I’m testing as a working desktop

It’s strange that yesterday I worked for more than 8 hours with two monitors connected via HDMI and several FireFox windows and many tabs. And it seemed quite stable to me.

But today I installed nvme disk

root@rock-5b:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           1.6G   19M  1.6G   2% /run
/dev/mmcblk1p1   14G  9.6G  3.7G  73% /
tmpfs           7.7G  193M  7.5G   3% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           7.7G  396K  7.7G   1% /tmp
/dev/nvme0n1p1  458G  222M  434G   1% /home
/dev/zram1       47M   12M   32M  27% /var/log
tmpfs           1.6G  128K  1.6G   1% /run/user/1000
root@rock-5b:~# lsblk 
NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
mtdblock0     31:0    0    16M  0 disk 
mmcblk1      179:0    0  14.5G  0 disk 
└─mmcblk1p1  179:1    0  14.3G  0 part /var/log.hdd
                                       /
mmcblk1boot0 179:32   0     4M  1 disk 
mmcblk1boot1 179:64   0     4M  1 disk 
zram0        254:0    0   7.7G  0 disk [SWAP]
zram1        254:1    0    50M  0 disk /var/log
nvme0n1      259:0    0 465.8G  0 disk 
└─nvme0n1p1  259:1    0 465.8G  0 part /home

And today, twice in a row, when trying to open the FireFox browser, the board spontaneously rebooted. After that, I cleared the browser cache and moved it from nvme to /dev/shm. The browser opened, and I continue to work carefully.

Also noticed the messages in the log:

[ 3948.203781] [drm:rockchip_vop2_mod_supported] *ERROR* Unsupported format modifier 0x810000000000001
[ 3948.219861] [drm:rockchip_vop2_mod_supported] *ERROR* Unsupported format modifier 0x810000000000001
[ 3948.242599] [drm:rockchip_vop2_mod_supported] *ERROR* Unsupported format modifier 0x810000000000001
[ 3948.253120] [drm:rockchip_vop2_mod_supported] *ERROR* Unsupported format modifier 0x810000000000001
[ 3948.268994] [drm:rockchip_vop2_mod_supported] *ERROR* Unsupported format modifier 0x810000000000001
[ 3948.285729] [drm:rockchip_vop2_mod_supported] *ERROR* Unsupported format modifier 0x810000000000001
[ 3949.540597] [drm:rockchip_vop2_mod_supported] *ERROR* Unsupported format modifier 0x810000000000001
[ 3949.553298] [drm:rockchip_vop2_mod_supported] *ERROR* Unsupported format modifier 0x810000000000001
[ 3949.569564] [drm:rockchip_vop2_mod_supported] *ERROR* Unsupported format modifier 0x810000000000001
[ 4920.207976] ------------[ cut here ]------------
[ 4920.208007] WARNING: CPU: 1 PID: 12677 at drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:2907 vop2_crtc_load_lut+0x50/0x2d8
[ 4920.208011] Modules linked in: bnep xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter
 bridge stp llc overlay binfmt_misc zstd fuse ip_tables x_tables ipv6 panfrost gpu_sched pgdrv r8125
[ 4920.208099] CPU: 1 PID: 12677 Comm: kworker/u16:1 Tainted: G        W         5.10.72-rockchip-rk3588 #trunk.0102
[ 4920.208102] Hardware name: Radxa ROCK 5B (DT)
[ 4920.208114] Workqueue: events_unbound commit_work
[ 4920.208121] pstate: 40c00009 (nZcv daif +PAN +UAO -TCO BTYPE=--)
[ 4920.208126] pc : vop2_crtc_load_lut+0x50/0x2d8
[ 4920.208131] lr : vop2_crtc_load_lut+0x48/0x2d8
[ 4920.208134] sp : ffffffc01ab13be0
[ 4920.208137] x29: ffffffc01ab13be0 x28: ffffff814ed5fc00 
[ 4920.208144] x27: ffffffc0110b9d98 x26: ffffff8150301e80 
[ 4920.208151] x25: ffffff816e6cc058 x24: ffffff81052e2080 
[ 4920.208158] x23: 0000000000000400 x22: ffffffc0114fd9f8 
[ 4920.208164] x21: ffffff81052e0080 x20: ffffff81052e0080 
[ 4920.208171] x19: ffffff81052e00f8 x18: 0000000000000000 
[ 4920.208179] x17: 0000000000000000 x16: 0000000000000000 
[ 4920.208185] x15: 0000000000000010 x14: 0000000034325258 
[ 4920.208192] x13: ffffffc01ab13b98 x12: ffffffffffffffff 
[ 4920.208199] x11: 0000000000000040 x10: 00000000fffffffe 
[ 4920.208205] x9 : ffffffc0107d4b94 x8 : 0000000000000000 
[ 4920.208212] x7 : ffffff81011c6080 x6 : 00000000000003ff 
[ 4920.208219] x5 : 0000000000000400 x4 : 00000000000003ff 
[ 4920.208226] x3 : 000000003fffffff x2 : 00000000000003ff 
[ 4920.208232] x1 : ffffffc012c1d000 x0 : 0000000000000000 
[ 4920.208241] Call trace:
[ 4920.208247]  vop2_crtc_load_lut+0x50/0x2d8
[ 4920.208253]  vop2_crtc_atomic_flush+0x948/0xc18
[ 4920.208257]  drm_atomic_helper_commit_planes+0x1c0/0x1c8
[ 4920.208264]  rockchip_drm_atomic_helper_commit_tail_rpm+0xa4/0x144
[ 4920.208269]  commit_tail+0x80/0x108
[ 4920.208272]  commit_work+0x1c/0x28
[ 4920.208281]  process_one_work+0x1d8/0x290
[ 4920.208286]  worker_thread+0x1e0/0x270
[ 4920.208291]  kthread+0xf4/0x104
[ 4920.208300]  ret_from_fork+0x10/0x30
[ 4920.208305] 
               PC: 0xffffffc0107d4a9c:

[ 4920.215575] ---[ end trace 2a6242fa207cbbb1 ]---
[ 6400.984118] ------------[ cut here ]------------
[ 6400.984141] WARNING: CPU: 7 PID: 13326 at drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:2907 vop2_crtc_load_lut+0x50/0x2d8
[ 6400.984145] Modules linked in: bnep xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter
 bridge stp llc overlay binfmt_misc zstd fuse ip_tables x_tables ipv6 panfrost gpu_sched pgdrv r8125
[ 6400.984236] CPU: 7 PID: 13326 Comm: kworker/u16:0 Tainted: G        W         5.10.72-rockchip-rk3588 #trunk.0102
[ 6400.984240] Hardware name: Radxa ROCK 5B (DT)
[ 6400.984249] Workqueue: events_unbound commit_work
[ 6400.984259] pstate: 40c00009 (nZcv daif +PAN +UAO -TCO BTYPE=--)
[ 6400.984267] pc : vop2_crtc_load_lut+0x50/0x2d8
[ 6400.984274] lr : vop2_crtc_load_lut+0x48/0x2d8
[ 6400.984278] sp : ffffffc01ada3be0
[ 6400.984282] x29: ffffffc01ada3be0 x28: ffffff814f471000 
[ 6400.984291] x27: ffffffc0110b9d98 x26: ffffff814ef37a80 
[ 6400.984300] x25: ffffff816e524058 x24: ffffff81052e2080 
[ 6400.984308] x23: 0000000000000400 x22: ffffffc0114fd9f8 
[ 6400.984317] x21: ffffff81052e0080 x20: ffffff81052e0080 
[ 6400.984325] x19: ffffff81052e00f8 x18: 0000000000000000 
[ 6400.984335] x17: 0000000000000000 x16: 0000000000000000 
[ 6400.984343] x15: 0000000000000010 x14: 0000000034325258 
[ 6400.984352] x13: ffffffc01ada3b98 x12: ffffffffffffffff 
[ 6400.984360] x11: 0000000000000040 x10: 00000000fffffffe 
[ 6400.984369] x9 : ffffffc0107d4b94 x8 : 0000000000000000 
[ 6400.984377] x7 : ffffff81011c6080 x6 : 00000000000003ff 
[ 6400.984386] x5 : 0000000000000400 x4 : 00000000000003ff 
[ 6400.984394] x3 : 000000003fffffff x2 : 00000000000003ff 
[ 6400.984402] x1 : ffffffc012c1d000 x0 : 0000000000000000 
[ 6400.984411] Call trace:
[ 6400.984419]  vop2_crtc_load_lut+0x50/0x2d8
[ 6400.984427]  vop2_crtc_atomic_flush+0x948/0xc18
[ 6400.984433]  drm_atomic_helper_commit_planes+0x1c0/0x1c8
[ 6400.984442]  rockchip_drm_atomic_helper_commit_tail_rpm+0xa4/0x144
[ 6400.984448]  commit_tail+0x80/0x108
[ 6400.984453]  commit_work+0x1c/0x28
[ 6400.984462]  process_one_work+0x1d8/0x290
[ 6400.984470]  worker_thread+0x1e0/0x270
[ 6400.984477]  kthread+0xf4/0x104
[ 6400.984483]  ret_from_fork+0x10/0x30
[ 6400.984488] 
               PC: 0xffffffc0107d4a9c:

root@rock-5b:~# dmesg | grep -c 'Unsupported format modifier'
1989

dmesg.0 logs after self reboot:

[   23.236146] kernel: dwhdmi-rockchip fde80000.hdmi: use tmds mode
[   23.249592] kernel: dwhdmi-rockchip fde80000.hdmi: use tmds mode
[   23.265794] kernel: dwhdmi-rockchip fde80000.hdmi: use tmds mode
[   23.323465] kernel: enP4p65s0: 0xffffffc015e60000, 00:e0:4c:68:00:a7, IRQ 152
[   24.786472] kernel: bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
[   24.789336] kernel: Bridge firewalling registered
[   25.080300] kernel: mali fb000000.gpu: Loading Mali firmware 0x1010000
[   25.080842] kernel: mali fb000000.gpu: Protected memory allocator not found, Firmware protected mode entry will not be supported
[   26.166229] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[   26.166270] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[   26.166286] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[   26.166301] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[   26.166318] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[   26.166639] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[   26.166664] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[   26.166677] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[   26.166691] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[   26.166704] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[   26.166996] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[   26.167051] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[   26.167098] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[   26.167143] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[   26.167191] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[   26.167499] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[   26.167563] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[   26.167659] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[   26.167728] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22
[   26.167786] kernel: rockchip-i2s-tdm fddf8000.i2s: ASoC: error at snd_soc_dai_hw_params on fddf8000.i2s: -22

root@rock-5b:~# grep -c 'dwhdmi-rockchip fde80000.hdmi: use tmds mode' /var/log/dmesg.0 
811