NicoD

Technical support section is mainly a feedback to improve Armbian as operating system. We can only deal with Armbian images and our tweaks. That's plenty of work and we have to do something about that.

"If you deal with everything you fix nothing"
 
Common issues sections is already on the edge/outside since mainly contains generic Debian/Ubuntu problems, which we don't have intention nor resources to deal with. Armbian specific problems are already enough. I am seriously thinking to move it to less restricted "community" area, where only general restriction apply.
 
More topics in technical support could also mean developers are doing a lousy job in making Armbian. But since overall user base is growing and since we people are lazy by default (I also belong to that tribe), this section also grow. No forum around is happy on opening more topic for the same issue. Over and over again. Technical support questions are specific. They need to contain certain things or they are useless.
 

That was also intendenten. When you are putting a pressure and wasting precious time, you are making a damage and if you are aware of this, a progress was made. For all of us. It's like traffic regulations.
 

Yes, that's all about. All this is just yet another SPAM filter. One out of many that we already use.

After removing the noise from the input-data, I now got quite reasonable RPM values for the Noctua NF A14:
 
RPM per duty_cycle [ns] duty_cycle RPM 180 158 200 476 250 637 300 938 400 1111 500 1200 2000 1251  
Below 180ns the fan stops, above 500ns it doesn't really increase anymore.
 
fan.svg

So the Media Script is finally released:
 

wow.. nice bacteria rick and morty fun  
 

THE MEDIA SCRIPT IS DEPRECATED, IN FAVOR OF THE LEGACY MULTIMEDIA INTEGRATION. PLEASE REFER TO THIS TOPIC:
 
So finally we have the first version of:
The UN-official, UN-supported, etc...
RK3399 MEDIA TESTING SCRIPT
 
This is the first release of the RK3399 media testing script. The script provides a functionality similar to its RK3288 equivalent:
Installing all the libraries and system configurations necessary for GPU accelerated X desktop, Chromium WebGL, full VPU video play acceleration up to 4k@60 10-bit HEVC (the maximum supported by the SoC), and GLES 3.2 / OpenCL 1.2 support. Three video players supporting full VPU acceleration (RKMPP) and KMS display (GBM or a X11 DRM "hack", as described by the authors), namely: MPV, Gstreamer and Kodi. Two example programs using the OpenCL functionality: Examples form the Arm Compute Library, and a GPU crypto miner (an old version, but small and simple). A library that will act as an OpenGL to OpenGL-ES wrapper, allowing you to run programs that use OpenGL 1.5-2.0. Two additional features, that have no big interest from the Armbian development prospective, but I find them interesting to play with:  Chromium browser with support for Flash and DRM-protected commercial web video streaming (tested with Amazon Prime, should also work with Netflix, Hulu, etc.), and a simple Pulseaudio GTK equalizer using LADSPA.  
Here is a more thorough documentation:
 
>>> DOWNLOAD LINK <<<
 
Prerequisites:
You need a fresh Armbian Bionic desktop image with legacy kernel installed.  
Instructions:
Download the file above Untar it: tar xvf media-rk3399_*.txz cd media-script ./media-rk3399.sh  
Notes:
This script is not officially supported by the Armbian project. It is just a community effort to help the development of the main build, by experimenting with a possible implementation of the media capabilities of this particular SoC. Therefore, questions about the script should not be laid out as support requests, but as commentaries or community peer-to-peer assistance. That being said, all commentaries/suggestions/corrections are very welcome. In the same way, I will do my best to help solve any difficulty that may arise regarding the script.  
Enjoy!

RK3399 media script released, with full VPU acceleration support:
 

so today we're talking a little bit about the buildscript (likely that those posts will be splitted out into it's own thread to build up a miniseries of tutorials)... I just talk about basics of it. To be honest, I don't know every part of it fully but for detailed questions there are people here which can answer specific parts. For the simplicity we assume that the SoC on the board is a supported one (rk3399 is). A basic overview with tree -L 2 to get a overview:
 
cache: to avoid downloading the sources again and again every time you build an image and saving you time to build images, armbians build-script caches sources (e.g. rootfs, kernel sources, u-boot sources, atf, compilers - out of tree sources can't always be compiled with the newest compiler versions so we also have some older ones) config: basic configuration files for your board, the kernel and sources we use. config --> board: an armbian specific boardconfig file, for the RockPi 4b it looks like the follwowing: # RK3399 hexa core 2G/4GB SoC GBe eMMC USB3 WiFi BOARD_NAME="RockPi-4B" BOARDFAMILY="rockchip64" BOOTCONFIG="rockpi4b-rk3399_defconfig" # MODULES="" MODULES_NEXT="" # KERNEL_TARGET="default,dev" CLI_TARGET="stretch,bionic:default" DESKTOP_TARGET="stretch,bionic:default" CLI_BETA_TARGET="" DESKTOP_BETA_TARGET="" BOARDFAMILY tells you which sources it uses (later more on that).
BOOTCONFIG telly you which xxx_defconfig file in u-boot will be used (maybe something for an u-boot plumber tutorial follow up) Modules is only needed if you've to install special modules to enhance functionality (something for a more detailed tutorial).
KERNEL_TARGET (will be explained in sources), CLI_TARGET (which flavors of Armbian you can build (here we provide only ubuntu bionic and debian stretch for some older kernels we've to provide xenial as well cause they're not able to work properly with stretch or bionic).
DESKTOP_TARGET - same as CLI but with a DESKTOP (e.g. we don't provide DESKTOP images for boards without HDMI etc.). CLI_BETA_TARGET not of interest yet.
 
config --> kernel (the .config file you normally get with make ARCH=arm xxx_defconfig if you compile kernels on your own - our configs differ often from defconfigs provided by kernels often to enhance functionality) config --> sources as you can see, the RockPi4b is part of the rockchip64 family therefore (https://github.com/armbian/build/blob/master/config/sources/rockchip64.conf):   for a beginner, most of this configs here can be ignored cause it needs some knowledge to deal with but a few interesting parts will be explained. It basically describes you which sources we use for ArmTrustedFirmware (part of  all(most?) ARM64 boards during boot. U-boot (before the kernel fires up) and which kernel sources will be used for default (often a BSP Kernel), next (mostly a vanilla kernel) and dev (mostly a kernel close to mainline - for rockchip64 for example this is a kernel based on 4.20). some tweaks needed to build an image (e.g. different SoCs expect the u-boot binary on a clear defined place inside the SD-Card for example here: dd if=$1/uboot.img of=$2 seek=16384 conv=notrunc status=none >/dev/null 2>&1 ) tweaks which are needed to boot up the board (e.g. rockchip needs a few binaries and it depends on which rockchip SoC, (sometimes also ramspecific) you use to boot up a board - rockchip64 is for rk3328 and rk3399 and they use different binaries) some family_tweaks here to enable debug console etc. (boardspecific tweaks are also here with some if statements to keep those changes separated from the others). To do changes here or to create such a file from plain (for a new boardfamily) you might need some more experience but it's worth to have a look at it (especially to check which sources we use). The rest of config is currently not that important.
config-default.conf (shows up after you build an image for the first time): this file will be important but since this post here gets anyways too long I try to explain it in the next days (it deserves to have it's own day)
lib: the build-script is not only one big bash-script it's splittened into different ones. In the beginnings you (hopefully) don't need to change something in them but cause the script isn't everywhere 100% clean (we've to be pragmatic here + different people have different opinions how stuff should be solved) it's worth to try to understand how random part of the script work (needs knowledge in bash and definitively not learned within a few hours - you need some background this grows over time)
output: that's where your kernel config (if you decide for Show a kernel configuration menu before compilation - would also need it's own post), debs (debian packages built during compilation, e.g. needed for sending kernelupgrades via apt upgrade), debug (also something for a further tutorial - you'll have a lot of fun with this folder during development ) images (the finally compiled images if nothing fails) patch (will be explained in the follow up, but that's most of the work devs do here.. - e.g. if we fix something inside a kernel or u-boot etc. a patch is automatically generated this is then moved to the appropriate patch folder and part of the buildscript)
packages:  blobs we've to deliver (e.g. to boot up a board), bsp (board support package - I also call non vanilla kernels bsp kernels, it has similarities but it's not the same - some boards need special configurations, e.g the bananapi r2 which has 5x GbE has here some configuration files to bring up all it's interfaces), tools (never worked with, ask someone else ) extras-buildpkgs for packages we deliver to get the enhanced functionality ( also not needed to understand fully in the beginnings - wouldn't call myself an expert on this part.. )
patch: if you generate a patch for kernel or u-boot and you want that others can use it as well place it here in the right folder, create a pull request to armbian and we'll get it. The structure is 'relatively' simple splitted into kernel, u-boot and atf (you won't patch atf soon.. ) for the kernel then splitted into boardfamily-branch (default,  next & dev - for the rockpi this means rockchip64-default and rockchip64-dev is of interest). For u-boot it's mostly u-boot-boardfamily (sometimes we have two branches for u-boot, e.g. the time we switch from a out of tree u-boot to upstream or we need different u-boot sources. not that often here u-boot-rockchip64-dev is of interest for the RockPi)
userpatch: the same than patches but for stuff you don't submit back to our tree (e.g. you can place your patch there if for whatever reasons it's not accepted by armbian - e.g. if it breaks other boards)
now you got an brief overview how much you'll have to learn until you understand it fully and in the next days I might partly explain how to use it.. If you can't wait reading more.. there you go:
https://forum.armbian.com/topic/6-how-to-build-my-own-image-or-kernel/?page=6&amp;tab=comments#comment-65998
https://forum.armbian.com/topic/7296-bananapi-r2-csc-mt7623-as-new-boardfamily/
 
have fun.

Привет, Балбес.
Do you have got a dtb file for the NanoPi M4 and/or RockPi4B? They've got working Armbian images. But would be cool to be able to use the same image on both boards. 
I wished all images were like this. Then we would not need new images for different boards with simular SoC's.
Can this then also be done with the LibreElec image?
I tried downloading your LibreElec image for the Edge. Got this message 'Произошла ошибка'. I don't have an Edge, but still wanted to let you know.
https://docviewer.yandex.ru/view/0/?*=hmrjCyQfuYVKHUtYSUu1p%2BR66fx7InVybCI6InlhLWRpc2stcHVibGljOi8vdmxhK21JbW9qR0hMNHhKVjc3MzZGSFJFWlIzaVZqS0taK3dUOXJLcVAyYXZNeHdxMnlBYmg4Y0JkNlFqV2RNVHEvSjZicG1SeU9Kb25UM1ZvWG5EYWc9PTovTElCUkVFTEVDLzIwMTgxMjI0L0xpYnJlRUxFQy1SSzMzOTkuYWFyY2g2NC05LjEtZGV2ZWwtMjAxODEyMjQxNDMxNTAtNzljMTBhYi1raGFkYXMtZWRnZS5pbWcuZ3oiLCJ0aXRsZSI6IkxpYnJlRUxFQy1SSzMzOTkuYWFyY2g2NC05LjEtZGV2ZWwtMjAxODEyMjQxNDMxNTAtNzljMTBhYi1raGFkYXMtZWRnZS5pbWcuZ3oiLCJ1aWQiOiIwIiwieXUiOiI2MjI2MjIxNjIxNTQxNTI0MjQwIiwibm9pZnJhbWUiOmZhbHNlLCJ0cyI6MTU0NjEyMDQxMDA0M30%3D
 
Спасибо, привет.

yes and there are good reasons for it.
Linus salary is also partly paid by Microsoft... https://www.linuxfoundation.org/membership/members/
 
it's never too late..   for sure you'll find something else to contribute.

RockPi is ok with vp9 4k60fps, thanks for telling me about it (about RockPi)

I did not had this message (but LongChair's mpv seems to not working with 10bits? on rk3399) so what i did:
cd /home/dante4 && mkdir video && cd video && git clone -b master https://github.com/rockchip-linux/libmali && git clone https://github.com/rockchip-linux/mpp && git clone -b master https://github.com/rockchip-linux/gstreamer-rockchip && git clone https://github.com/rockchip-linux/gstreamer-rockchip-extra && git clone https://github.com/mpv-player/mpv-build cd libmali && cmake CMakeLists.txt && make -j4 && make install && ldconfig LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/include cd ../mpp && cmake -DRKPLATFORM=ON -DHAVE_DRM=ON && make -j6 && make install apt-get update && apt-get upgrade -y && apt-get install -y libqt5opengl5 libqt5qml5 libqt5quick5 libqt5widgets5 libqt5gui5 libqt5core5a qml-module-qtquick2 libqt5multimedia5 libqt5multimedia5-plugins libqt5multimediaquick-p5 qtmultimedia5-examples qtmultimedia5-doc-html pkg-config gcc make git unzip wget xz-utils cmake devscripts equivs build-essential docutils-common mercurial cmake-curses-gui build-essential yasm mercurial cmake cmake-curses-gui build-essential gcc-arm-linux-gnueabi g++-arm-linux-gnueabi texinfo nasm automake pkg-config apt-get install libass-dev apt-get install libfdk-aac-dev fdkaac aac-enc libfdk-aac1 apt-get install autoconf automake build-essential cmake git-core libass-dev libfreetype6-dev libsdl2-dev libtool libva-dev libvdpau-dev libvorbis-dev libxcb1-dev libxcb-shm0-dev libxcb-xfixes0-dev pkg-config texinfo wget zlib1g-dev yasm libx264-dev libx265-dev libnuma-dev libvpx-dev libfdk-aac-dev libmp3lame-dev libopus-dev mc locate libghc-bzlib-dev and then i configured FFmpeg with this options
PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" +http://forum.loverpi.com/discussion/comment/1426/#Comment_1426
 
with doing this first
where $home/ffmpeg_build is place where folder FFmpeg laying

And SBC vendors - they just look for the best solution to fit their needs and business plan for a certain board...
 
The cost and efforts need to verify/validate ISA conformance are extremely high, as they should be - you look at companies like Intel and AMD, qualification of a chip can take years - and same with ARM folks like Apple and Qualcomm, where they take the ARM ISA and do their own designs - the chips you see on the market now were actually done 3-4 years ago in a cadence of development.
 
And that's millions of euro's/dollars...
 
You look at SoC vendors like Allwinner, Rockchip, Amlogic - they're using IP blocks that have been pre-certified by ARM (and others) with the fabs - so each block has tapeouts for a certain geometry node and process.. Grab the ARM core of choice, the Mali GPU block, wrap it around DesignWare blocks for peripherals for UART's, GPIO, Ethernet, etc... It's like lego's or ikea furniture...
 
And to the CN side - this is all dependencies on foreign IP... whether is ARM, Intel, Imagination Tech (GPU's with PowerVR), MIPS, Oracle (ex-SUN), etc...
 
With RISC-V - that's all out the door - which makes this interesting - going back to CN, there's enough government money at the local and national level to make things happen, and enough research in the academic space, along with the industrial resources to get things done...
 
Remember the CN initiative - "Made in China 2025"
 
I'm just an observer on the industry here - not being political...but it is interesting what the mainland is doing, and worth watching...

that's ok, but what I have found is that UnixBench a good equalizer across different SoC's on these cheap little boards - even though UnixBench is still variable based on the compiler...
 
It runs long enough (a full run can be 28 minutes) to show if thermals are a challenge (for TinkerBoard, absolutely with stock config compared to NanoPI NEO, where the Tinker has a much better architecture (A12) vs. NEO with A7, but the Neo can shed heat faster, and outperform the Tinker in the longer run - heck, even Pi3B+ runs UnixBench faster than Tinker...

Good questions, I've added them. Thanks.

How can SoC vendors help here with support for chips, interfaces, GPU/VPU, network, etc...
The Armbian team has done a lot of development, how receptive has upstream been to accepting changes/pull requests?
What's the best approach for SoC/Board Vendors to get Armbian ported to their board/chipset?
Documentation is key for supporting a chip or board - where are the opportunities for the vendors to improve?

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.