NanoPi R5S Graphis/GUI issues - Help!

mjmo · 14 January 2025 05:06

Hello All,

I’m coming to this community because it’s one of the best I’ve seen on the linux internet for discussion, problem solving, etc. I posted similar to FriendlyElec forums and it’s been silent, so forgive the faux pas of a cross-post.

I am also not currently running DietPi on the system in question, but at this point would be willing to nuke it and start over (again…) if needed for troubleshooting.

I had a brand new NanoPiR5S delivered a few weeks ago. DietPi was the first thing I installed to it, because it’s great! I was able to install to the eMMC by the method of flashing the DietPi Image to an SD card, booting and setting it up, and then dd-ing the same image file from a usb stick to the eMMC. dd-ing a running system booted as read-only was unsuccessful.

Everything in tty-land works just as snappy as I’d expect for a minimal install on arm. However, no matter what I try to run a minimal GUI…the board refuses to play nice.

I have tried the following:

xorg and xfce on DietPi, installed via dietpi-software
i3 on DietPi, installed via apt
awesomewm on DietPi, installed via apt
FriendlyElec’s official bullseye desktop (LXDE) image via eflasher
FriendlyElec’s official minimal bookworm image via eflasher, with xfce4 installed via apt
An alternative base debian install from here
- xfce4 on xorg via apt
- KDE plasma on Wayland via apt

I am getting laggy, glitchy gui performance in all cases, (seemingly) identical symptoms for all of them. My desktop environment needs are very light: putty and a browser, and a remote desktop client. Navigating gui menus has a second or more of lag, ui elements are sometimes flickering. Browsers are slow to render, despite the machine having no apparent bottlenecks to my fast home network, in fact in one case it’s loading a device’s local web UI over a direct 2.5Gb connection.

NoMachine is my go-to remote desktop platform, it’s what I use on all my other machines (without issue). It seems to be partially responsible, using 50-70% CPU all by itself. I have not attempted an alternative yet, something like x11vnc should be less demanding? But it seems like NoMachine isn’t really the root of the issue, the machine is struggling to do the most basic graphical tasks even before NoMachine is installed.

My google-foo has been minimally helpful, partially because this is kind of a niche problem, partially because some of the discussion of graphics drivers and anything with the kernel is over my current knowledge/experience level. If I’m interpreting it all correctly, it seems that either:

The default mesa/permafrost/lima packages on Debian are not supported by/do not support the specific chipset (RK3568B2 with integrated Mali G-52 GPU).
Nobody’s image for this chipset has whatever it needs in the kernel to actually RUN the Mali GPU or make use of it for hardware acceleration (if that is nonsense, it’s evidence of my lack of knowledge in graphics ).
Maybe my google-foo has truly failed me and I’ve missed some obvious dependency or other step in installing and setting up this system?

Thank You!
MJ

Jappe · 14 January 2025 09:43

It’s a dev board and not a desktop computer. Only 4 cores @ 2 GHz and the eMMC is also slow (or slower than an SSD attached via USB3).

How much RAM does your board have? Did you monitor some ressource, like RAM? Maybe it’s full and the swap comes into play, which is really slow then.

mjmo · 14 January 2025 15:36

4GB RAM, here is the more detailed spec from FriendlyElec.

I will have to do more monitoring to collect concrete data on resource utilization.

I’m certainly not expecting it to be a workhorse, but I am surprised that it can barely function running just a simple desktop environment, and that that is even the case with the desktop image shipped by the manufacturer.

Joulinar · 14 January 2025 18:29

I’m not sure what exactly the expectation is now if the manufacturer’s image already has this behavior?

MichaIng · 15 January 2025 09:01

Probably you get (better) hardware acceleration with newer Mesa drivers. Try our NanoPi R5S Trixie image from here: Index of /downloads/images
Or enable backports: OrangePi5 video hardware acceleration - #4 by MichaIng

Mesa/Panfrost is generally supporting the G52 since a longer time, but not sure how well, or how much to expect from it. Did you run some test or chrome:gpu in Chromium or so to check, whether really no hardware acceleration is available/used?

usual-user · 18 January 2025 09:17

For me, a device with a RK3568B2 SoC works quite well, see glmark2-odroid-m1.log (24.8 KB) here for reference.
Of course, it can’t compete with a device with a better-specified Mali GPU, see glmark2-odroid-n2+.log (24.9 KB) here for reference.
But if you want better performance, you also have to invest in appropriate hardware.
For a desktop application, a RK3568B is always sufficient, provided it has access to an appropriate amount of RAM.

mjmo · 19 January 2025 15:48

Thanks all for contributions so far.

I attempted to capture some system info today…the system was very laggy and ultimately locked up. Now when I boot it will freeze at the login screen and not accept any keyboard or mouse input. I am going to start over with @MichaIng suggestion of using the Trixie image. Quick question before I image the eMMC, is there any firmware I need to install first, or leave installed, or does that all live on mmcblkboot0/mmcblkboot1? As far as I understand it from reading previous threads on the device, once booted into a running system on the SD card, I should be able to dd an image file directly to the eMMC. lmk if that’s incorrect, I’ll check back before imaging.

