Jump to content

Rock64 Rockchip_dri driver missing


Stuart Naylor

Recommended Posts

 /usr/lib/dri/rockchip_dri.so just doesn't exist but not really sure if the xorg package is the xenial one or rockchip one.

If it is the rockchip one then for some reason rockchip_dri.so isn't being built.

On a startx it gives it a good go but always drops out to software rendering because its missing the above.



 

Link to comment
Share on other sites

Yeah puzzled by the community images as the git repo's seem to be there for the Rockchip graphics framework.

Just trying to use libmali and get glamour going for X11 and sort of given in.

The status matrix sort of looks like a solution can be compiled even though mainline is still a WIP

http://opensource.rock-chips.com/wiki_Status_Matrix

libmali-rk-utgard-2th-r7p0 - The mali library for Rockchip RK3328 (32bit) either doesn't like the kernel space driver or the xserver / mali / kernel is somewhere out of sink.

Xorg & kernel logs don't tell me a lot apart from I bang out with a segmentation fault.

 

[    10.987] (II) xfree86: Adding drm device (/dev/dri/card0)

[    10.988] (II) no primary bus or device found

[    10.988]  falling back to /sys/devices/platform/display-subsystem/drm/card0

[    10.988] (II) LoadModule: "glx"

[    10.988] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so

[    10.992] (II) Module glx: vendor="X.Org Foundation"

[    10.992]  compiled for 1.19.3, module version = 1.0.0

[    10.992]  ABI class: X.Org Server Extension, version 10.0

[    10.992] (II) LoadModule: "modesetting"

[    10.993] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so

[    10.993] (II) Module modesetting: vendor="X.Org Foundation"

[    10.993]  compiled for 1.19.3, module version = 1.19.3

[    10.993]  Module class: X.Org Video Driver

[    10.993]  ABI class: X.Org Video Driver, version 23.0

[    10.993] (II) modesetting: Driver for Modesetting Kernel Drivers: kms

[    10.994] (II) modeset(0): using drv /dev/dri/card0

[    10.994] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support

[    10.994] (II) modeset(0): Creating default Display subsection in Screen section

"Default Screen Section" for depth/fbbpp 24/32

[    10.994] (==) modeset(0): Depth 24, (==) framebuffer bpp 32

[    10.994] (**) modeset(0): Option "AccelMethod" "glamor"

[    10.994] (==) modeset(0): RGB weight 888

[    10.994] (==) modeset(0): Default visual is TrueColor

[    10.995] (II) Loading sub module "glamoregl"

[    10.995] (II) LoadModule: "glamoregl"

[    10.995] (II) Loading /usr/lib/xorg/modules/libglamoregl.so

[    11.014] (II) Module glamoregl: vendor="X.Org Foundation"

[    11.014]  compiled for 1.19.3, module version = 1.0.0

[    11.014]  ABI class: X.Org ANSI C Emulation, version 0.4

[    11.014] (II) glamor: OpenGL accelerated X.org driver based.

[    11.049] (EE) 

[    11.049] (EE) Backtrace:

[    11.049] (EE) 

[    11.049] (EE) Segmentation fault at address 0x10

[    11.049] (EE) 

Fatal server error:

[    11.049] (EE) Caught signal 11 (Segmentation fault). Server aborting

But the kernel is loading and libmali-rk-utgard-2th-r7p0 is installed but is grabbing from the glx module

 

Oct  6 04:19:00 rock64 kernel: [    3.984499] mali-utgard ff300000.gpu: resource[4].start = 0x0x0000000000000013

Oct  6 04:19:00 rock64 kernel: [    3.990333] mali-utgard ff300000.gpu: resource[5].start = 0x0x0000000000000014

Oct  6 04:19:00 rock64 kernel: [    3.996105] mali-utgard ff300000.gpu: resource[6].start = 0x0x0000000000000015

Oct  6 04:19:00 rock64 kernel: [    4.001815] mali-utgard ff300000.gpu: resource[7].start = 0x0x0000000000000016

Oct  6 04:19:00 rock64 kernel: [    4.007480] mali-utgard ff300000.gpu: resource[8].start = 0x0x0000000000000017

Oct  6 04:19:00 rock64 kernel: [    4.013018] D : [File] : drivers/gpu/arm/mali400/mali/platform/rk/rk.c; [Line] : 518; [Func] : mali_platform_device_init(); to add platform_specific_data to platform_device_of_mali.

Oct  6 04:19:00 rock64 kernel: [    4.019593] mali-utgard ff300000.gpu: Looking up mali-supply from device tree

Oct  6 04:19:00 rock64 kernel: [    4.021553] Mali: Mali device driver loaded

Oct  6 04:19:00 rock64 kernel: [    4.028062] ALSA device list:

Oct  6 04:19:00 rock64 kernel: [    4.033448]   #0: HDMI

Oct  6 04:19:00 rock64 kernel: [    4.038635]   #1: I2S

Oct  6 04:19:00 rock64 kernel: [    4.043777]   #2: SPDIF

Oct  6 04:19:00 rock64 kernel: [    4.049603] Freeing unused kernel memory: 1152K (ffffff8008fb0000 - ffffff80090d0000)

aint a clue to what  D : [File] : drivers/gpu/arm/mali400/mali/platform/rk/rk.c; [Line] : 518; [Func] : mali_platform_device_init(); to add platform_specific_data to platform_device_of_mali. is supposed to mean mali450 but maybe that is just generic.


 

Link to comment
Share on other sites

Hi I've had similar issue on older images (<0.6.x), having missing  /usr/lib/dri/rockchip_dri.so in logs

but since 0.6.25 it seems ok (kernel and various graphics related libraries bumped)

I was lucky with xenial-minimal-rock64-0.6.25-193-armhf.img and `apt update && apt upgrade` and `install_desktop.sh mate`

Link to comment
Share on other sites

9 hours ago, vasekch said:

Hi I've had similar issue on older images (<0.6.x), having missing  /usr/lib/dri/rockchip_dri.so in logs

but since 0.6.25 it seems ok (kernel and various graphics related libraries bumped)

I was lucky with xenial-minimal-rock64-0.6.25-193-armhf.img and `apt update && apt upgrade` and `install_desktop.sh mate`

 

Link to comment
Share on other sites

Aah cheers for the heads up as was staying clear of the pre-releases.
You having no probs then as when I last tried pre xMas they where out of sync with Artful and not working at all.

Looks like Ayufan is just supporting LTS as artful is now bionic which is prob wise.
Shame as I was actually just running Kodi via X on its own but guess it will be april before anything solid.
Guess I could try backporting from artful now that the xenial image seems a little more stable and get back to remembering what arm libs where missing from xbmc :) maybe not with artful.

Link to comment
Share on other sites

If I'm not wrong, that error is due to Mali not supporting OpenGL, but only OpenGL ES. In other words: there is no rockchip_dri.so, it just doesn't exist anywhere, and I don't think it will exist.

 

Rockchip provides a tweaked X server that gives you glamor acceleration through OpenGL ES, but it only works for mali midgard  (RK3288 and 3399). However, you can get 3D acceleration for your RK 3288 3328 (sorry, typo) through the armsoc driver. If you are interested, I can give you more info on it.

Edited by JMCC
Link to comment
Share on other sites

On 3/14/2018 at 10:05 AM, JMCC said:

If I'm not wrong, that error is due to Mali not supporting OpenGL, but only OpenGL ES. In other words: there is no rockchip_dri.so, it just doesn't exist anywhere, and I don't think it will exist.

 

Rockchip provides a tweaked X server that gives you glamor acceleration through OpenGL ES, but it only works for mali midgard  (RK3288 and 3399). However, you can get 3D acceleration for your RK 3288 3328 (sorry, typo) through the armsoc driver. If you are interested, I can give you more info on it.

 

I'd be interested in knowing more about what armsoc driver you're referring to what libraries it provides :)

Link to comment
Share on other sites

I don't have a Rock64 to test, but here are some clues that might help you to make it work:

 

First, you need to make sure the kernel has the right drivers. I'm not familiar with the Ayufan kernel we use in Armbian as source, so I cannot help you with that.

 

Second, you need to install the libs:

wget https://github.com/rockchip-linux/rk-rootfs-build/blob/master/packages/armhf/libmali/libmali-rk-utgard-450-r7p0_1.6-1_armhf.deb
sudo dpkg -i libmali-rk-utgard-450-r7p0_1.6-1_armhf.deb

 

Third, you need to fix the permissions. I think for mali 450 you can manage by adding to /etc/rc.local something like the following:

chmod 666 /dev/mali*
chmod 666 /dev/ump*

Again, not sure since I cannot test.

 

Fourth, install the armsoc driver. Rockchip's X server and driver are for Debian Stretch, but I compiled a version for Ubuntu Xenial. Provided that the steps above are OK:

  1. Download the 7z archive: https://mega.nz/#!oywWCaDA!wDtzXQuohJeVDuePCxHej4xkqDfUmhaPj6XNU7ZXyCk
  2. Unzip it
  3. cd xserver-1.18-ubuntu
  4. sudo dpkg -i *.deb
  5. sudo apt -f install

 

Fifth (and last), backup /etc/X11/xorg.conf.d/01-armbian-defaults.conf, and edit like the following:

Section "Device"
        Identifier      "Mali-Fbdev"
        Driver          "armsoc"
        Option          "fbdev"         "/dev/fb0"
        Option          "Debug"         "false"
        Option          "DPMS"          "false"
        Option          "NoFlip"        "true"
        Option          "SWcursor"      "true"
        #Option         "InitFromFBDev" "false"
EndSection

Section "ServerLayout"
        Identifier      "Default Layout"
        Option          "BlankTime"     "0"
        Option          "StandbyTime"   "0"
        Option          "SuspendTime"   "0"
        Option          "OffTime"       "0"
EndSection

Section "DRI"
        Mode            0666
EndSection

Give it a try. You may need to add/modify many things, but this will give you a starting point.

Link to comment
Share on other sites

They estimated a 6 month to 12 month development cycle to get the libdrm and the libmali drivers working with the 3328.  Right now, there is absolutely no support for their drivers, playback doesn't work, and they are working on getting Chromium working. It is a real shame. Their drivers are built for the 3288 and the 3399 boards, which are entirely different from the 3288. The last I read about this, there was a musing from the kernel community about getting drm and mali support baked into the kernel for these boards. I doubt that went anywhere. 

 

I also cannot fathom why they would custom build xorg. That seems like far more trouble than it was worth. 

 

As is, this board is a really kick ass headless server and within a year, I suspect that the Rpi4 will blow it out of the water and have omxplayer. 

Link to comment
Share on other sites

2 hours ago, bholland said:

I suspect that the Rpi4 will blow it out of the water and have omxplayer

 

Well, without completely abandoning the entire software base it currently relies on, that's not possible.  TBH technology wise, RPi hasn't been "the one to beat" in several years, there's no reason to suspect it will be any time soon.  It's strength comes from the commonality and community it has.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines