JMCC

Okay, the script was finished, I was about to publish it... and I got the idea of adding the ARM Compute Library for OpenCL support. Guess whom the suggestion came from: @tkaiser! I think he is starting to love Desktop and GPU stuff... 

Yes, it's almost Rock64 ...  but what are those small diffs,  who wants to be in charge? I can build images (when we merge stable and development branches) and leave it this way: https://www.armbian.com/z28-pro/ as an alternative/for a while.

Since I'm playing more and more with hardware on my own time, I'm going to start the process of uploading my work to github for general consumption.  At the moment I only have DXF board outlines for a few things, I'll follow those with proper KiCAD templates so no one has to wonder where things go if they decide to build.
 
https://github.com/Tonymac32/Board-Geometries
 
 

Update: Kodi+RKMPP+GBM finally working. It's been a tough one: since Kodi 18 is still in alpha state,  I started with 17.6, porting @Kwiboo's Libreelec implementation to .deb packages... only to discover, after I finally got it, that it doesn't work well with the set of kernel/libs we are shipping with Armbian, creating artifacts in videos (it is an early implementation, for older versions of Mali and RKMPP). So I had to start again, with Kodi 18.  Maybe too much time and work, but you know, once you set your mind in making something work, it is hard to stop until you get it.
 
Navigating through GUI and playing 4k videos is smooth like warm butter. But, of course, being in alpha state has quite a few glitches (e.g. crashes frequently when trying to open a file from USB stick). Now, time to package it and release it with the rest of the media stuff.

This should fix this problem.
https://github.com/armbian/config/commit/d7b283e7b8af0c64189f47d0765a790767b44e99

And more fixes were added by Armbian too! Just the mali4xx/mali-midgard conflict was causing a flood of error messages in syslog, until @TonyMac32 found it and fixed it.

And more fixes were added by Armbian too! Just the mali4xx/mali-midgard conflict was causing a flood of error messages in syslog, until @TonyMac32 found it and fixed it.

And more fixes were added by Armbian too! Just the mali4xx/mali-midgard conflict was causing a flood of error messages in syslog, until @TonyMac32 found it and fixed it.

Today's nightly or build from development branch:

- packages cleanup and reorganize: removed Libre writer and Thunderbird from the default desktop install. This brings CLI < 1G and desktop < 2G.
- many bugfixes, enhancements and new software added to armbian-config https://github.com/armbian/config/blob/development/README.md
- fixed FriendlyARM M3 kernel
- wireless for Z28PRO
- removed HDD temperature from MOTD
- many upstream changes for Espressobin kernel(s)
- Odroid DT blob switching was added to the armbian-config. This speeds up boot process and lower consumption on HC1/HC2
- docker building improved
... more changes will be found at the merge
 
Tomorrow website launch ... then:
- merging patches to the stable
- testing
- testing
- fixing
- testing
- testing
- fixing

I get a bunch of approval messages for stuff which is already approved..  From the experience I had before.. those didn't show up that much when they were approved by another mod before (not 100% but more). Seems once more that the UI isn't really friendly for low resolution displays like mine (13XX) but at least coding template works quite well even when not fullscale window.  Seems that there is a 'Add tag' feature which is broken:
Sorry, there is a problem There are no tags available Error code: 2S131/3  
 

I liked yours

Wrote on mobile

Great job! Only there seem to be a few minor bugs. I cannot like any post so far...

I'm working on a script to install all the stuff at once, but I'm not sure when it will be finished. In the meantime,in case anyone wants to try MPV with GBM (dsiplay) and RKMPP (decoding) acceleration, here are the instructions:
After installing the base libs, configs and MPV according to the first post, download this package and install it. From then, you can launch mpv like this, in order to have full acceleration: LD_LIBRARY_PATH=/opt/libmali-gbm:$LD_LIBRARY_PATH mpv --hwdec=rkmpp --vo=gpu --gpu-api=opengl --gpu-context=drm <file> The deb package above will install the GBM version of libmali. I packaged it to install under /opt, so it did not interfere with system libs and we can still have X11 acceleration with the libmali-X11 version.
 
MPV can still be run normally, through X11-EGL, with the known performance limitations (see first post). But if you launch it with the command above, it will completely ignore the X server, and use directly GBM/KMS. That means it will only run in fullscreen, with no mouse support. You can control it with the keyboard and (I suppose) with a remote control or HDMI CEC. MPV on-screen display works normally,  so when you press the appropriate keys info is displayed on the screen (see MPV manpage for a list of keyboard controls). When you press "q" or "Q", it will exit and you will have your X11 session back as you left it.
 
In MPV's implementation of RKMPP, it is bound to GBM display, so the only way to use hardware video decoding is with this launcher. Performance is outstanding: Silk-smooth 4K playback, with minimal CPU usage.