@usual-user , I don’t have the full log but the final score when running glmark2 was 70…

I was able to run chrome:gpu and a few lines related to video en/decoding were marked as yellow with something to the effect of “no hardware” or no access to hardware. Unfortunately I didn’t capture this before rebooting, I had planned on running it again but then experienced the locked up login screen.

MJ

usual-user · 19 January 2025 17:24

This is the OS currently running on my SBCs:

All that is needed is a suitable firmware that can start the OS and usually an up-to-date mainline kernel with in-flight patches added, because SoC development is bleeding edge if you don’t want to use manufacturer-legacy code.
But the RK3568 SoC support is already quite mature and recent kernels are almost usable out-of-the-box.
And the mainline firmware source code is usually already available.
For me, it is only necessary to build the firmware, since it cannot be supplied by fedora because of manufacturer license conditions and then I’m ready to go.
I rebuild the kernel regularly anyway to follow the current development.
Everything else is recent native standard aarch64 OS software, nothing device-specific.

mjmo · 20 January 2025 00:52

For firmware I was mainly making sure I wouldn’t be missing a step or wiping something necessary off the device by using dd to put an OS image on the eMMC.

@usual-user It sounds like from what you’re saying, my previous system builds have consistently lacked what they needed in the kernel to run the integrated GPU on the RK3568?

Do you know if the Trixie DietPi image has what’s needed? (What specifically IS needed?). I am a relative newcomer to Linux systems and compiling my own kernel for a system image is a process I have no experience with (yet).

Thanks

mjmo · 30 January 2025 12:54

Ok, I started fresh with the DietPi trixie image and installed LXDE. Similar performance, per chrome:GPU hardware acceleration is NOT enabled. glmark2 score was extremely low. Nvtop reports the following:

mpca@DietPi:~$ nvtop
profile parameter not implemented in Panfrost
No GPU to monitor.

about-gpu-2025-01-30T06-10-52-885Z.txt (40.8 KB)
glmark2-2501290033.txt (6.2 KB)

usual-user · 31 January 2025 04:13

For me, the WEB browsers I use work as expected:

You are running a recent Mesa which makes use of the Mali GPU, but:

You are running a Xwindow driven DE, which works by design very inefficient with render nodes.
See my glmark2 --off-screen runs to get an impression of the influence of the display sub-system.
There is a reason why Wayland exists.

You are running a kernel that dates back to a time before nvtop support landed.

mjmo · 31 January 2025 13:43

Then is hardware acceleration being enabled/disabled a matter of a setting being changed?

I had similar performance issues on KDE Plasma with Wayland, but I don’t know if it was the same version of mesa.

usual-user · 31 January 2025 15:54

To confirm that the GPU is working correctly in your environment, publish the contents of the glmark2-es2.log created with this command:glmark2-es2 --off-screen |& tee glmark2-es2.log

mjmo · 1 February 2025 19:28

output file attached, I also captured some screen recordings showing the amount of lag going on.

glmark2-es2.log (2.9 KB)

EDIT: Uninstalled LXDE and installed KDE Plasma, reran glmark2-es2:
glmark2-es2-kde.log (2.9 KB)

usual-user · 1 February 2025 22:46

If you compare your log with the corresponding snippet of my log, you will see that you get similar numbers as I did.
So your GPU works perfectly as expected and my assumption that the display subsystem cannot use the performance of the GPU is confirmed.
If you compare it to the log snippet with screen output, you can see that my display subsystem loses round about 150 frames, but there are plenty left that have to be dropped on the floor because my monitor can only display 60 frames per second.
So the display subsystem of your environment is much less efficient.
Watch a small Screencast.webm that shows how my environment works.

mjmo · 1 February 2025 23:33

So what is the difference in our systems, and what specifically do I need to do on mine to get it working right? (Sorry, like I said, kernel and driver stuff is a bit beyond my experience)

usual-user · 2 February 2025 09:07

The kernel and drivers are in a proper state, as you’ve proven, so there’s nothing to do here.

It is probably due to the components from which the OS is constructed. The only thing that is stable for me about a Debian based system is the use of outdated software stacks.
So I’ll repeat it again:

The emphasis is on “recent”, i.e. it does not have to be the last available development versions, but at least the last release versions.
And that usually takes a very long time until these current versions trickle into Debian.

mjmo · 22 February 2025 18:05

Thank you, this explanation is helpful.

Unfortunately I think this means I have to abandon the project. Rebuilding the kernel or building a modified image of a more updated OS that can boot on this chipset is not beyond my ability to learn, but its certainly something I don’t have spare cycles to learn.

There don’t seem to be really concise guides for the process, since it relies on extensive existing knowledge and experience. If you can point me to any resources they may be helpful in the future. I got the device so I could use it, and this is keeping me from doing that, so I think I have to consider other options at this time .

Thank you everyone for your input.
MJ