JMCC

Yes, of course, I forgot the mali permissions issue. This code should fix it: echo 'KERNEL=="mali0", MODE="0666", GROUP="video"' | sudo tee /etc/udev/rules.d/50-mali.rules sudo usermod -aG video $(getent passwd 1000 | cut -f1 -d:) Then you must reboot, and you can test: sudo apt install glmark2-es2 glmark2-es2

Wow. Do you also have wifi, bluetooth and sound on that kernel?

Great! Let's see if you don't get a bootloop with the commands listed in

I installed the lib in my system, and OpenCL works. What strikes me is that you experienced a bootloop: I could understand X server not starting, but system rebooting ?? I noticed you must create a user called "odroid" before installing the package, for it to configure properly. So maybe it has something to do with the library not being configured and therefore symlinks not created. In short, you can try to copy-paste this into a terminal: sudo adduser --disabled-login odroid wget http://deb.odroid.in/5422-s/pool/main/m/mali-x11/mali-x11_20170718-r17p0-20503ff-3_armhf.deb sudo dpkg -i mali-x11_20170718-r17p0-20503ff-3_armhf.deb wget http://deb.odroid.in/5422-s/pool/main/x/xf86-video-armsoc/xserver-xorg-video-armsoc-exynos_1.4.1-0ubuntu4_armhf.deb sudo dpkg -i xserver-xorg-video-armsoc-exynos_1.4.1-0ubuntu4_armhf.deb sudo rm /etc/X11/xorg.conf.d/* echo 'Section "Device" Identifier "Mali-Fbdev" Driver "armsoc" Option "fbdev" "/dev/fb0" Option "Debug" "false" Option "DPMS" "false" Option "NoFlip" "true" EndSection Section "ServerLayout" Identifier "Default Layout" Option "BlankTime" "0" Option "StandbyTime" "0" Option "SuspendTime" "0" Option "OffTime" "0" EndSection Section "DRI" Mode 0666 EndSection ' | sudo tee /etc/X11/xorg.conf.d/01-armbian-defaults.conf And then, restart X and see what happens.

Yeah, you've done a great job to get a stable system, with all those filesystem and kernel tweaks that no other distro has. That's why there's so many of us who feel drawn to use Armbian, even though it would be easier to use the vendor-provided distro for graphic stuff. But, you see, we made everything work in RK3288 SoC, I think it is worth giving a try with the Exynos 5422 too. Let me make some tests in my own HC1 and see. I cannot test EGL, but I can test OpenCL. And normally, if the latter works, the former will work too.

Can you please post the output of "sudo armbianmonitor -u", and also "cat /var/log/Xorg.0.log" ?

It is a Youtube-specific plugin. It will do nothing outside of Youtube. AFAIK, the RK3288's VPU cannot decode VP9, so it will be decoded through software. VP8 seems to be supported, though I have not tested it. More info: http://rockchip.wikidot.com/rk3288

Just got my HC1. Any news about the update to kernel 4.14?

I think I found a bug: devfreq does not work for the gpu. The devfreq interface is located at /sys/devices/platform/ffa30000.gpu/devfreq/ffa30000.gpu root@tinkerboard:/sys/devices/platform/ffa30000.gpu/devfreq/ffa30000.gpu# ls available_frequencies cur_freq governor max_freq polling_interval subsystem trans_stat available_governors device load min_freq power target_freq uevent root@tinkerboard:/sys/devices/platform/ffa30000.gpu/devfreq/ffa30000.gpu# cat available_governors userspace root@tinkerboard:/sys/devices/platform/ffa30000.gpu/devfreq/ffa30000.gpu# cat available_frequencies 100000000 200000000 300000000 400000000 600000000 root@tinkerboard:/sys/devices/platform/ffa30000.gpu/devfreq/ffa30000.gpu# cat cur_freq 384000000 root@tinkerboard:/sys/devices/platform/ffa30000.gpu/devfreq/ffa30000.gpu# echo 400000000 > min_freq root@tinkerboard:/sys/devices/platform/ffa30000.gpu/devfreq/ffa30000.gpu# cat cur_freq 384000000 root@tinkerboard:/sys/devices/platform/ffa30000.gpu/devfreq/ffa30000.gpu# Expected behavior: You should have four available governors: userspace, powersave, performance and simple_ondemand You should be able to set the governor by something like "echo performance > governor", and it should regulate frequency accordingly available_frequencies lists the possible GPU frequencies cur_freq shows the current frequency, which should be one number from the list in available_frequencies You should be able to set min_freq and max_freq, and the system should honor it Current behavior: Only userspace governor is available Frequency is fixed at 384000000, no matter what That number is not in the list of available frequencies min and max freq are not honored Devfreq interface and governors are working properly in the Asus image, and it also works in Rockchip-linux image built on 2018/01/16. By default, they use the simple_ondemand governor. It allows you to save ~0.4W on idle, and gain about 60% performance under load, with regards to the current Armbian fixed-frequency policy.

