gounthar

just a little update: i got the open source nouveau gpu driver working with the mainline kernel finally by using a self compiled xorg server from the latest sources (required - see: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3505), a self compiled mesa 21.0.1 (not sure if this is really required) and the "nouveau.modeset=1" kernel cmdline parameter - what is nice is that it is opengl 4.3
 
so far the good part, the bad part is that it is extremely slow (glmark2 score of 68) as it is clocked at the lowest gpu frequency by default and trying to increase the gpu frequency via /sys/kernel/debug/dri/128/pstate seems to make the system quite unstable or quickly hangs it (maybe my power supply - 5.1v/3a - is not powerful enough?)
 
i'm also able to run a wayfire wayland session using the nouveau gpu driver, but it shows quite a few graphical artifacts when scrolling in a terminal or doing other activities - glmark2 score here is 83, but its also for lima or panfrost higher in wayland/wayfire than in xorg/xfce
 
all in all it looks like the quality of the open source nouveau driver on the jetson nano (maybe even in general?) is not really the best and as it looks to me far behind the quality of the lima and panfrost open source drivers for the mali gpus in other socs

Before complaining about an issue read this!
 
tl;dr: Put your Zero2 and/or any other H616 based device on the shelf and WAIT for proper support to come. And no. There is no ETA. Assuming usable state end 2021/beginning 2022.
 
Software support is still work in progress and under heavy development. Provided preview images can break any time. Do not report this, we are aware of that and can/will not help you with that if you are not willing to investigate and research by yourself.
Feel free to join fellow developers to their efforts to create proper software support. But don't waste our time with complains. Thank you!
 
https://github.com/apritzel/linux/commits/h616-v5
https://github.com/jernejsk/u-boot/tree/h616-v2
https://github.com/apritzel/arm-trusted-firmware/tree/h616-v2-wip
 
 
-----------------------------------------------------------------------------
 
I started to play with this board and obviously failed miserably creating a basic Armbian integration.
 
Anyway. These are the information I collected so far:
 
dtb extraction from Xulong image: https://pastebin.com/raw/Uni2JzBF
 
orangepimonitor 🙄  http://ix.io/2FM0
 
 
root@orangepizero2:/etc/apt# lsmod Module Size Used by zram 36864 2 sprdwl_ng 438272 0 sprdbt_tty 36864 2 uwe5622_bsp_sdio 294912 2 sprdbt_tty,sprdwl_ng  
kernel config: https://pastebin.com/raw/e2jTTZ7A

Here a YT video about the new Station P2. 

I love the design. SATA and NVMe now fit in the case. A bit more usb is great. Dual Gbit ethernet, wifi 6 and up to 8GB ram. RK3568.
I hope they'll also make an rk3588 model.I like their metal cases a lot.
 

@gounthar - i think you do not need esxi as kvm and maybe xen (and some other free hypervisors) are working quite well on aarch64 already ...

Update to version 20210319. Using kernel 5.10.24. Added support for Firefly-rk3399 in station-p1 images (for proper operation, you need to configure DTB in extlinux.conf). With the correct DTB setup, the HDMI audio LAN WiFi BT works in kernel 5.10. In kernel 4.4 worck remote control and analog sound. 

I am running the latest Armbian 21.02.3 on two NanoPCT4s.
Thanks to everyone for this. I didnt think I would see this performance on this device.
But here it is and I see Armbian is getting good notice for this.
I dont know how they did it but these devices are running very well.
I am a little tired this week so I dont have any technical details.
I want to just ramble (opinionate) on how nice this is and what I like about it.
I am running standard Focal Gnome Desktop from Armbian Download.
I just disable the pwm-fan module and run hot.
As long as I dont make -j6 I can avoid meltdowns.
I run Firefox and Microsoft VSCode. I run a complex desktop and my
standard install involves a day of burnin compilation.
I can run Firefox videos and Microsoft Code.
By the way Code can now be downloaded direct from Microsoft.
I run a lot of Python and JavaScript and C++ [avoid Java and C# at the moment
but really I dont have much time considering I do more and more C/C++]
and use Python as scripting language for C. I compile Sage Math 9.2
and that will halt this machine at make -j6 and no fan.
with fan, no problem. but make -j3 works OK with no fan.
After compiling these little ARM devices run SageManifolds doing complex
Jupyter Lab interactions. Pretty slick.
So I think this is a wonderful desktop.
 
I know the Gnome people own GItHub and Microsoft
TypeScript backended on GitHub integrated with the wonderful
Microsoft Code is a great desktop that Armbian is Smart to invest in.
 
more later.
 

Hi @srinath,
I think, there are two possibilities:
 
1. Your overlay is compiled, but not loaded. This may happen, because it tries to access nodes, that are not described. Neither within itself, nor within the device tree.
 
To check, whether it is loaded, you should inspect '/proc/device-tree'. The best way to start is
$ ls /proc/device-tree/__symbols__/ And there must be an 'i2c2' file, containing a string path to dt-node (in my case '/soc/i2c@1c2b400').
 
So now, you need to check out this node. Like I do on my system (+ rreigner's overlay with my completion)
$ ls /proc/device-tree/soc/i2c@1c2b400/ '#address-cells' camera@3c clocks compatible interrupts name phandle pinctrl-0 pinctrl-names reg resets '#size-cells' status $ cat /proc/device-tree/soc/i2c@1c2b400/status okay $ cat /proc/device-tree/soc/i2c@1c2b400/reg | xxd 00000000: 01c2 b400 0000 0400 ........ $ ls /proc/device-tree/soc/i2c@1c2b400/camera@3c/ AVDD-supply clock-names clocks compatible DOVDD-supply DVDD-supply name phandle pinctrl-0 pinctrl-names port powerdown-gpios reg reset-gpios Some files may contain gibberish, that may be resolved by piping them to xxd.
 
2. If the previous test is fine (status contains "okay" and camera@3c child node present), your i2c2 bus may just not end up as /dev/i2c-2! (I have this situation on my OrangePi-PC.)
So it is present and works fine, but it's adapter has a different number and a different name. You just need to know it and pass it's "nickname" to i2c-detect.
So you can list all i2c adapters on your system like this:
$ ls /dev/i2c-* /dev/i2c-0 /dev/i2c-1 /dev/i2c-2  
And you can access their system interface via '/sys/class/':
$ ls /sys/class/i2c-adapter/ i2c-0 i2c-1 i2c-2 $ ls -l /sys/class/i2c-adapter/i2c-*/of_node lrwxrwxrwx 1 root root 0 Mar 17 14:08 /sys/class/i2c-adapter/i2c-1/of_node -> ../../../../../firmware/devicetree/base/soc/i2c@1c2b400 lrwxrwxrwx 1 root root 0 Mar 17 14:09 /sys/class/i2c-adapter/i2c-2/of_node -> ../../../../../firmware/devicetree/base/soc/i2c@1f02400 So, most of i2c adapters have of_node within their system interface, which is a symlink to their dt-node. Remember, how my i2c2 dt-node was called? '/soc/i2c@1c2b400'. And this is an of_node of i2c-1 adapter!
 
So to probe my i2c2 I need to tell i2cdetect to check '/dev/i2c-1':
# i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- And see camera activity on address 3c, as expected.
 
Hope, this helps
 
Upd. Now since @srinath edited comment, mine looks not related.

Adding the Pinebook Pro and T-Firefly ROC-RK3399 PC PLUS a.k.a StationGeeker Station P1 to this list

agree with @NicoD opi3 is close but not quite.  Anything rk3399 is going to provide the best desktop experience.

8K fake
 
https://www.cnx-software.com/2021/03/04/rockchip-rk3566-tv-box-h96-max-android-11/

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