I'm working on a script to install all the stuff at once, but I'm not sure when it will be finished. In the meantime,in case anyone wants to try MPV with GBM (dsiplay) and RKMPP (decoding) acceleration, here are the instructions:
After installing the base libs, configs and MPV according to the first post, download this package and install it. From then, you can launch mpv like this, in order to have full acceleration: LD_LIBRARY_PATH=/opt/libmali-gbm:$LD_LIBRARY_PATH mpv --hwdec=rkmpp --vo=gpu --gpu-api=opengl --gpu-context=drm <file> The deb package above will install the GBM version of libmali. I packaged it to install under /opt, so it did not interfere with system libs and we can still have X11 acceleration with the libmali-X11 version.
 
MPV can still be run normally, through X11-EGL, with the known performance limitations (see first post). But if you launch it with the command above, it will completely ignore the X server, and use directly GBM/KMS. That means it will only run in fullscreen, with no mouse support. You can control it with the keyboard and (I suppose) with a remote control or HDMI CEC. MPV on-screen display works normally,  so when you press the appropriate keys info is displayed on the screen (see MPV manpage for a list of keyboard controls). When you press "q" or "Q", it will exit and you will have your X11 session back as you left it.
 
In MPV's implementation of RKMPP, it is bound to GBM display, so the only way to use hardware video decoding is with this launcher. Performance is outstanding: Silk-smooth 4K playback, with minimal CPU usage.

Now I understand, I thought you wanted to use your Tinker in your car. Cool what you've done, for that I also use a power bank. Here a video of me building a simple robot with an Arduino. Keep up the good work. Sorry for the misunderstanding.
 

Hi all.
I've seen a lot of questions here about what sbc to buy. So why not put a few links here to my videos about SBC's.
The first is my latest video about the desktop experience with the Odroid XU4.
 

This video is about the Rock64(with Armbian)
https://www.youtube.com/watch?v=_oX7TabSROw
This about the Rasp 3b+
https://www.youtube.com/watch?v=7UbapdFXpqE&t=2s
Khadas VIM2 MAX
https://www.youtube.com/watch?v=k3ue7mmpVoU&t=188s
Asus Tinker Board + Odroid C2
https://www.youtube.com/watch?v=PT17hiELHLE

I also can use the views.
Thank you. Have a nice day.

I'm working on a script to install all the stuff at once, but I'm not sure when it will be finished. In the meantime,in case anyone wants to try MPV with GBM (dsiplay) and RKMPP (decoding) acceleration, here are the instructions:
After installing the base libs, configs and MPV according to the first post, download this package and install it. From then, you can launch mpv like this, in order to have full acceleration: LD_LIBRARY_PATH=/opt/libmali-gbm:$LD_LIBRARY_PATH mpv --hwdec=rkmpp --vo=gpu --gpu-api=opengl --gpu-context=drm <file> The deb package above will install the GBM version of libmali. I packaged it to install under /opt, so it did not interfere with system libs and we can still have X11 acceleration with the libmali-X11 version.
 
MPV can still be run normally, through X11-EGL, with the known performance limitations (see first post). But if you launch it with the command above, it will completely ignore the X server, and use directly GBM/KMS. That means it will only run in fullscreen, with no mouse support. You can control it with the keyboard and (I suppose) with a remote control or HDMI CEC. MPV on-screen display works normally,  so when you press the appropriate keys info is displayed on the screen (see MPV manpage for a list of keyboard controls). When you press "q" or "Q", it will exit and you will have your X11 session back as you left it.
 
In MPV's implementation of RKMPP, it is bound to GBM display, so the only way to use hardware video decoding is with this launcher. Performance is outstanding: Silk-smooth 4K playback, with minimal CPU usage.

Good news about the new webpage.
 
I also have some good news about RK3288 media implementation: I finally got rkmpp accelerated mpv to work. It works really well, better than Gstreamer, although only in fullscreen. It's a real "Armbian premiere", no other distro implements it so far, neither ASUS' nor Rockhip's own. In the next days, I'll try to put that with some other new goodies into a script, and keep it available there until it is possible to integrate it in the main build script.

Good news about the new webpage.
 
I also have some good news about RK3288 media implementation: I finally got rkmpp accelerated mpv to work. It works really well, better than Gstreamer, although only in fullscreen. It's a real "Armbian premiere", no other distro implements it so far, neither ASUS' nor Rockhip's own. In the next days, I'll try to put that with some other new goodies into a script, and keep it available there until it is possible to integrate it in the main build script.

Good news about the new webpage.
 
I also have some good news about RK3288 media implementation: I finally got rkmpp accelerated mpv to work. It works really well, better than Gstreamer, although only in fullscreen. It's a real "Armbian premiere", no other distro implements it so far, neither ASUS' nor Rockhip's own. In the next days, I'll try to put that with some other new goodies into a script, and keep it available there until it is possible to integrate it in the main build script.

Good news about the new webpage.
 
I also have some good news about RK3288 media implementation: I finally got rkmpp accelerated mpv to work. It works really well, better than Gstreamer, although only in fullscreen. It's a real "Armbian premiere", no other distro implements it so far, neither ASUS' nor Rockhip's own. In the next days, I'll try to put that with some other new goodies into a script, and keep it available there until it is possible to integrate it in the main build script.

Exactly. It's already problematic - information is scattered around a web page, documentation, Github and forum which is mainly community, self-organized. IMO adding yet another chunk of infrastructure (Wiki) can only make things worse. If we wanted to improve the current situation, we would need to assign a person(s), dedicated editor for keeping documentation well organized.  We can dupe docs as they are now and move them to the web page or to another form or engine ... but its a huge task/challenge.

We are releasing new webpage, which was quite a challenge, in a few weeks and with it, new features and possibilities are being unleashed. Its also a paradigm change - the current website was a single user renderer directly from build script config. With many dirty scripts and plugins. A future website should be a group, community managed with a simple but powerful backend. Most of the work was done to improve that management, previously controlled with configs. I will give rights to anyone who wants to participate as a board(s) maintainer. In a sense to set facts, collect relevant information, decide which download options should be exposed and adjust things, add warnings, etc. This task is not hard work but helps core crew to find some breath. It should be fun and it comes with some responsibility. More when it's out ...
 
Getting access there or rights for editing the documentation is liberal. Like Wiki. Anyone wants to edit textual data, ping me, you get instant commit access.
 
Back to the topic. I think we should keep those how-to's updated but implement features directly into Armbian. When things are matured and when core developers team finds the time. And then, they become irrelevant for the implementation part but still keep the educational role. For that purpose, it should remain in the right place. Subforum "Research and tutorials" is IMO right spot, it's indexed by the main search engine and it will be linked directly from our new web page. They are important.

I'm not so sure about that. I think the best option would be to have a thread where the OP holds the link to the scripts and the instructions, and gets updated with every new release, so users don't need to search through all the thread for the latest version. And having you update the OP with each bug fix or new release would unnecessarily slow down the workflow and make you work. I think it is better if I start a new thread for that, focused only on providing the scripts and commentaries/support about them, and we keep this one for informational/research purposes.
 
(BTW: I don't think it would be a bad idea to create an Armbian community wiki for "unofficial" info like the one provided in this post, apart from the "official" docs).

Seems that hardware accelerated Videodecoding & GPU usage is the new 'hot topic' at the moment. A lot of this stuff is discussed in various topics and threads and subforums here. As nice at it is to bring this topics up, it's hard to follow them across the forum and when those questions come up from users you have to link the to a bunch of topics which they probably don't read cause it's simply to much to read (I now that this is a shitty argument, but reading is boring for most people in those days..  ). 
So why does it make sense to open another thread targeting this topic? This should summarize the things that work, no suggestions what could work, should work, may work and hope that it could work.. That's what all those other threads are for...  And it's focused on Armbian not raspian, not android, not what ever OS you use on your board. Focused on Armbian means also, the board has at least wip status and you can download images from our downloadpage.
Theres a lot of ongoing topics which might find their way into this thread as soon as this stuff is ready (e.g. hardware accelerated video encoding on allwinner in mainline).
 
Basics:
For the most more experienced users it's obvious, video decoding doesn't happen on the GPU which means Mali Support != good videodecoding performance (this might come true when those VPU stuff from mali finds its way into the SoCs we support - that will make things even more confusing ). As a side-note for the KODI users, you need also GPU support to bring it up (OpenGL ES 2.0 as described in their wiki). But videodecoding happens on the VPU not CPU nor GPU (software accelerated videodecoding is possible on the CPU, but the CPUs on ARM boards are mostly not powerful enough for software decoding in high-resolution). The GPU is responsible to keep load from the CPU for desktop usage but not for the video stuff (despite some special hacks).
A second topic which might be important, even when hardware accelerated video decoding is possible from userspace, this doesn't mean every application on your Armbian SBC can benefit from it (e.g. browser etc.).  A bit old, but I think this explains things better than I can do:
https://www.cnx-software.com/2013/12/10/most-embedded-gpus-do-not-support-hardware-video-decoding-acceleration-the-vpu-does/
 
Allwinner:
Currently, VPU support is only possible with the Legacy Kernel (3.4.113) and very limited by using desktop builds of Armbian. Behind the scenes Cedrus is responsible for the usage of the VPU. Under Armbian hardware accelerated videodecoding is possible by use of the provided MPV player. To Summarize it:
Legacy & Desktop images only MPV player uses it H3 & A20 SoC As far as I know, nobody tried the new drives for mainline yet on armbian. 
 
Rockchip:
RK provide a lot of stuff to make HW acc. video decoding possible with their 4.4.x legacy kernel. The efforts taken to bring this to armbian can be followed here: https://forum.armbian.com/topic/6506-tutorial-3d-video-acceleration-and-opencl-in-rk3288-boards-with-new-44-default-kernel/
 
At the moment hardware accelerated video decoding is possible with RK3288 SoCs. Supported is
Hardware acc. video decoding by using gstreamer (up to 4k@30fps HEVC) H.264 HW acc. videodecoding in chromium browser (no VP9) by using MPV video decoding happens on CPU (up to 1080p@30fps HVEC by 80-90% CPU load) and accelerated display layer through EGL. That makes a huge difference in playback smoothness over the stock unaccelerated MPV. openCL (1.1) and openGL ES (3.2) is supported Chromium supports webGL HW encoding is also possible, in addition to Gstreamer, through a custom FFMPEG (included in the package from the referenced tutorial, although undocumented) All this stuff is at the moment not provided by a stock Armbian, but @JMCC wrote an installation script for Ubuntu Xenial:
 
 
Exynos 5422
Exynos 5422 which can be found in Odroid XU4 (HC1/HC2 too but there's no HDMI output) has a less powerful VPU than the RK3288 but hardware accelerated video decoding and mali support is possible as discussed here.
OpenCL (1.1) and openGL ES (3.1),  with excellent performance thanks to the hexa-core Mali T628. MPV, by default it works like in RK3288: SW decoding and accelerated EGL display. But you can add the "-hwdec" option to get HW decoding through the v4l interface (H.264 only: tested up to 1080p@30 to work well, 1080p@60 so-so). Chromium supports WebGL and accelerated H.264 video decoding. 
Emby Server
All this stuff is at the moment not provided by a stock Armbian, but @JMCC wrote an installation script:
 
This thread is supposed to be updated over time as soon as things are implemented in Armbian or proper tutorials are available to do it on your own. IMO development discussion for support shouldn't happen here (this should happen on threads dedicated to a specific board/kernel) and as soon as it is confirmed to work write it here and I'll update this post to get the latest news on the starting post which makes it easy for the 'lazy' ones to get an overview of the current status for a specific board/soc/kernel. I might miss part of the things which are currently running and I'll happily update it when someone points me to those threads or writes a short summarization (preferred ) below this post. I suspect that hardware accelerated video encoding will also come up soon, so this might be also added in this thread as soon as proved results are available.
 
Side-note: I'm not sure if we should place this thread here (General chit chat) or in the Research guides & tutorials section. Cause this is more a overview and not a guide it's here, but might change in the future (depends on other opinions). @JMCC I have in mind that such a summarization was on your 'to-do' list, feel free to correct & add things I might missed here. 
 
Side-note II: The thread only represents work on top of 'stock armbian' @balbes150 work which is done for TV boxes is highly underrepresented here.  Feel free to add your opinions and additions directly into my post (as mod you should be able to do it directly). 
 

TL;DR: the following is a simple summary of the issue:
 
Amlogic SoCs contain an own embedded microcontroller (Cortex-M3) used for controlling power and clocks A proprietary and closed source firmware is loaded on the M3 at boot. This stuff is contained in the bl30.bin blob we have to include This firmware controls the real clockspeeds, ignores what the cpufreq framework running in the Linux kernel wants and even reports back bogus clockspeeds (the kernel wants to set 1512 MHz, the M3 ignores this and sets 1416 MHz instead but the code returns faked 1512 MHz) Various tests showed that this is not related to thermal protection but just to $something we currently don't understand and out of our control Hardkernel are the only ones who managed to get a bl30.bin blob from Amlogic for their ODROID-C2 that does not cheat on us but honours the cpufreq framework, sets the wanted clockspeeds and also returns real and not faked cpufreq values. On all other Amlogic SBC situation is different  
 
 
Talking about 'not entirely honest' when it's about bold lies is funny
 
It's some proprietary crap that controls DVFS on Amlogic SoCs (a bl30.bin BLOB loading some firmware on the embedded Cortex-M3 which controls DVFS/cpufreq on its own) and Hardkernel is the only vendor that got this BLOB from Amlogic in a way where the installation does not cheat on you. In case the BLOB does also DRAM initialization (most likely) it should be hard to exchange it between boards.
 
https://forum.armbian.com/topic/2138-armbian-for-amlogic-s912/?do=findComment&comment=43338 (S912 and S905X are both known to cheat on the Linux kernel. The cpufreq values are all faked. Most probably this does also apply to all S905 devices except ODROID-C2 since Hardkernel managed to get a fixed BLOB from Amlogic)