• Announcements

    • 1. Check power supply, check SD card and check other people experiences

      Power supply issues are one of the three biggest issues you'll face when starting with Single Board Computers (SBCs). SD card issues, whether fake or faulty, are another and issues resulting from poor board design is the other common issues you can encounter.   Power supply issues can be tricky. You might have a noisy power supply that works with one board because it has extra filtering, but won't work with another. Or you're using that cheap phone charger because your board has a microUSB connector, and it is either erratic, or doesn't start up, or even becomes the cause of some SD card issues.    Some tips to avoid the most common causes of problems reported:   Don't power via micro USB  - unless you have optimised your setup for low power requirements. Micro USB is great for mobile phones because they are simply charging a battery. It's bad for SBCs. Yes, it does work for a lot of people, but it also causes more problems and headaches over time than it is worth, unless you know exactly what you are doing. If you have a barrel jack power connector on your SBC, use it instead! If there is an option for powering via header connections, use that option!
        Don't use mobile phone chargers. They might be convenient and cheap, but this is because they are meant for charging phones, not powering your SBC which has particular power requirements.
        When you are evaluating a power supply, make sure you run some stress tests on your system to ensure that it will not cause issues down the path.   (Micro) SD card issues can be sneaky. They might appear right at the start causing strange boot and login errors, or they might cause problems over time. It is best to run a test on any new SD card you use, to ensure that it really is what it is, and to ensure that isn't faulty. Armbian provides you a simple way to do this   --   armbianmonitor -c /path/to/device/to/test  
    • 2. Make sure to collect and provide all necessary information

      We can only help if you provide quality information for us to work with. All stable images from the download section are tested, most stable upgrades are tested and we have tens of thousands of users. Even with regular and extensive testings, bugs sometimes do slip through. This is a voluntary support service and is unrelated to board makers, and is not obligated to provide you any answers. Repeated asking the same questions because you're not happy with the answers will result in you being ignored.

      Before you post a question, use the forum search as someone else might have already had the same problem and resolved it. And make sure you've read the Armbian documentation. If you still haven't found an answer, make sure you include the following in your post:   1. Logs when you can boot the board: armbianmonitor -u (paste URL to your forum post)   2. If your board does not boot, provide a log from serial console or at least make a picture, where it stops.   3. Describe the problem the best you can and provide all necessary info that we can reproduce the problem. We are not clairvoyant or mind readers. Please describe your setup as best as possible so we know what your operating environment is like.     We will not help in cases you are not using stable official Armbian builds, you have a problem with 3rd party hardware or reported problem would not be able to reproduced.

GPU driver?
2 2

88 posts in this topic

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

 

 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@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 by Tido
update on the SoC

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 ?

Share this post


Link to post
Share on other sites

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. :mellow:

 

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.

Share this post


Link to post
Share on other sites

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 likes this

Share this post


Link to post
Share on other sites

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 :(

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by Tido
adding spoiler

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

2 2

  • Support the project

    We need your help to stay focused on the project.

    Choose the amount and currency you would like to donate in below.