GPU driver?

[Konstantin Gontarenko]

Hi.

 

I need hardware OpenGL ES, at least 2.0.

 

I’ve tried this https://github.com/rockchip-linux/libmali

It works OK on latest Asus OS 2.0.1, but for Armbian 5.33 kernel 4.4.88 it doesn’t:

 

ERROR: The DDK is not compatible with any of the Mali GPUs on the system.

The DDK was built for 0x750 r0p0 status range [1..1], but none of the GPUs matched:

Segmentation fault

 

I don’t have much experience with Linux, but IMO it might mean the kernel + userland parts of the GPU driver are incompatible.

 

Is there a working GPU driver for Mali-T76x on Armbian?

 

Thanks in advance!

Regards, Kosta.

[Myy]

First thing : Check if you have a /dev/mali0 node. If it is not present, the kernel-space drivers are not loaded and the user-space binary drivers will not work.

Then : Check if your user have the rights to write into /dev/mali0. You can try the evil chmod 0666 /dev/mali0 as root and see if it resolves the issue as a user.

Finally : Ensure that you're using the drivers correctly.

 

Something like :

LD_PRELOAD=/path/to/userspace/drivers/x11 ./your_gles2_app_using_x11

Or

LD_PRELOAD=/path/to/userspace/drivers/wayland ./your_gles2_app_using_drm_kms

 

[Konstantin Gontarenko]

The demo app I’m trying to build uses DRM DMS.

OK, tried linking to mali-midgard-t76x-r13p0-r0p0-wayland. The result is very similar:

 

ERROR: The DDK is not compatible with any of the Mali GPUs on the system.

The DDK was built for 0x750 r0p0 status range [1..1], but none of the GPUs matched:

failed to initialize

failed to initialize EGL

 

I have the device:

 

$ ls /dev/mali*

/dev/mali0

 

After sudo chmod 0666 /dev/mali0 the error message changes to

 

file /dev/mali0 is not of a compatible version (user 10.4, kernel 10.1)

ERROR: The DDK is not compatible with any of the Mali GPUs on the system.

The DDK was built for 0x750 r0p0 status range [1..1], but none of the GPUs matched:

file /dev/mali0 is not of a compatible version (user 10.4, kernel 10.1)

failed to initialize

failed to initialize EGL

 

It’s strange it says “kernel 10.1”, my kernel is 4.4.88:

 

$ uname -r

4.4.88-rockchip

 

Does it means latest Armbian ships with outdated GPU driver in the kernel? If yes, how can I update?

[Konstantin Gontarenko]

Here’s the code I’m trying to compile:

 

https://gist.github.com/Miouyouyou/89e9fe56a2c59bce7d4a18a858f389ef

 

Compilation command line:

 

gcc -o drmgl Linux_DRM_OpenGLES.c -l mali-midgard-t76x-r13p0-r0p0-wayland -ldrm -I /usr/include/drm/

 

Userland parts of the GPU drivers are installed in /usr/local by the default  installer, i.e. I executed

 

git clone https://github.com/rockchip-linux/libmali.git

cd libmali

cmake .

make

sudo make instal

[Konstantin Gontarenko]

Tried another userland driver, from https://developer.arm.com/products/software/mali-drivers/user-space, the one under Firefly, the file name “malit76xr12p004rel0linux1wayland.tar.gz”

 

This one says

file /dev/mali0 is not of a compatible version (user 10.2, kernel 10.1)

 

Getting closer, but still doesn’t work.

 

Where can I get the complete GPU driver, both kernel and userland parts, for latest Armbian 5.33 Tinkerboard Ubuntu xenial default?

 

Thanks in advance!

[TonyMac32]

Please post the result of "sudo armbianmonitor -u"

[Konstantin Gontarenko]

Here’s the log, slightly redacted (personal info):

http://const.me/tmp/armhwinfo.log

[TonyMac32]

Hmmm,

 

[    2.476623] I : [File] : drivers/gpu/arm/mali400/mali/linux/mali_kernel_linux.c; [Line] : 389; [Func] : mali_module_init(); svn_rev_string_from_arm of this mali_ko is '-5396f8a', rk_ko_ver is '5', built at '17:24:43', on 'Sep 21 2017'.
[    2.477004] Mali: Mali device driver loaded

 

[    3.350314] mali ffa30000.gpu: GPU identified as 0x0750 r0p0 status 1
[    3.355880] mali ffa30000.gpu: Probed as mali0

 

 

OK, so it probes properly but a strange loading message.  I'l take a look, but I'm not sure what's going on. 

[Konstantin Gontarenko]

Thanks in advance!

 

BTW, I’ve already saw that “-5396f8a” string, I was it in the output of the following command:

$ cat /sys/module/mali/version

-5396f8a

 

Found the command searching for the version of the kernel-mode half of the GPU driver.

[TonyMac32]

OK,

root@tinkerboard:/sys/module/mali_kbase# cat version
r9p0-05rel0 (UK version 10.1)

This is 5 revisions out of date for Rockchip (r14p0) .  Also, that mali 400 stuff shouldn't be in there, it was in the kbuild but not in the kconfig [edit] I seem to be blind, it is in the kconfig [/edit], @Myy correct me if I'm wrong but they should not have any interdependent code, right?  I pulled it out and it built fine and I get the module. 

 

This may take some work, unless you can get the r9p0 userspace I wouldn't expect an immediate quick fix, I will get to work on it though as it's useless to anyone if they don't have a usespace driver.

[Konstantin Gontarenko]

Thanks a lot for the info. As far as I understood, there’s no hardware 3D acceleration in the current stable version on Armbian for RK3288.

 

What about the “next” version of armbian, the one with kernel 4.13.3?

 

Kernel GPU driver there is r19p0-01rel0 (UK version 10.6).

 

It appears to be compatible with the latest userland components from libmali repository (i.e. I was able to compile & run a simple demo). Apparently they have one-way compatibility, i.e. userland driver 10.4 (the latest available on Rockchip’s github) is compatible with kernel driver 10.6.

 

The only problem is resolution is stuck to 1280x1024. Do you happen to know a quick way to change HDMI resolution in kernel 4.13.3? I don’t even need that EDID magic that automatically works in 4.4.88 kernel, manually is fine too. Tried adding

disp.screen0_output_mode=1920x1080p60

to /boot/armbianEnv.txt but that did nothing.

 

Also, are there some issues with that pre-release armbian build? Besides GL ES, I gonna need Ethernet, wifi, second DSI-connected touch screen display (official one from rPi), and an SPI interface for a custom chip. Can I reasonably expect the drivers for that hardware will work with the pre-release kernel?

 

Thanks in advance.

[TonyMac32]

5 hours ago, Konstantin Gontarenko said:

As far as I understood, there’s no hardware 3D acceleration in the current stable version on Armbian for RK3288

No, there is, it's release r9p0, which is becoming difficult to find the userspace portion of.  That's quite different from there being none, you just happen to be the first individual to voice the difficulty.  I am reviewing the options for patching it to a level even with Rockchip.

 

Adding display resolutions: I have not attempted it, it is a bit involved, I can look at it after getting the Mali updated.

 

Touchscreen: the Asus driver is garbage.  The rpi driver is incompatible.  I have been able to compile the tinkerboard kernel with the Asus driver, but it written so terribly it breaks other rk3288 boards that share the kernel.

 

Otherwise everything in 4.4 but Bluetooth works on the mainline kernel build 4.13, to the limits of my testing.  

 

At the moment the kernel seems to be coming up short for your needs.

 

 

 

[Konstantin Gontarenko]

Thanks a lot for your help!

 

In this case, I think I gonna start with Tinker OS, and try to remove or disable the components I don’t need.

 

I need very few parts BTW, besides GPU driver & related stuff (GL ES, WGL, for Armbian also DRM and GBM, for Pi it was DispmanX instead) it’s only C++ runtime and .NET Core 2.

I want to make an embeddable single-app OS for that Tinker Board, with minimalistic touchscreen-based GUI.

[Myy]

@TonyMac32 Well, if by interdependent you mean Mali Utgard kernel driver code depending on Mali Midgard driver code, and vice-versa : No, they're not interdependant.

 

Meanwhile, you might want to test my RockMyy 4.13 kernel and give it a try. At least you'll be able to check if everything is fine with the GPU.

 

Now, concerning the userspace binary drivers, as long as the version of the userspace drivers is lower than the kernel driver version, everything should be fine.

 

I can guarantee that GL ES + DRM drivers, using GBM to generate the framebuffer, work on MiQi hardware (RK3288) using 4.13 kernels, once the drivers integrated.

WGL, I don't know what it is. Wayland GL ? Or Windows GL ?

I haven't tried getting .Net working on ARM systems however.

 

Anyway, I'll try to release a 4.14 with Mali Midgard drivers integrated this week, if everything goes fine.

The 4.14-rc5 kernel seems to boot fine at least. I just need to check if the DRM subsystem has been fixed since the rc1 and, at least, split and rewrite the DTS patches.

[Konstantin Gontarenko]

@Myy

Sorry, WGL was my mistake. I meant EGL, this one https://en.wikipedia.org/wiki/EGL_(API)

 

At least for my use cases (TCP/UDP networking, file system, unmanaged interop with my C++ .so library), .NET Core 2.0 appears to work OK on both Armbian 4.4.88 and TinkerOS.

 

I’ve already got the first TinkerBoard prototype working on TinkerOS.

It doesn’t yet use the second DSI display, but GBM/DRM/EGL/GLES on HDMI, SPI, and TCP/IP (both Ethernet and WiFi) appear to work OK.

 

However, if you’ll fix GPU drivers in Armbian, it’ll be awesome.

And I’ll happily switch to that instead.

I’m working on an embedded firmware. I don’t need desktop, and I love that Armbian has console-only images with minimal pre-installed stuff.

It’s much easier to add a few libraries I need, than to clean up these 900+ packages TinkerOS has pre-installed.

[Myy]

Well, I've reworked most of the Tinkerboard patches. They will need to be tested though. Tomorrow, I'll get a screen to test the HDMI output and the GPU drivers, see if everything goes fine.

 

If everything does go fine, I might push a release.

 

Meanwhile, while hacky, you can boot the zImage and modules available on RockMyy-Build from an ARMbian system. Updates won't be automated tough.

I don't remember how to edit the bootloader configuration though. I'm pretty sure the .txt and .scr files contain comments on what to edit and how to regenerate the boot configuration files.

 

Anyway, I'm currently testing my releases on ARMbian distributions.

 

My latest (4.13 era) tested kernel build is available through : https://github.com/Miouyouyou/RockMyy-Build

Just do a :
 

# git clone --depth 1 https://github.com/Miouyouyou/RockMyy-Build
# cd RockMyy-Build
# cp -r lib/* /lib/
# cp -r usr/* /usr/

Then for the zImage and DTB, you should look at the ARMbian documentation first, then copy the zImage and DTB accordingly.

[TonyMac32]

Rockchip has done something a bit on the odd side, so I haven't gotten the patch up to r13p0 to take for the default kernel yet.  I'll keep working on it, and then I'll turn my attention to the rewrite of the DSI driver for the Raspberry Pi display, as the ASUS driver is...

[Myy]

Okay, turns out that I got no HDMI screen at the moment, so testing the new release on a real screen, and testing the OpenGL ES side is tricky.

 

So, to test at least the DRM and X11 side, I'll need some testers (*stares at @TonyMac32 *).

 

So here's the 4.14-rc4 RockMyy release. It has been put inside a specific branch (with a big typo) until I'm sure that things are working correctly.

The prebuilt release, on RockMyy-Build, should follow soon.

[Myy]

Here's the prebuilt release not tested on a real screen :

 

https://github.com/Miouyouyou/RockMyy-Build/tree/GotNoScreenToTest

[TonyMac32]

4 hours ago, Myy said:

I'll need some testers (*stares at @TonyMac32 *).

 

Well that's uncomfortable...

[Tido]

@Myy, I followed this step-by-step instruction (beside zImage where I deleted the link and placed the file). Unfortunately, no Display output, no network, very hot RK3288 more than the usual 42°.

At the begin the orange light blinked, but then it stopped. I hope the SoC is still okay.

 

Edit: flashed the old image, still runs.

Edited October 23, 2017 by Tido
update on the SoC

[Myy]

Ok, I also got an HDMI screen to test it on and, yeah, the DRM drivers fails extremely fast, printing :

[    1.429322] rockchip-drm display-subsystem: master bind failed: -12
[    1.436413] rockchip-drm: probe of display-subsystem failed with error -12

 

I'll try to see what's wrong with the display subsystem since the update.

 

Note that currently the kernel only boots if you use a serial connection.

[Tido]

4 hours ago, Myy said:

Note that currently the kernel only boots if you use a serial connection.

Sorry it was late and I had no Laptop to attach UART. The fact that the SoC got really warm didn't really increase my curiosity

What blocks the kernel from booting ?

[Myy]

I guess that no DRM + no Serial output == kernel panic somehow. However, that's a wild guess and it will be hard to check that up, since the system boots fine when enabling a serial console.

 

Now, my MiQi reboots, however it's connected with a dreaded microUSB cable. So maybe it reboots because it just cannot go haywire with ~500mA.

 

Anyway, I'll try to remove the patch that defines a new set of VOPB registers, see if that's not the real cause.

[Myy]

Found the real culprit. It was the patch that... enable the VPU services... Some issues with IOMMU definitions made it bork the entire IOMMU group, which included the video output IOMMU. So when the DRM driver tried to use the Video Output, no video output was usable anymore and it bailed out.

 

I'll perform some GLES tests tomorrow and if everything is working, I'll try the rc5 and release a rc5 !

 

 

[Tido]

Btw, if it is possible to have it also at 1280x1024 it is much easier for me to test and attach UART. On the other hand, I don't know how I can help to get this resolution

[Myy]

Well, I pushed an update of the rc4 on the GotNoScreenToTest. Here's the prebuilt one. I should be able to buy a nice HDMI screen in November, and fully resume the MiQi kernel maintainance.

 

Meanwhile, I don't know how to get to this resolultion AND I think that, if you can get the GLES drivers running correctly, you might be able to use something like kmscon in order to get a DRM/KMS/GL accelerated console that you can configure at the resolution you want, instead of relying on some obscure emulated framebuffer configuration.

[Tido]

does this matter for you? https://github.com/rockchip-linux/rk-rootfs-build/issues/25#issuecomment-336333485

[Myy]

That's some interesting tidbits.

 

Last time I tried, the wayland support was good when using weston and was utter garbage when testing with kwin and mutter, which need to be compiled and debugged intensively in order to understand the real issues. However glmark2-es2-drm worked, once I patched it. For example, kwin_wayland --drm can fail if logind and dbus are not started, while providing no useful error messages. Not counting that their graphic card detection system was a bit simplistic, the last time I checked.

[Tido]

UART connected, got no ethernet.  I wonder if it really copied the files:

 

deleted by adding spoiler the content %)  -  anyway it doesn't boot

Edited October 30, 2017 by Tido
adding spoiler