gounthar

Another one with 8Gb RAM

The patch was very recently added in 5.11.6.
I'm not sure how you install the kernel after the fact—I simply built a new bootable image with armbian-build (choosing sunxi-dev as the kernel with ./compile.sh EXPERT="yes") and flashed that to µSD.

You can create a swap file for this.
If you're using an sd-card then it will be very slow, but it will work. You can use zram and swap files together. It will first use zram, then swap file.
Here is how to create a swapfile. This is for 8GB, if you only need 1GB then use 1GB. When done just reverse the commands and delete /swapfile (sudo rm /swapfile)
sudo fallocate -l 8G /swapfile Allocate 8GB for swapfile sudo chmod 600 /swapfile Give the correct rights for the swapfile sudo mkswap /swapfile Make it a swapfile sudo swapon /swapfile Turn on the swapfile sudo nano /etc/fstab Open fstab and add the line ... /swapfile swap swap defaults 0 0  

It must be 5.11, so you need to build from source.
Something I forgot to mention (going to edit the post now): the kernel must be built with this patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7072db89572135f28cad65f15877bf7e67cf2ff8
It's been accepted for upstreaming and will be included in 5.11 later, but up until 5.11.3 at least, you need to include it as a userpatch.

If RK3399 maybe make good use of the PCIe lane?
 
I have an addiction to headless SBCs

Suggestion for a (near future) product.
 
We're still lacking a good SBC out in the wild for small clusters.. Recent SoC performance is good.. Currently all the homelab and k8s nerds are just using RPI4s because they have a header for POE support.    We know there are better options.

We had pitched this to orange pi but weren't receptive. Just sharing my idea here.
 
A Lean SBC exclusively for server tasks.
"The Ultimate Homelab SBC"

Real 802.11at POE+ means only 1 cable for your compute node
Use SPI flash for custom provisioning configuration
 
Optimized for Compute
"Ready for clustering and kubernetes"
Has the Performance and Storage you need to easily deploy for clustered computing

Suggested Reference Specs
RK3399K or similar performant SoC Gigabit Ethernet 4G Dual Channel LPDDR4 16-32gig EMMC SPI flash 128mbit/16megabyte No Wifi No bluetooth No audio No CSI No HDMI USB 3 802.11af/at support or support for RPI4 style 6 pin POE hat All Ports in rear? holes for additional heatsink mounting options

Thanks to the very patient support from jernej and ndufresne on the linux-sunxi IRC channel, I could confirm that GStreamer 1.19+ works out of the box on the 5.11 kernel (sunxi-dev), tested with Hirsute and Bullseye, at least on the H3/Orange Pi PC. (I haven't been able to build or run a 5.11 image on a H6 device, so I couldn't test it there yet.)
 
Kernel:
Build 5.11.y with this patch, must be included as a userpatch. 5.11.6 includes it from the getgo, but below that you need to add it yourself:
<jernej> PPA: kernel 5.11.6 is released with Cedrus patch  
Requirements:
sudo apt update sudo apt install meson ninja-build pkg-config libmount-dev libglib2.0-dev libgudev-1.0-dev libxml2-dev libasound2-dev  
Building & installing GStreamer:
git clone https://gitlab.freedesktop.org/gstreamer/gst-build.git cd gst-build meson -Dgst-plugins-bad:v4l2codecs=enabled -Dgst-plugins-base:playback=enabled -Dgst-plugins-base:alsa=enabled build ninja -C build cd build sudo meson install sudo /sbin/ldconfig -v  
You can play videos from the command line to the framebuffer. At least on the OPiPC there is a problem where it doesn't automatically play on the correct DRM layer and the video is hidden. To fix this, it needs to be ran once per boot with “plane-properties=s,zpos=3”:
 
gst-play-1.0 --use-playbin3 --videosink="kmssink plane-properties=s,zpos=3" video.file  
Afterwards it should be fine with just gst-play-1.0 --use-playbin3 input.video (until the next reboot).
h.264 (except for 10-bit, which the hardware cannot handle) decodes smoothly with CPU load across all cores around 2%–5%.
 
 
Thanks; the OP was edited accordingly.