You must install the "default" image, not "mainline". Sound is not working in mainline. This is the right one: https://dl.armbian.com/tinkerboard/Ubuntu_xenial_default_desktop.7z.torrent

I can't answer, since I don't have a 4k display to test with. You can add the mode to the xorg.conf file, and let us know what happens.

You can also add OpenCL to the list. I added it to the tutorial.

Updated to include also Open CL testing with a GPU miner. No, guys, you're not going to get rich with your little Tinker, but it is funny to see her join all those mining rigs and ASICs at the mining pools.

I have a HC1 (a kind of a headless XU4), so I can't test WebGL. It should work if you install these two packages: http://deb.odroid.in/5422-s/pool/main/m/mali-x11/mali-x11_20170718-r17p0-20503ff-3_armhf.deb http://deb.odroid.in/5422-s/pool/main/x/xf86-video-armsoc/xserver-xorg-video-armsoc-exynos_1.4.1-0ubuntu4_armhf.deb And then replace /etc/X11/xorg.conf.d/(whatever-is-the-name-of-the-conf-file) with the following: Section "Device" Identifier "Mali FBDEV" Driver "armsoc" Option "fbdev" "/dev/fb0" Option "Fimg2DExa" "false" Option "DRI2" "true" Option "DRI2_PAGE_FLIP" "false" Option "DRI2_WAIT_VSYNC" "true" # Option "Fimg2DExaSolid" "false" # Option "Fimg2DExaCopy" "false" # Option "Fimg2DExaComposite" "false" Option "SWcursorLCD" "false" EndSection Section "Screen" Identifier "DefaultScreen" Device "Mali FBDEV" DefaultDepth 24 EndSection Maybe you can play with the commented-out lines, and see how it affects performance. Let us know whether it works.

@pipozovato You downloaded the wrong image. It should be https://dl.armbian.com/tinkerboard/Ubuntu_xenial_default_desktop.7z, with 4.4 kernel. And, until the new image is released, you must also install the testing packages with the updated 4.4 kernel, from the post referenced at the beginning. @pro777 When the new image is released, permissions will be set properly by default. Until then, you can put in /etc/rc.local these three lines: sudo chmod 666 /dev/hevc-service sudo chmod 666 /dev/mali0 sudo chmod 666 /dev/media* You guys must remember that all these features are still under testing. The stable image won't need all the fixes.

As of now, Debian Stretch image is still under development (though very functional already). So I would recommend you to build Ubuntu. Maybe when Stretch image is released officially, it will be better to use it for the Tinkerboard, since all the Rockchip-linux packages are built against Stretch. But for now, I recommend Ubuntu.

@jkljkl1197 Sorry, if you told us which board you have, I can't find the post where you said it. I assume it is a Tinker Board. Well, in that case, I think you have two options: Armbian and the official TinkerOS Debian. About Armbian, if you are not able to build an image yourself with the new kernel, you can either download the old image and then install the packages referenced in the OP of this thread (including the kernel packages, from another thread linked also there), or you can also wait until the new image is released. About TinkerOS, it will give you some of those things already configured without you needing to do so. But Armbian is more stable, has slightly better performance, and several tweaks and scripts that you won't find in TinkerOS. I recommend you to try both, and see which one suits your needs better. This is what the world of FOSS and SBC's is about: experimenting, trying, learning, tinkering... ;-)

@TonyMac32You probably have already checked Rockchip's own BT service, but just in case: https://github.com/rockchip-linux/rk-rootfs-build/blob/master/overlay/lib/systemd/system/example/bt_uart.service

Hello Pietro, What is happening to you is normal. The tutorial does not tell you to reboot at that time, because if you do so, X will not start. That is because the old 1.8 Xserver bundled with ubuntu will crash while trying to start glamor. You only need to do the following step (number 3.), and everything will work fine.

Glad it worked. Yes, if you disable vsync you can get over 200 fps. But it is useless since your screen is still refreshing at 60hz, and you lose all that smoothness in video playing. Probably needs some specific entries in Xorg config file. Unfortunately, I don't have the touchscreen to test. Sure. Maybe adding a menu item to armbian-config in RK3288 boards. Also, I think I know which changes would need to be made in order to make it work in RK3328 and RK3399. But I don't have any board with thise SoC's. I am not planning to buy any RK3328; maybe a RK3399, when they release one for the average user who doesn't need to attach three LVDS at a time.

Mmmm, I just copied and pasted all the code into a blank file, and works for me. I'm doing it directly in the Tinkerboard, and using Vim. Maybe your text editor is messing line breaks or quotes, particularly if you are SSH'ing from Windows.

As you already discovered, there is a tutorial that will help you set up acceleration in the Tinkerboard: Take into account that you will need to install the testing new kernel packages, from the thread referenced at the beginning of the tutorial. Hopefully, in a few days a new Armbian image will be released, including the new kernel.

Yes, sorry, I corrected the link in the post. Should be this: https://mega.nz/#!UuRThALT!FcgA72sKKk179giSYzPooJQy6SbDYFpy4NJ8Gkp95Xc

I just posted the tutorial:

I just posted a tutorial on this topic: