JMCC

It should be plug and play. It works on ASUS images (https://tinkerboarding.co.uk/wiki/index.php?title=CSI-camera). But there is some bug that is preventing it from working in Armbian. It might have gotten fixed already, you can try it and see if it works.
(What I mean is that there has been a patchset applied recently in the development default image, that may have fixed the bug. But I have been the whole day trying to find my Rpi camera, without success, so I couldn't test it).

It would, in theory.  This is actually a situation where the Hardkernel code base is significantly divergent from the others, due to their hard work early on to support the hardware.  It means things are done differently, not necessarily incompatibly.  Now, quite some time after Hardkernel, we have other boards, and Amlogic/others are pushing to get proper mainline support, so I'm sticking with that.
 
As for compatibility of VPU's:
https://elixir.bootlin.com/linux/v4.16.2/source/Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt

I believe there is a simple command line player (c2play) that makes use of the VPU (similar to omxplayer on RPIs). Of course this does not integrate with FFmpeg/gstreamer and other applications that may want to use HW video decoding.
These libraries can be used to integrate with different apps like Kodi.

Hi guys,
 
after some interesting weeks, I could successfully install eight Odroid C2 together with dedicated FPGA hardware now, and prepare them now for deep sea operation.
 
Just wanted to express a big "THANK YOU" to all here in the forum which were involved in helping me to get the beast working.
 
The boards operate now with patches inside Uboot (serial console 9600 8N1) and several small patches inside the kernel (device tree, PWM, ADCs, 1Wire), and a patch inside the rt8152 driver to switch off the LEDs in the USB ethernet dongle (PMTs don't like such bright light usually). 128GB eMMCs are working fine, thanks to the speed patch
 
The Armbian image does a great job, it's a pleasure to work with. At the moment I run it headless over some DSL connection, with a SSH tunnel and TigerVNC to remotely operate it and test under hard conditions
 
Again, thanks to all persons involved.
 
BTW, I'm open for ideas on how to save power on C2 during operation, as well as how to read CPU temperature remotely - we have 22W max power dissipation inside the Titanium shell... every Watt counts.
 
BTW2, how can I take the kernel image out of updates? I want to use apt-get for normal packages, but hands off the kernel
 
So far, Michael

S905's use SMP, but S912 uses HMP (big.LITTLE architecture). You can google for those terms, and you'll find good explanations about their meaning. That is valid for Armbian as well as any other distro supporting those SoC's.
 
That means that it is capable to display 4K resolution (that is, 3,840 pixels wide and 2,160 pixels high), at a framerate of 60 or 30 frames per second, and decode video with those specifications. It has nothing to do with the number of CPU cores being used by the system, but with the video decoding capabilites of another component of the SoC, called VPU (Video Processing Unit). Again, google can give you good definitions about these.
 
I have never tried that. You can try to configure it, and let us know about the results.

No problem! Rule #1: keep Youtubers happy 

https://github.com/armbian/config/commit/2992430d263cad9ca18fb773127fb90d628e5ab8#diff-f31297ad208d45c13b6d3d24c66823cdR35

Ubuntu Bionic can be build ... but you need to kill man-db process which hangs during debootsrap process. I made a test image for Odroid XU4 but the network was not configured and probably other things need to be fixed. Addin Bionic remains a low priority and hidden under the expert switch.
 
armbian-config, network management needs further testing and fixing.
 
power management on wireless devices was enabled on some during my last test. IIRC brcmfmac / mainline / h3 

Do you mean at full CPU usage? No wonder. Just consider that XU4 peaks above 3A, also with nothing connected to it. You need a minimum of a 5V 2.5A PSU to work with the Tinkerboard.
 
Powering through GPIO gives you the best power throughput, but if you don't use a filtered PSU or make a tailored circuit for that yourself, you risk to burn your board. I personally use a 5v 2.5A PSU connected through MicroUSB, and never get a crash as long as I don't connect to the USB ports anything more than the keyboard dongle (I tested dual CPU+GPU mining for several days). The key is to get a good MicroUSB cable, with a plug that makes as much contact as possible. If you're only going to do benchmarks, that should be enough.
 
You can test the Armbian multimedia package for the Tinkerboard here:
It will make streaming videos, webGL, and more stuff, work, and will give you a real idea of the Tinkerboard's potential.
 
I'll try to make a Blender BMW render (that is your test, right?), and let you know about my results.
 

Hey, don't worry, in addition to releasing my weekly allowance of testosterone in this discussion, I am meanwhile making tests on the Tinker. So far, render is going well, I'll get to you with the results.

Hello all.
I've made a video about the Rock64. I've tried different distro's, but Armbian was the best for me.
The only problems I've found was that Synaptic Package Manager didn't work. It crashes when I press the search button. And sometimes surfing was extremely slow. Otherwise it did fix all the problems I've had with the other distro's I've tried.
Thank you for all the great work.

Now I've started my research with the Orange Pi +2, and again Armbian is the best choice.
Greetings, NicoD

Here is my video.

 

You're right. They are still using an old set of libs, with libmali r0p9 (Rockchip is using r0p14 now). I was hoping they changed it in their last release. I tested it, and saw lots of artifacts in webgl that don't happen when you use the more recent versions of the libs.
 
In Armbian, we are implementing the most updated versions, and everything has worked so far very well, including drm, without that lib. However I have repackaged it from TinkerOS, and I'm attaching the deb to this post. But you must realize that if you install it in Armbian Stretch, you will not have all the other libraries necessary to make GPU acceleration work.
 
My recommendation would be that you start from an Armbian Xenial default image, if your project can work on Xenial, and then follow the steps in the following guide (only the parts you need): https://forum.armbian.com/topic/6506-tutorial-3d-video-acceleration-and-opencl-in-rk3288-boards-with-new-44-default-kernel/
 
Then try to make your project work without libdrm-rockchip. If it doesn't , then install the deb and try.  I'm very interested in knowing the results, so I would appreciate if you shared them. That would help to the development, and we may include that lib in case it turns out to be useful.
 
Thanks. 
 
libdrm-rockchip1_2.4.74-2_armhf.deb

You're right. They are still using an old set of libs, with libmali r0p9 (Rockchip is using r0p14 now). I was hoping they changed it in their last release. I tested it, and saw lots of artifacts in webgl that don't happen when you use the more recent versions of the libs.
 
In Armbian, we are implementing the most updated versions, and everything has worked so far very well, including drm, without that lib. However I have repackaged it from TinkerOS, and I'm attaching the deb to this post. But you must realize that if you install it in Armbian Stretch, you will not have all the other libraries necessary to make GPU acceleration work.
 
My recommendation would be that you start from an Armbian Xenial default image, if your project can work on Xenial, and then follow the steps in the following guide (only the parts you need): https://forum.armbian.com/topic/6506-tutorial-3d-video-acceleration-and-opencl-in-rk3288-boards-with-new-44-default-kernel/
 
Then try to make your project work without libdrm-rockchip. If it doesn't , then install the deb and try.  I'm very interested in knowing the results, so I would appreciate if you shared them. That would help to the development, and we may include that lib in case it turns out to be useful.
 
Thanks. 
 
libdrm-rockchip1_2.4.74-2_armhf.deb

Okay, I knew your board was missing something, but I couldn't point what it was. I think I finally got it:
 

 
That makes it perfect! Don't you think so?

Okay, I knew your board was missing something, but I couldn't point what it was. I think I finally got it:
 

 
That makes it perfect! Don't you think so?

Okay, I knew your board was missing something, but I couldn't point what it was. I think I finally got it:
 

 
That makes it perfect! Don't you think so?

I made an updated build, with the current master branch from the Rockchip repo.  I noticed we were formerly using the 1.19 "release" version, which did not incorporate many fixes and performance improvements. I was also able to compile against the standard Xenial 1.18 X server, so no need to use the backport anymore.
 
Installation steps (provided that you already configured your system according to the first post of this thread):
Restore the regular 1.18 X server packages: sudo aptitude install xserver-xorg-core xserver-xorg xserver-xorg-input-all xserver-xorg-input-evdev xserver-xorg-input-synaptics xserver-xorg-input-wacom xserver-xorg-video-fbdev Aptitude will ask you if you want to remove the backported ("-hwe-") packages, so answer Yes.
Download the 7z archive: https://mega.nz/#!oywWCaDA!wDtzXQuohJeVDuePCxHej4xkqDfUmhaPj6XNU7ZXyCk
Unzip it
cd xserver-1.18-ubuntu
sudo dpkg -i *.deb
sudo apt -f install
I see a big performance improvement, and also bug fixes. Windows dragging is snappy, with or without compositing. No more icons disappearing with compositor enabled.
 
However, I am afraid that the more recent version of the X server may have caused the problem with the DSI screen that @TonyMac32 described in another post. Can you test and see if you experience the same problem as with TinkerOS? (EDIT: Nope, the problem was a download link in the product page leading to a much older version instead of the last release: https://forum.armbian.com/topic/6870-rfc-tinker-board-uart-number/?do=findComment&comment=52161) So it seems safe to use this version.
 

My pleasure. I entered the world of SBC's four months ago, when I got a Tinkerboard for a multimedia-related project (a programmable video and announcements player for a TV in my church).  I only knew about the Raspberry Pi, but I did some research and learnt it was not powerful enough for 1080p video.  So I found myself in front of a myriad of different Chinese fruitty-pies, another brand called "Odroid" which I assumed would only run Android (), and a more powerful Raspberry Pi clone from ASUS.  I said "what the heck, if it's from ASUS it must be good, and it will also fit in the RPi case I already ordered". So I went for it (it was also on a special offer before Christmas, 55€ with free shipping). 
 
I had not used a Linux desktop in quite a few years, but turned out that X had not changed much since (which proves that it is obsolete ), so it just took me a few nights to figure out how to squeeze the most out of that little piece of hardware. But, still, all the Tinkerboard OS's looked to me more like compromise solutions to make the board work, rather than real OS's I could trust. Until I came across Armbian, that appeared to me more like the real Linux distros I was used to in the past. I saw committed people who really knew what they were doing, and it gave me a feeling of reliability.
 
Thanks to Armbian and other projects like DietPi, I learnt about other possibilities for SBC's, such as home NAS, Wifi hotspot or VPN tunnel. That encouraged me to get an OPi+ 2e first, and an Odroid HC1 later: Armbian reviews and comments taught me that those were good choices.
 
So I wanted to share the little I had learnt about multimedia in ARM SoCs, and @TonyMac32's announcement that he was switching to the Rockchip kernel seemed like a good opportunity to do it.  And, most important, what really motivates me is that I have found there is a lot of good people in this community, and I really enjoy participating in it! So, as long as I am able to contribute in any way, I'll be most glad to do it! 

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:
Download the 7z archive: https://mega.nz/#!oywWCaDA!wDtzXQuohJeVDuePCxHej4xkqDfUmhaPj6XNU7ZXyCk Unzip it cd xserver-1.18-ubuntu sudo dpkg -i *.deb 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.

I made an updated build, with the current master branch from the Rockchip repo.  I noticed we were formerly using the 1.19 "release" version, which did not incorporate many fixes and performance improvements. I was also able to compile against the standard Xenial 1.18 X server, so no need to use the backport anymore.
 
Installation steps (provided that you already configured your system according to the first post of this thread):
Restore the regular 1.18 X server packages: sudo aptitude install xserver-xorg-core xserver-xorg xserver-xorg-input-all xserver-xorg-input-evdev xserver-xorg-input-synaptics xserver-xorg-input-wacom xserver-xorg-video-fbdev Aptitude will ask you if you want to remove the backported ("-hwe-") packages, so answer Yes.
Download the 7z archive: https://mega.nz/#!oywWCaDA!wDtzXQuohJeVDuePCxHej4xkqDfUmhaPj6XNU7ZXyCk
Unzip it
cd xserver-1.18-ubuntu
sudo dpkg -i *.deb
sudo apt -f install
I see a big performance improvement, and also bug fixes. Windows dragging is snappy, with or without compositing. No more icons disappearing with compositor enabled.
 
However, I am afraid that the more recent version of the X server may have caused the problem with the DSI screen that @TonyMac32 described in another post. Can you test and see if you experience the same problem as with TinkerOS? (EDIT: Nope, the problem was a download link in the product page leading to a much older version instead of the last release: https://forum.armbian.com/topic/6870-rfc-tinker-board-uart-number/?do=findComment&comment=52161) So it seems safe to use this version.
 

The problem I noticed when enabling the compositor was desktop wallpaper and icons disappearing. Can you confirm that is not happening?

I successfully completed all step of the installation, with all tests passing.  I had massive slowdown when moving windows, and so I re-enabled the compositor.  This fixed the problem and has not affected the GPU drivers.

Good catch.  It could be because only Uart1 has cts/rts from what I can tell, and that might be needed somewhere besides a terminal...
 
Hey, that was me! 

Ok, so this mpv will play by default with software decoding and GLES accelerated display output.  You can also use hardware decoding through the v4l interface with the "-hwdec" option, although the performance will not really improve, only the CPU usage will be lower.
 
Download the package: https://mega.nz/#!AqhhAYQQ!W75RW58Pf3TQtN8koxMJ2YlWts9XvBhXiUbDDNrQPmE sudo dpkg -i mpv_2018.03.25_xu4_armhf.deb sudo apt -f install

Ok, so this mpv will play by default with software decoding and GLES accelerated display output.  You can also use hardware decoding through the v4l interface with the "-hwdec" option, although the performance will not really improve, only the CPU usage will be lower.
 
Download the package: https://mega.nz/#!AqhhAYQQ!W75RW58Pf3TQtN8koxMJ2YlWts9XvBhXiUbDDNrQPmE sudo dpkg -i mpv_2018.03.25_xu4_armhf.deb sudo apt -f install

I got a workaround by disabling the composite [EDIT: and Render] extension. Only that it has some side effects: everything works very well and performance is excellent, but in some places where Xfce tries to make transparency, you see a black background instead.
 
I modified the xorg config file in the script two posts above. You can either re-run the modified script, or add the following lines to /etc/X11/xorg.conf.d/01-armbian-defaults.conf
Section "Extensions" Option "Composite" "Disable" Option "RENDER" "Disable" EndSection In my opinion, everything works very well, and these solid black backgrounds in some places are a small price to pay for having the ability to use GLES, WebGL, and accelerated video display. And maybe in the future we can find a way to work those around too.
 
About accelerated video, I'll post a tweaked mpv package when it is ready. [EDIT: see the following post]