The GPU accelerated trend with the SBC community will depend on the Panfrost driver development. After some testing on current version of Mesa (20.2.6) on Armbian, only the Midgard series (Mali-T###) will work. Mali-G30, Mali-G50 and Mali-G70 series (Bifrost) is not included in Mesa (20.2.6) without tweeking. At the current time the Mesa project version 21.1, the Panfrost driver is unstable/broken and several commits behind the target branch (master).
 
Might be worth waiting until the official release is available!

https://my.banggood.com/H96-MAX-RK3566-SDRAM-8GB-DDR3-64GB-eMMC-ROM-Android-11_0-8K-UHD-TV-Box-bluetooth-4_0-5G-Wifi-1000M-LAN-H_265-VP9-4K-Decoder-Voice-Control-OTT-Box-p-1820334.html?cur_warehouse=CN&ID=47184&rmmds=search
 
This might get me back to tinkering with TV boxes again.

This is a bit incorrect. libvdpau-sunxi is using for decoding only.
The Cedrus legacy driver has been supported to run on mainline kernel as KLM.

Good summary, let me clear some things.
Having proper uAPI by no means makes libva-v4l2-request obsolete. If this lib is updated to latest uAPI, it still could serve as intermediate layer for all apps that don't support new interface but they support VA-API.
Before you talked about libva-v4l2-request, which implements VA-API, so I wouldn't say it's irrelevant to ARM HW accel. libvdpau-sunxi implements VDPAU, but that works only on BSP kernels and it is not relevant for mainline.
Further clarification: Kodi 19.0 (released recently) is highly recommended for all this - it doesn't require any out of tree patch for video decoding (LE uses patch for HW deinterlacing). Additionally, with version 19.0, there is single binary for all 3 windowing systems (gbm, X11, wayland). Depends on build options. Not sure if this version is available on Armbian but PPA exists, so I guess it should not be hard to test.
H264, MPEG2 and VP8 should be good in mainline, although api can still change until codec is promoted to uAPI. HEVC still needs out-of-tree patches for any serious work.
 
Maybe you can update your text, so we have current state overview in single post.
 

I've taken peeks at threads related to hardware decoding (of H.264 and HEVC, mainly) on Allwinner and Rockchip platforms on and off, sometimes dabbled in trying and failing to implement solutions recommended there. Being a complete amateur, I find the topic very opaque and confusing, with various different components that need to interface with each other, be patched in sync, and sometimes change drastically between kernel versions, etc. Today I sat down and read up on these subjects, scouring wikis, documentation, this forum, and assorted other sources to try and understand how this works. In this post I will attempt to compile what I've learned on the different software components involved, their relationships, their current status, and solutions to the problem. I hope people more knowledgeable will correct me when I get something wrong or cite outdated information. Stuff which I am highly uncertain of I will print in italics.
(This post is going to focus on mainline implementations of Cedrus/Allwinner, I haven't looked into Hantro/Rkvdec/Rockchip specifics yet. I will speak only of H.264 and H.265/HEVC; I don't understand the high/low stuff and didn't pay attention to other codecs.)
 
Components:
 
Basics: Video codecs like H.264, H.265/HEVC, MPEG-2, etc. are standardised methods which serve to more efficiently encode and decode videos, reducing their filesize. Software en-/decoding is very CPU-intensive. Modern GPUS and ARM SoCs therefore contain specialised hardware (VPUs) to delegate these tasks to. Working hardware decoding is particularly important for underpowered ARM CPUs.
Drivers: Topmost in the stack are the VPU drivers. These are Sunxi-Cedrus/Cedrus V4L2 M2M and Cedar [Is this the legacy one?] on Allwinner; Hantro and Rkvdec on Rockchip. These are all still in development, but Cedrus already fully supports H.264, and partially supports HEVC, and is already usable in the mainline kernel.
APIs: In order for anything (userspace APIs, libraries) to make use of the VPU drivers, you need backends/APIs. For Cedrus, there is the unmaintained libva-v4l2-request backend which implements VA-API, the legacy VDPAU implementation libvdpau-sunxi, and as of kernel version 5.11, H.264 has been merged into the uAPI headers. Different applications may make recourse to one or another of these APIs.
Libraries: FFmpeg and GStreamer. provide libraries and APIs of their own to other applications but can (importantly!) also output directly to the framebuffer. FFmpeg must be patched to access either libva-v4l2-request or the Cedrus driver headers. GStreamer directly accesses kernel headers since 1.18 (works on 5.9, not on 5.10; 1.20 will support 5.11.)
Media players: mpv and depends on FFmpeg for hardware acceleration (and must be patched together with it). VLC can be set to access libva-v4l2-request directly. Kodi 19.0+ supports hardware acceleration out of the box without any out-of-tree patches.
Display server: An additional complication is drawing the output of any of the above on screen. Most successful implementations I've seen bypass X11 and either output directly to the framebuffer or force a plane/display layer on top of any X windows. Wayland apparently makes this easier by allowing applications to use their own DRM planes, but this hasn't been explored much yet. Kodi 19.0 works with all three windowing systems (X, Wayland, and gbm).
 
Codec status:
 
Taken from the LibreElec thread (which reflects LibreElec's status and is ahead of what works elsewhere, but outlines hardware limitations):
 
 
Approaches:
 
Many people have managed to make it work on their machines using different approaches. Note that some of these solutions are one or two years old, and kernel developments since may have changed the situation. Ordered from newer to older:
 
LibreElec – kernel + ffmpeg + Kodi: LibreElec is a Just-Enough-OS with the sole purpose of running Kodi, a media player. It's at the bleeding edge and usually implements codecs and features well before mainline or other distros. It achieves this by heavily patching everything up and down the stack, from the Linux kernel over FFmpeg to Kodi itself. These patches could all be applied to an Armbian build, but there are a lot of them, they're poorly documented, and you'd need to dig into their github to understand what they all do. LibreElec runs Kodi directly without a desktop. kodi-gbm is a package that can be installed on Armbian and functions similarly.
Key contributors to the project are @jernej and @Kwiboo, who sometimes post about their work here (and have been very helpful with questions, thank you). @balbes150 includes some of LibreElec's patches in his Armbian-TV builds, but I don't know which.
 
Kodi 19.0: 
 
LibreElec patches + mpv:
 
 
@megous – Kernel 5.11 + GStreamer: This implementation, done here on a PinePhone (A64), patches the 5.9 kernel and uses a recent version of GStreamer (1.18 and up), whose output is rendered directly to a DRM plane via kmssink. (No X or Wayland.)
GStreamer 1.18 works with the 5.9 kernel. It does not work with 5.10, because of numerous changes to the kernel headers in this version. In 5.11 the H.264 headers were moved into the uAPI; the master branch of GStreamer reflects this, but there haven't been any releases with these patches yet. It'll probably be in repositories with GStreamer 1.20; until then you can build it from source.
 
@Sash0k – patched libva-v4l2-request + VLC: This updates bootlin's libva-v4l2-request and follows the Sunxi wiki's instructions for enabling VLC to make use of it. It works on the desktop. This only works for H.264 and breaks HEVC. When I tried to replicate this approach on a recent Armbian build, I discovered that the h264.c files in the kernel (that libva-v4l2-request draws on) have changed considerably between 5.8 and 5.10, and I lack the understanding to reconcile libva-v4l2-request with them.
 
@ubobrov – old kernel + libcedrus + libvdpau-sunxi + ffmpeg + mpv: This approach, which supports encoding decoding of H.264 uses the libvdpau-sunxi API and ports the legacy driver to mainline as a loadable kernel module and if I understand it correctly, ubobrov ported a legacy feature to mainline. In the post quoted below the kernel is 4.20, but the same method has been successfully applied to 5.7.8 by another user. It requires that the board's device tree be patched, as documented in ubobrov's github repository.
 
 
The summary seems to be that none of the current implementations on Allwinner boards really play nice with X or desktop sessions, and it's best to output directly to the framebuffer. Kwiboo has forked FFmpeg and mpv to make good use of new and unstable kernel features/hardware acceleration which will take a while to make their way upstream. The recent 5.11 move of stateless H.264 out of staging and into the uAPI should facilitate further developments.
I intend to try some of these things in the nearer future. Thanks to everyone who works on mainlining all of this VPU stuff, and to users here who contribute solutions and readily & patiently answer questions (Jernej especially). I hope I didn't post any falsehoods out of ignorance, and welcome any corrections.
 
Other related threads here:
https://forum.armbian.com/topic/11551-4kp30-video-on-orange-pi-lite-and-mainline-hardware-acceleration/
https://forum.armbian.com/topic/16804-orange-pi-pc-h3-armbian-focal-5104-sunxi-av-tv-out-cvbs-enable/page/2/
https://forum.armbian.com/topic/11184-hardware-graphicvideo-acceleration-in-h3-mainline/
https://forum.armbian.com/topic/13622-mainline-vpu/

On the TX6, I removed the bottom cover of the case and use this model upside down (so that the radiator looks up and has a good run for air movement). I do not know what kind of idiot designs TV boxes in China, they put the board in the case with the radiator down, this is complete idiocy. Apparently, these "engineers" did not go to school and do not know the laws of physics at all - hot air always moves up (if there is no fan). Therefore, with passive cooling (without forced air supply from the fan), it is necessary to place the radiator so that the air passes to it as best as possible and the heated air freely goes up.

New Image 20210123 for H6, kernel 5.10.9
 
https://yadi.sk/d/0a41swJcEAZ0SQ?w=1
 
 
https://mega.nz/folder/j9QSDQSQ#6WpasOlbZYIInfw6yo4phQ/folder/K9BRjSaZ

Reboot doesn't seem to be working. It either shuts down, or stays on without doing anything. 
Otherwise it all looks ok. I do have a problem with kazam when the media script is installed. I've had that too on M4V2 with media script in Buster, so it's not the image.
I'm filming everything to make the video. I'll not use Android to write the image, I'll link to the video of @gounthar instead. He clearly has more Android knowledge, and way more patience. 

Armbian is little more than a stock Debian/Ubuntu installation with the aim of providing recent kernel, bootloaders, and some quality of life userspace customizations.
 
None of those seem needed for a docker image. Maybe start with the upstream image of whichever version you're using for your Orange Pi?
 
If you do need certain things from Armbian, you can always copy the apt configuration from /etc/apt/sources.list or sources.list.d into your Dockerfile and go from there.
 
 

Hello everyone!
 
Is there anyone who tried to run Docker on armbian?
 
Ok, let's start from the beginning: I am from the Hypriot Team (we made Docker available on ARM) and recently saw some guys successfully playing with Docker on armbian. Meanwhile, we know, that our Docker runs at least on the Cubietrack and Lamobo R1/BananaPi R1 on top of armbian!
 
This is awesome because, you know, IoT is coming, and Docker on ARM helps get a grip on many challenges induced by IoT. However, we were only able to support Docker on Raspberry Pis so far...  Imagine if Docker would run on more than just a few ARM boards! Armbian seems an awesome platform to extend the family of Docker compatible boards.
 
So, I wonder if there is anyone who tried to run Docker on armbian?
 
If you are now curious about this topic and wanna get started, please see this blog post of how to install Docker on ARM within no time: http://blog.hypriot.com/post/family_arm_hardware_for_docker_more_children/
 
Looking forward to get in touch with you guys!

I did it. Somehow.

I did it. Somehow.

@NicoD Can you shoot a video on how to download and burn an Armbian image to an SD card using only a regular Android on P1 ? I. e. I am interested in a video how to run Armbian with only P1. This instruction allows any user, without any additional devices (PC, laptop, etc.) to get a working Armbian on any supported device.

For start, you might need to install kernel headers. 
 
armbian-config -> software -> install headers
 
Then try again. Regarding display connection or if the method is proper - no idea.

Are you mainly going to participate live, listen later to recordings or not at all? Any topics that are related, close to single board computer world to recommend?

I am still working on my "shopping list", but this is some initial draft from https://fosdem.org/2021/schedule/
 
QA
About the joy and tears of testing Embedded Devices
https://fosdem.org/2021/schedule/event/testing_embedded_devices/
Interactive debugging inside CI systems
https://fosdem.org/2021/schedule/event/debugging_inside_ci/
QAOps - The Latest Trend in QA & Software Delivery
https://fosdem.org/2021/schedule/event/qaops/

Software Composition devroom
Overview Software Bill of Materials (SBOM)
https://fosdem.org/2021/schedule/event/sca_overview/
 
Legal
Protecting against proprietary re-licensing with a community contract
https://fosdem.org/2021/schedule/event/qtproprietaryrelicensing/
 
CI
ARM your continuous integration system with fruits! by @gounthar
https://fosdem.org/2021/schedule/event/arm_your_continuous_integration_system_with_fruits/
 
Community
Mental health and free software
https://fosdem.org/2021/schedule/event/community_devroom_mental_health_free_software/
 
And one fine Belgian beer for each day of the conference also just arrived  
 
 

I regularly delete my branches because all work is eventually merged to  https://github.com/LibreELEC/LibreELEC.tv (you quoted quiet old post).
 
But as @Werner said, H616 is not exactly the same as H6 regarding display stuff so it needs quiet a lot of work. Cedrus will be probably easy, but that comes after display stack.

I tried with an application Pi SDCard image writer, or something like that, but it does not allow to download images, and proposes only images for the Raspberry.
I then found another application that would burn whatever image you give it, but... it needs a rooted device.
I tried lots of one-click root application (bad idea), but none of them worked.
I then switched to recovery mode, and tried to install TWRP (specific to RK3399 TV boxes), but it fails with an error 21.
Even the opengapps fails the same way.
I tried it with adb sideload, but it fails the same way.
Would someone have a link to a working TWRP for this box, or to a way to root it properly?
As @balbes150 asked, the goal would be to write a tutorial for people wanting to switch from Android to Armbian in the case they have just this computer available, and nothing else.
Thanks.