NicoD

Well, yes, I didn't mention that you need to configure the system with the script first. I'll PM you a link of the preliminary version, though it is almost finished

well we have what you would call a militia parliament.. It's not always that they understand stuff better.. But hey.. data is the new oil.. we might need a few exxon valdez'es or deep water horizons to figure out how this new oil is handled safely..
some other bad jokes..
we don't understand it fully yet but let's build up a cartel (that's some years ago for the real oil)... wherever the pipeline goes.. someone is upset once it's in the environment it needs years until it disappears.. seems that this 'dataset' also contains information of their kids (account-names etc.), maybe this helps them a bit to understand the issue better...
 

 
feeling like grandpa simpson

@NicoD Well, in order to compile ffmpeg with rkmpp support, you need to pass these three configure flags (or their cmake equivalent, if that's what you are using): 
--enable-libdrm --enable-version3 --enable-rkmpp  
Then, make sure your user has access to DRM. It should be enabled out-of-the-box for the default user in Armbian, if you build a current NanoPC-T4 image with the script (not in the one for download). Or you can just try to launch ffplay with sudo.
 
For last, when you launch it try changing the "h264" decoder to the "h264_rkmpp" decoder. Here is a link to a thread in the ffmpeg lists from someone who tried to do something similar: http://ffmpeg.org/pipermail/libav-user/2018-April/011081.html
 
Good luck with that 

AFAIK, ffmpeg can only display rkmpp decoded video through drmprime/gbm. Meaning that it cannot show it windowed in kdenlive.
 
I see more chances of using mpp accelerated decoding in a gstreamer-based video editor, such as pitivi

This thread summarizes the efforts done to get armbian support for the new RockPi 4b.
 

 
Boardspecs (from: https://wiki.radxa.com/Rockpi4/getting_started):
 
Rockchip RK3399 64bit dual channel LPDDR4@3200Mb/s, 1GB/2GB/4GB optioal storage:
eMMC module (optional) uSD card M.2 SSD (M.2 connector supports up to 2T M2 NVME SSD) display:
HDMI 2.0 up to 4k@60 MIPI DSI 2 lanes via FPC connector other features:
3.5mm jack with mic MIPI CSI 2 lanes via FPC connector, support up to 800 MP camera. 802.11 ac wifi Bluetooth 5.0 USB 3.0 OTG X1, hardware switch for host/device switch, upper one USB 3.0 HOST X1, dedicated USB 3.0 channel, lower one USB 2.0 HOST X2 GbE LAN with PoE support (hat required!) 40-pin expansion header USB PD, support USB Type C PD 2.0, 9V/2A, 12V/2A, 15V/2A, 20V/2A. (supports Qualcomm® Quick Charge as well) 85mm x 54mm  
Current support status (and some background):
first dev samples arrived and @martinayotte and @TonyMac32 started to integrate it into the rockchip64 boardfamily. Radxa offers a patched kernel and u-boot based on rockchips out of tree 4.4 kernel and 2017.09 u-boot. The our rockchip64 family is based on @ayufan s u-boot (which is a fork of rockchips) but a simple patch in of raxdas defconfig and the needed devicetree files don't work (it breaks on several parts during compilation related to USB and other stuff I'm still not 100% sure why.. ). So we went for a defconfig and DT file based on the one of the RockPro64 (cause even without patching, those images booted - a lot of stuff didn't work but at least it allowed us to start getting things working).
People related to Radxa forked the buildscript (https://github.com/brian541/build) and I assume that's why they can provide some 'preview' Armbian images on their site. Problem here is that they defined their kernel and their u-boot in a new linuxfamily (https://github.com/brian541/build/blob/master/config/sources/rk3399rockpi4b.conf) we simply can't have another RK3399 boardfamily (we have two, they share the kernels but not u-boot cause some boards have issues with upstream u-boot - we don't want to manage another u-boot fork nor another 4.4 kernel, it's ayufans or upstream).
That's why things may need a bit of time until they work properly on the RockPi.
 
Currently working (rockchip64-dev branch):
GbE
USB
Wifi (but laggy)
SD-Card (seems to be fine now)
HDMI (not committed yet)
 
Currently broken or with issues:
SD-Card has random hangs (probably speed issues)
 
everything else must be expected as broken at the moment. As far as I know nobody is currently working on 4.4 images and it might need some time to bring things up there. So RockPi 4b images must be considered as early wip at the moment and have to be built on your own cause we don't provide images yet.
 
side-note: first patches are also upstream to support the board in mainline kernel (not done by us https://patchwork.kernel.org/patch/10745929/)
 
@martinayotte & @TonyMac32 can you please correct in case I screwed something up in my summary?
 
@Igor or @zador.blood.stained if you think the thread fits better into the 'board bring up' subforum just move it.

That`s a joke. Learn to laugh
Don`t joke about C, that`s serious stuff. (again...)
Greetings

I am there Friday evening - Monday morning. 
 

See you there.  

I plan to attend FOSDEM 2019, anyone else too?

I'm afraid not.  A few have some sort of "marker" to show what they are (a resistor somewhere tied to an ADC, and efuse value, etc), but they are as non-standard as the SoC's themselves.
 
 
A lot of people feel this way, but it would require an agreement on a standard.  SPI flash or an eeprom drive cost some vendors will never sign up for, and create some problems when needing to upgrade the information stored on them (device tree bugs, bootloader fixes, etc)
 
And projects like this one wouldn't have much to do either, the "big guys" would take over and you'd have the same basic options as PC, with others like us and Arch being "alternatives".  That said, there is a versatility of application to SBC's that does not exist with PC.  Few strap a PC to a bench with bare I/O monitoring things, that died with the parallel port.  So I think there will always be room.
 
An FPGA that runs a RISC-V  powerful enough for linux isn't in my budget just yet, but it does look interesting.

That would be ideal, but some of these boards have... peculiarities that cause source code issues (Tinker has some gymnastics around reboot that require some ugly hacking of the sd/emmc driver that can break other RK3288 devices) or userspace issues (manually toggling IO's to reset BT adapters).  In general, though, you'll find that most of our images are the same for the same SoC, just with DTB/boot script differences for each particular layout, it's why on any board bringup you see us just manually swapping DTB's to see if it will work out of the box.

In Libreelec (KODI-18) on Khadas EDGE (RK3399) play all video works. Including HW for 4K and sound.
 
 
p.s. pls test  https://forum.armbian.com/topic/8898-ramblings-and-progress-with-the-rk3399/?do=findComment&comment=68690 
 

You read my mind! I'm brushing up the last stages for the RK3328/3399 multimedia support, and after that I was going to propose to add it to the build script.
 
So my plan is to release the media scripts for those two SoC's in a few days, and after having some feedback from the community integrate the main features into the main build.
 
Edit: I mean including all three RK SoC's: 3288, 3399 and 3328.

You've got an undervoltage before it goes into the board.
I wonder what your USB voltage is?

Heatsink and M.2 Expander Board are out. You can buy them here https://shop.allnetchina.cn/collections/rock-pi-4-accessories?page=2

I built Jock's forked X11 armsoc driver,   Installed and configured the Malie BLOB rpm and configured for X11.
 
Rebooted.
 
I ran glmark2-es2 :
=======================================================
root@nanopct4:~/Desktop# glmark2-es2 --fullscreen
=======================================================
    glmark2 2014.03+git20150611.fa71af2d
=======================================================
    OpenGL Information
    GL_VENDOR:     ARM
    GL_RENDERER:   Mali-T860
    GL_VERSION:    OpenGL ES 3.2 v1.r14p0-01rel0-git(966ed26).f44c85cb3d2ceb87e8be88e7592755c3
=======================================================
[build] use-vbo=false: FPS: 11 FrameTime: 90.909 ms
[build] use-vbo=true: FPS: 13 FrameTime: 76.923 ms
=======================================================
                                  glmark2 Score: 12 
=======================================================
 
I checked the Xorg.0.log.. armsock_dri isn't installed.  Isn't that part of the armsoc driver build ?
 
[   732.501] (EE) AIGLX error: dlopen of /usr/lib/aarch64-linux-gnu/dri/armsoc_d
ri.so failed (/usr/lib/aarch64-linux-gnu/dri/armsoc_dri.so: cannot open shared o
bject file: No such file or directory)
 
 
Without armsoc_dri I'm stuck software rendering.
 
If you have armsoc_dri.so can you attach it to this thread ?
 
 
I'm pretty sure I'm getting close to getting hardware acceleration working on my nanopc-t4 

Of course. You need to fix this otherwise everything you do is just a waste of time. And it's under-VOLTAGE and not under-current so as long as you ignore Ohm's law you're getting nowhere. The problem is high resistance and most probably (and as usual) the cable between PSU and device is to blame.

I'm going to test with the current stable armbian image and update this thread when done.
 

Some news:
 
https://wiki.radxa.com/Rockpi4/downloads
 
There is a first Armbian image available.

Yep.. I am using uname -a to get the architecture type.   I get aarch64.
I will rebuild with arm64 and post it.
It should be posted within the hour

We all know there are several shortcomings which causes mess in the config files and prevent simple implementing of more complex scripting. In order to make build system future proof and to cleanup the exception mess, which is virtually everywhere, I decided to start working on a part of the build system. Now the concept works and it is not that far to be mad if idea is bad
 
packages/extras was moved into this, then board support package and (for now) Cubietruck and Tinkerboard hacks from config/sources/ All others have to be implement into packages and their scripts. It's one time job and it will be much easier in the future, with new boards or functions.
 
New board support packages are now broken into unlimited number of packages. Currently there are three main groups and already present logical packages. Most of present are tested and are fully operational. Mostly its copy/past with bug fixed here and there. Perhaps some bugs were made in this process, but in essence system works - for those two boards. Upgrade path is not determined yet - I only focused on packaging and installing. All those packages can be installed from freshly build ones or from the repository. Each package can have their own number and package is rebuild only if number upstream doesn't exists.
 
This RFC includes preliminary merge of @balbes150 TV boxes fork so it's ATM a bit messy. Cubietruck and Tinkerboard images were tested (Bluetooth briefly, audio need to check again), the rest is not prepared and it requires some manual work. I hope someone else, not just the usual suspects, will help doing this.
 
I will slowly move forward and keep it mergeable/synced with upstream.
 
This approach is more or less only a working proposal for changes. IMHO it's better than what we have now but not perfect.

(WIP) Readme with some more details https://github.com/armbian/build/tree/tvboxes/config/packages
 
You can try this by adding LIB_TAG="tvboxes"
 
Edit:
 
Skeleton is done, images can be build from this branch ... Most but not all of our current families and board specialities has been moved under this packaging system. I tested Cubietruck, RockPro, Tinkerboard. At least they works fine - checked for Bluetooth (TB/CB3) and video acceleration on Cubietruck.

TBD: adjust changes in armbian-config regarding desktop (nodm is gone, lightdm only with possible autologin) and kernel switching.

@JMCC Welcome to try adding perhaps Tinkerboard MM script as a new multimedia/something package. What shall be its name? If some 3rd party packages needs to be placed to the repository, put them here: https://github.com/armbian/upload
 
@gprovost mvebu family is not there yet, but if you got time it should be clear what to do? If not, I wrote lousy docs or scripting is more complicated as before  
 
@selfbg Added Olimex SOM204. Check when possible.

@zador.blood.stained Are packages relations alright? I hope they are future proof. Upgrade is planned from armbian-config and is actually optional. Older packages, except boot and kernel are no more.
 
@tkaiser cpufreq is not overwriting anymore, serial consoles are board property SERIALCON="ttyS0,ttyGS0", board config is reloaded right before packages building. Shell we move hardware-optimisations.sh to per board script? Changes should not affect OMV.
 
@Staars Z28Pro merged but untested
 
@lanefu @5kft @TonyMac32 .... check.

@balbes150 have a lot of work to move his scripting into the build engine. Helping him, testing, fixing, ... @all Check and join if you can.
 
beta.armbian.com can be switched to this new world order ASAP.

Expected merge due: 2/2019 ?

Happy 19!

Edit by lanefu 7/2019:

A project #1 has been created on github.   There are several tasks, which will be tracked as issues on the board.

I made a custom Plex Media Player build that leverages the decent performance we get with the fbdev/dri driver.
I tested Rockchip MPP gstreamer plugin.   The Rockchip Hardware VPU is very basic, it breaks with mkv playback, so I decided to use ffmpeg software decoding since it's extremely robust. Also 1080p playback through DRI isn't too shabby!.  If you want 4k video then you need to contact Rockchip.   They seem to be overwhelmed or not interested in bringing 4k support to Linux.   I built a .deb package that will install plexmediaplayer to /usr/local.  No worries about installing to somewhere and clobbering an official library or package.    Official Armbian dependencies will be installed to the proper location.  The plexmedia web-client will be installed to /usr/local/share/plexmediaplayer, the Qt5 binary will be installed to /usr/local/bin/plexmediaplayer
 
install with:
gdebi plex-media-player-install.deb
 
remove with:
apt-get remove plex-media-player-installer
 
To fix the installer package I basically reflashed my NanoPC-T4 with a clean Armbian image,  printed out the errors.
Updated the Debian control file with all the proper dependencies.  
 
Here's the binary install package.  
 
 
 
If you get a dependency error you can use the --ignore-depends dpkg argument and resolve after the install.
The files are installed in an easy location to clean up. 
plex-media-player-install.deb

Igor, I have a plan.
 
I will rework the kmpp module. rebuild ffmpeg and mpv with kmpp support.  I am looking at methods to fix the video playrate issue 
 
Once I have video playback working with hardware accelleration I will upload the binary and source Deb packages.
 
I never even thought the issue was Armbian Support. No.. everyone here is very helpful. It is all Rockchip fault.
I have some Asian friends.
I know they turn beet red after a few drinks and I wouldn't put it past rockchip that the poor vpu support is
Because they are trying to get a large share of and control of  the cheap TV box market.  
Reverse engineering takes longer... Vpu will be working soon
 
Thanks

You can skip board makers from this. They would like to give you full blown Linux supported distro, but they can't deliver that. Rockchip is little more to blame if anyone. They were promising 3399 opensourceness and they are trying but they also can't do this alone. Linux is a community project per se. It's too big task for a few engineers which are working on Linux kernel. Their main focus is providing Android which nobody cares if it is not open source.
 
3399 is actually very well supported if you compare to other chips and it takes time that all boards features works at their maximum performance. Video acceleration is a complex hack and in some/most cases support is done via closed library. Since you are mentioning Nvidia: 
 
 
Without community work, you could only "enjoy" crippled buggy "deploy and forget" images (not a Linux distribution) that come from the board maker's labs and community repackers. FriendlyARM's work support is actually good, one of the best in the industry. They can't support end users - we also can't - except "as is" on forum. If you would send me a technical question an email/PM, you will most likely not get an answer. I stopped doing that, because day has only 24h hours and there is a huge list of people and even bigger list of problems. Most of people mix free software with free work and don't even think that they have to refund for the time wasted ... or risk to receive the same answer as Torvalds gave to Nvidia 
 
Board makers can't provide top shit Linux and don't even try. They would close their company very quickly if they would try to do that. Cost of software support is magnitude higher then making hardware. We at least try improving despite its economically unjustifiable. If this take years, so be it. 

Allwinner case - at the end, this is how things are done - we pay and we done. 3rd party kernel hackers company raising money and putting professionals for certain amount of time on the project to push hardest things forward in truly Opensource way. This is just a help to already vibrant community.  You still need to solve all the dependencies and implement the solution.
 
 

I am not dealing much in this area so I don't know how good or bad the situation is with the RK3399. This is how we done it for older RK's - it's community addition, which is at some point hopefully integrated into Armbian. Even that is hard since we extremely lack people/resources to maintain this project and cope with a 1000+ wishes which are regularly on the list.

Hi NicoD.  
 
Here's the video of the NanoPC-T4 Plex Media Player  1080p   Android 8.0   I want to run Linux, not android.   Also the android image has it's own UI bugs.  
 
Here's the video
 
https://www.youtube.com/watch?v=lKRn3eLjGa4

I'll try to shoot a video and post it of what the NanoPC-T4 can stream with the FriendlyARM Oreo 8.0 image.    The rat bastards at friendly arm are not releasing the entire source.  Other individuals downloaded the source and attempted to make their custom kernel and image.  FriendlyARM and Rockchip are not publishing all the code.   
I don't want to run android.   I want to get the VPU working because that's how hardware acceleration is important.  I also want to port my SLAM navigation code from my Tinkerboard  based robot to
the NanoPC-T4.     I need OpenCV with full accelaration, also I use VAAPI for video.  I figured I'd take advantage of the battery backed RTC and allow  the robot to sleep while charging and wake at 
at a set time.     The hardware is great,  the published software, no.    I will boot the board up with Android 8.0,  stream a video from my Plex Server at 1080p.  I'll show how it works.
I built plexmediaplayer for Armbian.   I have some hardware MPP support build, rockchip plugins working in Armbian, but MPP is not ready at all. It's buggy, video frames are too fast, audio out of sync by 1 second.
 
The main issue is we don't have proper T860 GPU and VPU support from Rockchip.  Panfrost is far from being "ready"  I downloaded it and tried it.  Also it does not cover VPU support.