Willy Moto

@elbuit - if nothing else works, this should usually work to get the device tree from a running android: https://github.com/hexdump0815/u-boot-misc/tree/master/misc.h616-legacy/android-device-tree-copy
 
best wishes and good luck - hexdump

Hello all,
I would like to have a WIFI/BT working on my X88 Pro 10 box.
If I understand correctly I need two things:
Corect DTB file Driver for specific hardware (directly in kernel or compiled as module) Am I right? Any other important point?
 
I have extracted the DTB from running Android - steps I done:
start the Android on TV box install and configure the SSH Server App (Dropbear) connect to Android via SSH be root (su - device must be rooted, usually already is) find the boot partition (ls -l /dev/block/by-name/) I found this: lrwxrwxrwx 1 root root 21 1970-01-01 01:00 boot -> /dev/block/mmcblk1p11 dump partition to the file boot.img (dd if=/dev/block/mmcblk1p11 of=boot.img) move the boot.img to the PC install extract-dtb python package (pip install extract-dtb) extract DTB from boot.img (extract-dtb boot.img) install device-tree-compiler (apt-get install device-tree-compiler) decompile DTB to DTS (dtc -I dtb -O dts -o x88_pro_10_rk3318.dts 01_dtbdump_rockchip,rk3328-box-liantong.dtb) Some notes.
extracted DTB is quite big:
# extract-dtb boot.img Dumped 00_kernel, start=0 end=19752960 Dumped 01_dtbdump_rockchip,rk3328-box-liantong.dtb, start=19752960 end=33554432 Extracted 1 appended dtbs + kernel to dtb # ls -l dtb/ total 32772 -rw-r--r-- 1 root root 19752960 apr 11 16:07 00_kernel -rw-r--r-- 1 root root 13801472 apr 11 16:07 01_dtbdump_rockchip,rk3328-box-liantong.dtb  
It was decompiled successfully but some warning reported (not sure if this is important):
 
# dtc -I dtb -O dts -o x88_pro_10_rk3318.dts 01_dtbdump_rockchip,rk3328-box-liantong.dtb x88_pro_10_rk3318.dts: Warning (unit_address_vs_reg): /usb@ff600000: node has a unit name, but no reg property x88_pro_10_rk3318.dts: Warning (unit_address_vs_reg): /regulators/regulator@0: node has a unit name, but no reg property x88_pro_10_rk3318.dts: Warning (unit_address_vs_reg): /regulators/regulator@1: node has a unit name, but no reg property x88_pro_10_rk3318.dts: Warning (unit_address_format): /reserved-memory/drm-logo@00000000: unit name should not have leading 0s x88_pro_10_rk3318.dts: Warning (simple_bus_reg): /regulators/regulator@0: missing or empty reg/ranges property x88_pro_10_rk3318.dts: Warning (simple_bus_reg): /regulators/regulator@1: missing or empty reg/ranges property x88_pro_10_rk3318.dts: Warning (avoid_unnecessary_addr_size): /syscon@ff100000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property x88_pro_10_rk3318.dts: Warning (avoid_unnecessary_addr_size): /regulators: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property x88_pro_10_rk3318.dts: Warning (graph_child_address): /hdmi@ff3c0000/ports/port: graph node has single child node 'endpoint@0', #address-cells/#size-cells are not necessary x88_pro_10_rk3318.dts: Warning (graph_child_address): /tve@ff373e00/ports/port: graph node has single child node 'endpoint@0', #address-cells/#size-cells are not necessary  
Then I compiled it back and tried to use with armian but TV box was not booting.
I was trying to use also original extracted DTB without decompile/compile with the same result.
 
What I am doing wrong? Should be DTB compiled on armbian?
Any changes required in DTS? (This is new area for me... )
 
Thanks in advance for any help.

@lucky62 The key mapping is stored in the kernel, and ir-keytable is a tool to test but also store the key mappings in the kernel, It also allows you to retrieve and restore the whole mapping table at once.
You should use ir-keytable to do the mapping, then retrieve the whole table from the kernel and save it in a file, then restore the table in the kernel on every reboot.

Thanks for directing me to the right way.
At first attempt the ir-keytable -t was not working. I was trying to use the different protocols according the LibreElec Infra-Red Remotes page but I was getting the errors:
# ir-keytable -p nec -t Protocols for device can not be changed Protocols changed to Testing events. Please, press CTRL-C to abort. Then I read few other web pages and looking into /etc/rc_maps.cfg and found, that my IR device is not the first (rc0):
 
# ir-keytable Found /sys/class/rc/rc1/ (/dev/input/event2) with: Name: gpio_ir_recv Driver: gpio_ir_recv, table: rc-empty LIRC device: /dev/lirc0 Attached BPF protocols: Operation not supported Supported kernel protocols: other lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp imon Enabled kernel protocols: lirc bus: 25, vendor/product: 0001:0001, version: 0x0100 Repeat delay = 500 ms, repeat period = 125 ms Found /sys/class/rc/rc0/ (/dev/input/event1) with: Name: dw_hdmi Driver: cec, table: rc-cec Supported kernel protocols: cec Enabled kernel protocols: cec bus: 30, vendor/product: 0000:0000, version: 0x0001 Repeat delay = 0 ms, repeat period = 125 ms  
So I must start the ir-keytable with  -s rc1 parameter then finally got it working:
# ir-keytable -s rc1 -p nec -t Protocols changed to nec Testing events. Please, press CTRL-C to abort. 3009.632067: lirc protocol(necx): scancode = 0xdf0c 3009.632120: event type EV_MSC(0x04): scancode = 0xdf0c 3009.632120: event type EV_SYN(0x00). 3009.684073: lirc protocol(necx): scancode = 0xdf0c repeat 3009.684129: event type EV_MSC(0x04): scancode = 0xdf0c 3009.684129: event type EV_SYN(0x00). 3009.792069: lirc protocol(necx): scancode = 0xdf0c repeat 3009.792121: event type EV_MSC(0x04): scancode = 0xdf0c 3009.792121: event type EV_SYN(0x00).  
So last point is to find the correct key mapping and make the settings persistent.
 

@lucky62
The legacy rockchip kernel (the Android one) uses a special driver from rockchip to handle the infrared module, but the mainline kernel uses the standard gpio-ir-receiver driver, which is already in the dtb: https://github.com/paolosabatino/armbian-build/blob/0a7db86c08d77e73c3fba97487d66defa36768ce/patch/kernel/archive/rockchip64-5.10/board-tvbox-rk3318.patch#L199
 
Also the gpio pin of the ir receiver is correcly configured in the armbian dtb, so it should work. I remember I tested on my board and the hardware layer was working.
Maybe you need instead to configure the remote keymapping. For that use you can ir-keyable utility, in particular, ir-keytable -t should help you test the remote. Usually box remotes use the NEC protocol. In the device tree I can also add a "default" keymapping, but actually I forgot to provide one of that and should recompile the image. Tomorrow I will take a look to this too. In the meantime, if you can report that the remote keystrokes are detected by ir-keytable -t may just confirm that the hardware works.

Firstly - to receive the messages from the board you need only 2 wires:
Ground of Serial port on PC -------> Ground of TV Box RX (input) pin of Serial port -------> TX (output) pin of TV Box You don't need to send the data from PC to the TV Box (at this moment).
 
I think it is clear how to connect the ground wire.
Then unclear point is only - where to connect RX pin of Serial port.
But there is only few pads and try to all in combination of  two baud-rates (115200 and 1500000) should not take much time...
 
Note: Just be sure that you are probing the RECEIVING pin. I have this adapter and surprisingly the pin labels are misleading... RX is the transmitting pin. RX means that this pin should be connected to the RX pin on the other side...
Similar for TX - it is a receiving pin.
 
 
 

good news, today I succesfuly compiled the openvfd driver.
This is my DT Overlay:
/dts-v1/; /plugin/; / { fragment@0 { target-path = "/"; __overlay__ { openvfd { compatible = "open,vfd"; dev_name = "openvfd"; openvfd_gpio_clk = <&gpio2 0x13 0x00>; openvfd_gpio_dat = <&gpio2 0x16 0x00>; openvfd_gpio_stb = <&gpio2 0x12 0x00>; openvfd_chars = [04 00 01 02 03]; openvfd_dot_bits = [00 01 02 03 04 05 06]; openvfd_display_type = <0x03>; status = "okay"; }; }; }; }; Driver is working without any changes.
 

Ok, I've installed updated image from first post:
Armbian 21.08 - Ubuntu Focal desktop [xfce] - mainline kernel 5.10.34 - Build date: 2021-05-05 Burned to emmc with multitool, and it works, connected to wifi without issues. Logs from this kernel: http://ix.io/3njG
After the first reboot it had a problem with starting X (restart loop). Solved it with connecting via ssh, and:
sudo apt update sudo apt-get install lightdm > ... > Preparing to unpack .../lightdm_1.30.0-0ubuntu4~20.04.1_arm64.deb ... > Unpacking lightdm (1.30.0-0ubuntu4~20.04.1) over (1.30.0-0ubuntu3.1) ... > Setting up lightdm (1.30.0-0ubuntu4~20.04.1) ... > ... I noticed one problem with apt - it is very slow, not while downloading, but later, it takes minutes while "Reading package list ..., Building dependency tree .. " etc.
 

Hello all nice people, let me do this post since I repute it very important.
There is a lot of people actively deploying things on rk 322x and rk 3318, some  media oriented things ( libreelec, kodi ) some desktop and servers applications.
Now.......it happens that @jock and my self are actively working on those two platforms because I was so lucky in the past to buy for really few bucks ( and i say FEW )  more than 50 different boards reputed faulty, and there were not, just wrong firmware.
But in this big STOCK of boards mostly were 322x ( 3228 3228a 3229 ) and ONLY ONE was 3318,and again I repeat just ONE 3318
 
So it happens that quite EVERY  question on 322x we can answer with sufficient level of accurancy, but on 3318 our experience is limited on HK1,  that is a circle box without display.
Every single help, every single uart log, bootlog any elselog is a mine of infos for us, in particular @jock , but at the same time is really hard provide you a satisfactory answer without debug info, our crystal ball is actually broken

Help us to help you providing as much infos possible and not just saying " it doesn't boot" because in that way is a hard stuff to solve.

Thanks

 

@Tucano2000

 
This is a very aggressive way to find the exact  clock-pin of emmc and also very DANGEROUS. Luckly throught 1k resistor the current will be quite low, but the possibility to destroy some cmos part is still HIGH. The only way to be sure that you managing the righ emmc clock point is discovering it  with an OSCILLOSCOPE , as I did the very first time i managed to find on my board, but again unfortunately my board is different from yours !!!!!!!

And as @jock already said , is needed more debug informations. Without a UART log we are pretty blind and also trying to help you is at the moment hard because lack of infos ( wrong ddrbin ? wrong trust-os?? wrong u-boot??? )

A couple of days have passed since my last post, and i must say, congrats @jock on your awesome work.
The build is running smoothly without any hiccups or other noteworthy bugs. After optimizing my Kivy app a bit more, the whole interface runs at a steady 60-120 fps.
I'm currently researching hardware accelerated video encoding to make the whole show complete (but, as you may have guessed, i know nothing about).
I've read about the 'Rockchip-linux' github repositories, but it seems like it's waaay out of my league, but i will try to make the best of it as i continue to learn.
 
HDMI audio didn't work right out of the box, you'll have to switch the default ALSA output (since the card gets recognized just fine)
Edit (or create) /etc/asound.conf and insert the following:
defaults.pcm.card 2 defaults.ctl.card 2  
Reboot the box (or restart apps using audio output) and voilà. If that does not work, try searching for your 'HDMI' card using 'aplay --list-devices' and replace the number '2' with the one of your desired output.

Regarding the usage of NodeMCU as a USB-to-Serial adapter - the idea is very simple.
As board contains the USB-to-Serial chip (CH340 or CP2102 or FTD or whatever..) and this chip is connected to the MCU to RX/TX pins, then it is enough to block the MCU (by the ENABLE/RESET signal or by programming the RX/TX pins as input) and connect RX/TX pins to our serial interface (instead of MCU). Pins are usually on the headers so it is easy to connect. You can also use others boards with USB-to Serial chips like Arduino, STM32 blue-pill, etc..)
Here is the link from I learn this:
 

I remember trying the adb method to get the dts, but my developer options did not have "Internet/wifi debugging" checkbox.
 
I found a release of the firmware from geekbuying for a A5X Box and used
https://roc-rk3328-cc.readthedocs.io/en/latest/fw_pack_unpack.html
to unpack the img into smaller img files from update.img
 
then used
https://github.com/PabloCastellano/extract-dtb
to extract the dtb (try on all the smaller img files created from unpacking update.img)
 
and then used dtc to decompile.
 
 

Agree. Getting to the Android .dts took me some time, as many of the proposed procedures did not work for me.
My workflow:
Have Android running on the box, developper mode active. In the settings I had a strangely named checkbox like "Internet debugging", switched on Have Android studio installed Could use adb to connect to the box, even without usb, just via lan/wlan adb root worked out of the box, devices like this one seem to be rooted by default? used adb to download the device-tree directory (have android not at hand now, should not be to hard to find) used dtc to convert It took me some time to realize that dtc can handle device-tree directories (-I fs option, see manual)
 
Starting point for documentation: https://www.kernel.org/doc/Documentation/devicetree/usage-model.txt

@fizban - for me those cheap pcm2704 adapters usually gave much better latency than the other cheap usb audio adapters: https://github.com/hexdump0815/sonaremin/blob/master/images/pcm2704-01.jpg
 
maybe have a look at sfizz as a sampler - it allows to use sfz files (much better than simple sound fonts) of which there are quite a few amazing ones around on the net (quite a few on pianobook for instance):
https://github.com/sfztools/sfizz/
https://github.com/hexdump0815/sfizz-arm-build (my notes on building it on arm)
 
if you want to go a bit furher, you can even run a full modular synth with around 2k avaiable modules (vcvrack) on your qplus - i did builds for h6 tv boxes for an older version - for instance here: https://github.com/hexdump0815/sonaremin/releases/tag/v1.1.6_8 but not yet on the latest improved version https://github.com/hexdump0815/sonaremin-ng ... but for vcvrack you'll have to add a fan to your box as it otherwise will get too hot and throttle the cpu
 
good luck and best wishes - hexdump

@RetroFan90
you are welcome to test every single image jock is assemblying bit I don't think this is the right approach to this CCS case community study on rk3318 and generally on every tvbox and every soc born to do other things in their life ( TVBOX !!!!)

Just reporting " this doesn't work" or " this is lagged" or can you test cpu at 1.3 or 1,8 Ghz is overhealming problem of those @jock ( and me, but I am more the hardware man..) is already informed
Until the whole X system isn't mature , every single piece is on place, every right library is in the right directory I think that we can enjoy the steps every day we are doing together, and what Jock did is so big step that mostly of ourselves can't believe !

At the actual state of the art there is none or few chanches that every thing will work out of the box. Study first the whole picture and then go deep in particular features

But the road is signed !!!

I don't know what requirements Kivy places on the graphics stack, but since Panfrost achieves OpenGL ES 3.1 conformance on Mali-G52, it certainly makes sense to read this to understand what to expect from a lima-driven GPU. I still remember very well times when my GPU only reached almost 2.0 and the performance was quite moderate. With now 3.1 it's a big difference for daily desktop use, although my GPU isn't yet declared fully compliant. But since this is bleeding edge development, at least the current mesa mainline release is required in any case. If not even the main branch to use just implemented extentions. Kernel driver wise everything necessary should already be available and therefor mesa is where you are looking for GPU support improvements.

