THE OFFICIAL ROCKCHIP-LEGACY MULTIMEDIA INTEGRATION | Switching All rockchip armbian base image using BSP-kernel

[FusionPlmH]

It is just released in last december,which start to bring us a most stable and suitable kernel with fully hardware and software support.

Although the kernel stable branch is still at 4.4 but we can bump and using their develop branch of 4.19 (still little bit old) but stable .

Link to rockchip BSP-kernel : https://github.com/rockchip-linux/kernel

Description link about armbian : https://forum.armbian.com/topic/16516-rk3399-legacy-multimedia-framework/

Main beif 👍 -Accelerated GLES/EGL X desktop -Accelerated Chromium, with WebGL and video display acceleration -Desktop video player capable of smooth 4K HEVC-HDR -RKMPP-accelerated MPV -ISP Camera with real-time h.264/1080p HW encoding -OpenCL 1.2 support -Kodi 18.9 Leia with full RKMPP+GBM acceleration, 4K-HDR capable -Full collection of Kodi binary add-ons -OpenGL 2.1 support through the gl4es wrapper

[FusionPlmH]

Now I am using this image : https://redirect.armbian.com/region/EU/nanopim4v2/Buster_legacy

[FusionPlmH]

Related devices: Nanopi M4/V2 Nanopi Neo 4 Nanopi T4

Not sure (Using Stock Image or armbian?): Rockpi 4 RockPro 64 Odroid N1 Firefly rk3399

[MichaIng]

Many thanks for your suggestion, but actually I don't see going backwards with the Linux version and using closed-sourced driver blobs being any step for the future. It has been a major pain indeed that mainline kernel and userspace libraries still lack major GPU acceleration for most ARM SoCs, but from all I know this will change with Bullseye, i.e. v20.x of the open Mesa drivers, which in cases even provide better acceleration than the Rockchip Mali blobs, at least from what I read.

We will switch to the official Debian kernel then, for all Armbian-based images where the Debian kernel ships a device tree already. For the others we'll stay with Armbian but Bullseye to increase GPU support, and migrate them to the Debian kernel as fast as it has the device tree included.

[FusionPlmH]

You are right BSP once dont has future at all , just can provide a stable at this moment without any future . But base on my collection about new driver from newest kernel , it still not perform very well as a lot of function is missing .

[MichaIng]

AFAIK it also depends on the exact SoC. I mean it's great to have this option for users which require certain GPU features or where Mesa drivers still do not perform well, but from my time and abilities to provide and maintain official images, I need a future prove generic solution, which I see in Debian mainline images and Mesa drivers only, currently.

So other bases would mean community-provided images, or e.g. a page in our new docs about how to create them, which refers to the PREP script. It should be possible to create a DietPi image based on Armbian legacy, install graphics/GPU software through dietpi-software and then install the media script package on top of it to replace the GPU/display drivers/libs and X.org config. I didn't have a closer look into it, but the media script included all necessary replacements and changes a way that works fine on top of DietPi.

[FusionPlmH]

Just trying your newest image build today , This issues happen again . Just using ssh login at first time but it show to me that it have been working at another screen

[FusionPlmH]

Just trying your newest image build today , This issues happen again . Just using ssh login at first time but it show to me that it have been working at another screen

solution found here: https://dietpi.com/phpbb/viewtopic.php?t=5986

But this issues happen ever time on this device , evevn i reflash the image

[FusionPlmH]

Running with pihole+unbound install using dietpi-sowftware , replacing the default pihole ad list anf unbound scripts from below：

https://github.com/neodevpro/neodevhost

https://github.com/FusionPlmH/unbound/blob/master/pi-hole.conf

[MichaIng]

Uff, there is another autologin override on the serial console 🙈:

rm -R /etc/systemd/system/serial-getty@.service.d/
reboot

Fixed for new images: https://github.com/MichaIng/DietPi/commit/aaa6a5f66a094d7fb7e3ef4a2ef95e9174f20072 Re-patching the 5 cases...

[FusionPlmH]

well another very strange problem：

case 1: It will hangout after 6~10 hrs ,you cant get into ssh terminal .

case 2:Totally random crash with unknown reason,but found similar thread on Armbian :https://forum.armbian.com/topic/15047-nanopi-m4v2-randomly-crashes/

case 3 ：System sometimes not bootingup after uboot screen ,no hdmi output

[FusionPlmH]

Uff, there is another autologin override on the serial console 🙈:

rm -R /etc/systemd/system/serial-getty@.service.d/
reboot

Fixed for new images: aaa6a5f Re-patching the 5 cases...

this not a big problem ,not affected daily stable

[FusionPlmH]

Or maybe change the heading to m4v2 rk3399 general stability improvement ?

[FusionPlmH]

well another very strange problem：

case 1: It will hangout after 6~10 hrs ,you cant get into ssh terminal .

case 2:Totally random crash with unknown reason,but found similar thread on Armbian :https://forum.armbian.com/topic/15047-nanopi-m4v2-randomly-crashes/

case 3 ：System sometimes not bootingup after uboot screen ,no hdmi output

For case 2 base on the Arabian discussion maybe we should lower the cpu freq and change the cpu gov.

[MichaIng]

@FusionPlmH You don't use a desktop or other GUI/X application, do you?

If so, please try:

echo 'blacklist panfrost' > /etc/modprobe.d/blacklist-panfrost.conf
rmmod panfrost

[FusionPlmH]

@FusionPlmH You don't use a desktop or other GUI/X application, do you?

If so, please try:

echo 'blacklist panfrost' > /etc/modprobe.d/blacklist-panfrost.conf
rmmod panfrost

Ys, i dont use any GUI/X application . Let me try it this two days

[FusionPlmH]

It seem fix the problem at this moment , but here i recommand force the max cpu freq to 1.8ghz only becasue rk3399 is 1.8ghz , only rk3399 is 2.0ghz . Although we still can mannered to run aat 2.0 ghz all the time without any trouble , we still want to make it more stable .Let us force the max cpu freq at 1.8 ghz for better stability

[MichaIng]

As long as there is no actual crash report due to that default clock rate, I think we'll leave it as it is now. It can be easily adjusted via dietpi-config > Performance Options > CPU Frequency Limits.

We'll migrate to the Debian distro kernel soon anyway, so I want try to keep additional Armbian-related workarounds at a minimum.

If the panfrost kernel module is indeed the culprit that leads to random crashes, then we should blacklist it for now on all systems, even that this further breaks GPU acceleration 🤔. Would be great if you could run your board at 2 GHz with the panfrost module blacklisted and report back as fast as any crash still happens. If everything runs stable, we can report this at Armbian forum and refresh the thread, so hopefully devs have a deeper look how the module can have an effect on the system stability even when not being used by any graphical software, especially when not even user-space drivers (Mesa) are installed.

[MichaIng]

I'm marking this as closed. We'll not going to maintain legacy images but go forward instead, providing Bullseye images soon with much better Mesa GPU acceleration.