Whats the right kernel / OS for me ?

[H_Berger]

Hello all, 

 

I'm also bought an orange pi 5 pro :-) 

I have red a little bit in the Forum (after i'm bought) and I'm a little bit confused now 🙂
I'm new in the embedded (arm) world but have some knowledge from the desktop/x86 windows & linux world.  

my first expirience with the device was also .... intresting. 

I'm installed the official (orangepi.org) debian-booksworm image with the 6.1.xx kernel .... and diddnt get the network interfaces to run, and no nvme device available ... 

next try was with debian-booksworm image and the 5.10..xx kernel and the networks just runned and the nvme showed up. But i think for my need this kernel is just old ... 

So now im trying armbian (iot version) ..... at the moment with an 6.1.99 vendor kernel. 
installed weston seatd & co for running some rudimentary OpenGL ES based tests .... but without success. 
glxgears / glxinfo failing EGLInitialize() cannot create context ... rknpuxxxx.so not found. 
i think thats the "which /dev/dri device is the right" issue. Have also red that some HW functionally is only available on full blown desktop environments 😞

What do I need: 
- i dont want to use the  device as a desktop replacement

- i want to use it as development board for tinkering around with OpenGL ES / OpenCL  and get some experience with embedded development. 
- rudimentary boot2qt functionality based on wayland-egl or eglfs platform (running Qt apps in wayland cage or without window manager)
- good opengl es 3.2 support 

- recent compiler support,  gcc13(+)  /  clang 18 

- boost / qt 6.7 + should available as devel packages (don't like to build it for my own, but if its necesarry ...)

- opencl support would be nice 

- media / audio support (QMultimedia)

- atm i dont need video acceleration, but maybe later .... 

 

So my question:

 

with which Kernel / System should i start with ? 
is the device a good choice ? I bought it mainly because the 2 nics and the available storage options (nvme / emmc) makes it very flexible for another usage (router backup i.e)
Soon or later i have to dig into yocto also maybe .... 
 

Edited May 28 by H_Berger

[Werner]

Hi

 

15 minutes ago, H_Berger said:

I'm new in the embedded (arm) world but have some knowledge from the desktop/x86 windows & linux world. 

We all started at some point. But overall prepare for some frustration

 

16 minutes ago, H_Berger said:

orange pi 5 pro

We don't support this device. Support was added via community effort. May work, maybe not. We don't know nor do we track status of such configurations.

 

Regarding OPi5+. It is using - in terms of ARM socs - a fairly recent SoC, the Rockchip RK3588. Mainline support is far from feature-complete. Will take a few additional years to complete.

If you need an almost feature-complete kernel, you have to use vendor branch which is based on Rockchip BSP. current (Linux 6.12.y LTS at this time) has basic support for rk3588 and is good enough for general server application, though for your usecase might not be enough. This branch will receive fixes only but no new features.

edge may be sufficient.

 

When using some graphics related I suggest to use an image with mesa-vpu extension included.

Also there a two ways to make use of it:

- We backported the open source Panthor driver into vendor. Can be enabled via device tree overlay (check armbian-config)

- Using proprietary mali blobs is also possible. I think Jellyfin has a tutorial how to setup those: https://jellyfin.org/docs/general/post-install/transcoding/hardware-acceleration/rockchip/

[H_Berger]

Thanks for your answer 🙂 

 

Zitat

We don't support this device.

Thats what I'm also not understand .... 
You (premium) support the radxa 5B or so, it has exactly the same Chip .... what does this exactly mean ? 

And you are completely right, 
the SOC world looks like so depressing, regarding the gap between the promises of the SOC producers and what you really can use .... 🙂 

[Werner]

https://docs.armbian.com/User-Guide_Board-Support-Rules/

Quote

supported is not applied to a “board family” or group of related SBCs. It is per board

support a whole soc family would be impossible. For example a vendor could do a poor implementation of something which could never work but we "support" it and people complain why it doesn't but there would be literally nothing we could do about.