Working for me on kernel 5.14.5 with ffmpeg https://github.com/jernejsk/FFmpeg/tree/v4l2-request-hwaccel-4.3.2 h264 1600*900 15fps stream from my cams use 17-22% of one CPU about 5% of which is pxfmt conversion because it reduces by that amount without conversion - no further kernel patches and ffmpeg dependencies all installed from default repos. This is awesome I've been wanting this for a while, my use case is Frigate NVR which is currently running on an old intel system with a nvidia gpu doing the decoding. I can now revert my nanopc t4 to the task and save some electricity. 
My ffmpeg command that emulates approximately what Frigate does:
 
ffmpeg  -loglevel warning -hwaccel drm -i rtsp://192.168.50.144:8554/unicast  -pix_fmt yuv420p  -f rawvideo pipe:
 
Many thanks @jernejkwiboo and everyone else who made this possible
 
Now need to find out why get block i/o  errors and corruption on emmc on all 5.13 and 5.14 kernels I have tried, doing testing from sdcard for now.

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.

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/

All bootloaders allows that, just because the bootloader is not involved in.
The kernel driver does the thing: it wasn't there before, hence for performance reason booting at high DRAM frequency was good. Now it the driver is there, so there is no necessity to boot at high DRAM frequency because the driver can do the thing during run-time.
 
You board however has NAND 100%, see clarification on first page.

It says ddr2, but actually works fine with ddr3 too.
BTW, I need to update the rk322x_loader to be more compatible. For example, ddr3 frequency is set to 660 Mhz, but it may cause malfunction on some boards: it is unnecessary nowadays because newer armbian releases (even on mainline kernel!) have the dram memory controller driver to allow run-time and on-demand frequency scaling.
About the "spectek" bootloader: we noticed that some rare boards only like that old bootloader, using the newer rk322x_loader results in lockups and unstability.

@jock
Rare?? 
 
It becames to be the normality this odd behaviour of the loader so is good idea sit on the most compatible and left out the newer boards that need the famous 2t initialisation
 
@Willy Moto
The 2.51 is somehow I call the definitive ERASER 
 
We discovered that old 2.47 +but ALWAYS spectec in name ) is one of the most compatible loader ever.
Stay tuned because exactly in these days jock and me actively discovering more odds behaviour on some boards ( x96 mini e.g.) and trying to solve them. Are you sure your board IS NOT a emcp board instead of emmc or nand ?
 
 
 

If you do not need maximum performance, I recommend paying attention to the new Station P2 and M2 models (these are full-fledged mini PCs). At the moment, there are systems with the Legacy core for them, but the development of support for the main core for the rk35x is very fast. And soon there should be a "monster" with very strong characteristics - RK3588. But if you need the most ready-made solution with the main core right now, I recommend P1\M1 . Just yesterday I tested the work of new versions of KODI with full HW support for playing full-screen video on P1\M1 on the main core (I pay attention not to the Legacy core, but the latest stable 5.10), everything works fine even with 4K. By the way, P1 (RK3399) copes with 720p full-screen video in the Chrome browser without problems , there are not big artifacts in 1080p mode, but with the release (I hope it will be in the coming months) of the new version of FFMPEG and adding its support to browsers, rk33xx (P1\M1) will easily cope with 4k in full-screen browsers.

@gianlucaf
Ciao Gianluca, molti italiani qui

That is because in repository of armbian (  could be or could be not ) your deb doesn't exist!!
I am not very fan of docker and I installed home assistant just once.. and it worked.

But since not really interested in HA I deleted the steps to install docker . Sorry. Have a look for some instruction how to install docker on raspberry and choose the ARMHF architecture, NOT the aarc64

Ican only say to you it worked smooth !