gounthar

There is not really "translation" between android dts to linux dts. Android could be considered a Linux distribution like Ubuntu or Debian.
What you are referring as "android" dts is nothing more than a device tree wrote for a very old Linux kernel (probably 3.10 or 3.14).
As long as things change during time, so the device tree specifications become more standardized and well-defined. Device trees for old kernels (3.10 is very old nowadyas) are very messy and generally harder to read and understand.
 
Device trees describe the hardware equipment of  your board. On the x86 world there is something which was used to be called Plug&Play in the early days: Plug&Play let the devices expose themselves to the operating system, which is able to discover and configure them properly without the user intervention. On ARM side this mechanism does not yet exists (to be precise, something exists, but is not available on SBCs), so to let the hardware being discovered you have to tell the operating system. The device tree does exactly this.
 
All the properties and nodes in the device tree are read back by the kernel and kernel drivers. The "compatible" property tells the kernel which driver needs to be loaded, the driver then reads the node properties to know the resources associated with the device (memory regions, registers, interrupts, dma channels, gpio pins, etc...) and its specific characteristics (for example the clock frequency, FIFO queues, etc...), so it can proceed to initialize and make the device available to the system.
 
Being aware of this and getting back to the original question, there is no magic translation tool, you have to do the hard job of reading the old device tree and translate into the new. Experience and documentation are fundamental (you can find the documentation on the device tree bindings shipped with every linux kernel in Documentation/devicetree/bindings directory). Intuition and general knowledge of how electronic devices work are very helpful for such task.
 
 

I am a bit ashamed of citing myself, but this is a small post I wrote some time ago with some explanations:
 
https://forum.armbian.com/topic/14752-device-tree-translation/?do=findComment&comment=106284
 

some people solve Sudoku, with zero output but train-their-brain. Others fix device tree and get training and output

There is a value called the phandle. 
This value is very much like a unique ID number. As far as I understand it is assigned to each device, however the ID can be anything you want it to be. The phandle is used to link different entries in different locations of the dts/dtb. (like a trace on a pcb). 
 
Now this is where it gets complicated and can get confusing. If your audio or WiFi isn't working it is tempting to take parts of two dtb files and stitch them together. This is not possible because the phandles are arbitrary and can differ from dtb to dtb. 
 
For example your x.dtb might give the audio device the phandle ID of 25, while your y.dtb might give that same phandle to your USB device. If you attempt to stitch them together you might lose both audio and USB.
 
I have a suspicion that a lot of these TV box devices were made by stitching different files together while leaving a lot of bad syntax in the device trees. These dtb files are turning out to be more fun than I thought. 

https://github.com/armbian/build/blob/master/config/sources/armhf.conf#L9
https://github.com/armbian/build/blob/master/lib/configuration.sh#L71-L75
https://github.com/armbian/build/tree/master/patch/u-boot/u-boot-sunxi

Sometimes the syntax of DTS changes (by upstream). That is why adjustments might be necessary.
Next is also drivers in the kernel change and therefore adjustments to the device tree might be necessary as well to fit the intersection with the kernel.

Hello fellow armbianites,
 
It has been put to me that arm based boards require a DTB file because arm works a bit differently than x86.
The difference between an arm and an x86 board, is that x86 is standardised and always has the same form factor.
When you plug in a device into an expansion slot or port on your motherboard the new device announces itself.
All the addresses are known in advance and hence there is no need for a DTB file.
 
On arm on the other hand board design is not standardised. You can design a PCB whichever way you would like and solder any component onto the board that your heart desires.
There is no single way to design an arm PCB. The devices you solder onto the board do not announce themselves. It is therefore important to know the address location of each device and chip that is connected to the arm CPU.
 
This is where the DTB file comes in. Every chip and device that is wired to the CPU is linked in the DTB file.
 
I am trying to modify a DTB file to suit my box. Why is it that I cannot just take the DTB that came with the box and use it for an OS like armbian?
Moreover I have noticed that more recent mainline kernels have now lost audio on one of the ms1 dtb files. Someone has modified a dtb file with a fix for audio.
Why is a modified file needed? The hardware itself hasn't changed, and only the minor kernel revision. The audio chip didn't suddenly grow legs and migrate -1 hexadecimal locations. How can this be explained?

This is the worst choice.

Which nobody recommended to you since its not better then TV box. Its closed corporate controlled hardware and doesn't have an option for reliable storage.

This information is already outdated and does not correspond to the current market situation.
 
Make a mistake, rk3399 now has one of the best support in the main kernel (not to be confused with specific models of SbS or TV boxes, chip support and ready-made device support are not the same).
 
 

For running services with a bit more confidence and just a little more money I strongly suggest you to limit your selection to officially supported boards https://www.armbian.com/download/ (nanopi m4 / rockpi 4 or even NanoPC T4 could be in this range). Even there things are sometimes not perfect, but hardware is usually a class above. Also none of the TV boxes have official Armbian support. In case of troubles, you are limited to "TV boxes" forum only.
 
my 2c

Just to give you a realistic idea of total you may spend. at least $35 to 50 if you shop around  and be patient, possibly up to $70 or more if you just don't want to wait and haggle so much.
 
So aside from the board you buy,

 
 
 
you may want/need any one of these or similiar.. daughter board for the ops slot.
 


 
 
and that oddly hard to find barrel jack adapter pin *top row, last tip on the right)..
 

 
 
 
or if somehow you get lucky and find something like this ops adapter kit, it has ops powered cooling fans, proper voltage/amp for ops device power adapter, and ops daughtercard all contained inside it and each functioned separately when disassembled.
 

 
 
 
 
 
 
 
 
Here is the usb uart I have at the moment. Haven't gotten to use either of them yet so this could take a bit for me to update on the debug logs.
 
 

 
 
 
Would be nice if anyone else wanted to see what else can be done armbian or otherwise with these boards.
 
Am70 and am40 or am50 i can confirm boot to the operating systems all without an expensive smart board.
 
but yes you will need one or two of the things I have listed above to get the hdmi and or power going on them correctly on a normal or touch hdmi display. and a power switch more than likely. i used one off an old dekstop
 

Here are the Armbian bionic images with installed RTSP streamer using H264 HW encoding on Allwinner H3 boards
Orange Pi One
Orange Pi Zero
Images are able to run on any board with Allwinner H3
 
 

Will there be support for the RK3399PRO processor? e.g. for a Rocki pi N10 SBC?

Since 5.9 is ahead I'd suggest to focus on that since this will become next LTS kernel.

Hello again.
I've compiled libva-v4l2-request for actual orangepipc 5.7.15-sunxi #20.08
Works better than 5.4.45, no artifacts in 720p
Patched sources: https://github.com/Sash0k/libva-v4l2-request

Basically yes. Note that kernel patches are only for improvements - fixing decoding issues. At least H264 API should be promoted to stable with kernel 5.10, maybe others too.
 
Any player which uses ffmpeg directly should be able to benefit from those patches. AFAIK mpv needs only one simple patch in order to use this chain. I have no idea about VLC internals so I can't say much about it. About VAAPI - request API (Cedrus implements it for decoding) is similar in terms of requirements and features to VAAPI so Bootlin created simple library to expose it. That way they could use any VAAPI capable player. However, some codec interfaces changed considerably from those times and Bootlin didn't invest any time to update this library, so it's not very useful ATM unless you know how to fix it. I know that some people has still interest in that library so I imagine it will be forked/updated once api stabilizes further.
 
Note that there is one hidden issue. As long as you play video in native size, all is well. If you want to scale it then you might get a lot of dropped frames. Issue here is how you do scaling. It's pretty intense process for CPU so you should avoid that at any cost. Unfortunately, VLC with VAAPI translation library did just that. Second option is to go with GPU. IIUC it was impossible to do with binary drivers due to missing import buffer functions, but with mesa it should work now (didn't try it myself). Note that mali400 may still be limiting factor for some cases. Another approach is to use dedicated HW cores. For example, deinterlace core on H3 can be used for scaling only (with few driver tweaks). Downside of this is that scaling process depends on SoC. This would be different even for Allwinner SoCs (not all SoCs have deinterlacer). Most efficient approach (used in LibreELEC) is to use DRM planes - you instruct display engine how to scale and crop it and where on screen to render it. However, I'm not sure if this can work on X11 at all. Wayland should be able to pull this off IIUC.
 
Disclaimer: I don't care about desktop on ARM boards so I didn't do many experiments in this regard and I don't plan to work on improving desktop experience. LE runs without any desktop on ARM boards. Note that I also don't plan to work on any player except ffmpeg/Kodi combo.

Am I understanding it correctly that it works as follows?
LibreElec patches the kernel to make use of the SoC's VPU. (Some of these patches make their way upstream eventually, but that's a slow process.) It also forks ffmpeg, which is patched to recognise these new kernel features & to make use of them. Kodi then refers to ffmpeg to access them.
What would be necessary for players other than Kodi—mpv or VLC for example—to benefit from this as well? And what is the role of libva, VAAPI, and these other things in this process?

Note that ffmpeg patches for request API are important - without patched ffmpeg, all kernel patches have no meaning. Second important thing is that LibreELEC runs Kodi without X11 for ARM boards - this allows to use display more efficiently. On X11 it would be needed to render video through GPU which is less efficient. Note that I never actually tried that.

Maybe you wanna to share your success by commiting a PR to https://github.com/armbian/build/blob/master/config/kernel/linux-rk3399-legacy.config ?
 

I read carefully user manual and found it
#Dont supports imultaneous HDMI and Screen for HDMI IN Using HDMI IN with HDMI port CONFIG_VIDEO_TC358749XBG=y #CONFIG_ROCKCHIP_DW_MIPI_DSI=y #CONFIG_DRM_PANEL_SIMPLE=y I did so and went to rebuild kernel image  
git clone --depth 1 https://github.com/armbian/build cd build ./compile.sh # in dialog menu # U-boot and kernel packages -> Show a kernel configuration menu before compilation # then in kernel configuration menu use save config -> edit via vi -> laod config ___ ____ _ ____ _ ____________ ___ ___ / _ \| _ \(_) | _ \| |/ /___ /___ // _ \ / _ \ | | | | |_) | | | |_) | ' / |_ \ |_ \ (_) | (_) | | |_| | __/| | | _ <| . \ ___) |__) \__, |\__, | \___/|_| |_| |_| \_\_|\_\____/____/ /_/ /_/ Welcome to Armbian Focal with Linux 4.4.213-rk3399 System load: 0.19 0.14 0.06 Up time: 1 min Memory usage: 3 % of 3809MB IP: 192.168.1.90 CPU temp: 55°C Usage of /: 19% of 15G Last login: Sat Aug 8 18:47:55 2020 from 192.168.1.85 root@orangepi-rk3399:~# v4l2-ctl --list-devices rkisp10_selfpath (platform:rkisp10-000): /dev/video0 /dev/video1 /dev/video2 /dev/video3 root@orangepi-rk3399:~# root@orangepi-rk3399:~# ffmpeg -f v4l2 -list_formats all -i /dev/video0 ffmpeg version 4.2.4-1ubuntu0.1 Copyright (c) 2000-2020 the FFmpeg developers built with gcc 9 (Ubuntu 9.3.0-10ubuntu2) configuration: --prefix=/usr --extra-version=1ubuntu0.1 --toolchain=hardened --libdir=/usr/lib/aarch64-linux-gnu --incdir=/usr/include/aarch64-linux-gnu --arch=arm64 --enable-gpl --disable-stripping --enable-avresample --disable-filter=resample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librsvg --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opencl --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libx264 --enable-shared libavutil 56. 31.100 / 56. 31.100 libavcodec 58. 54.100 / 58. 54.100 libavformat 58. 29.100 / 58. 29.100 libavdevice 58. 8.100 / 58. 8.100 libavfilter 7. 57.100 / 7. 57.100 libavresample 4. 0. 0 / 4. 0. 0 libswscale 5. 5.100 / 5. 5.100 libswresample 3. 5.100 / 3. 5.100 libpostproc 55. 5.100 / 55. 5.100 [video4linux2,v4l2 @ 0x5594189760] Raw : yuyv422 : YUYV 4:2:2 : [video4linux2,v4l2 @ 0x5594189760] Raw : yuyv422 : YUYV 4:2:2 : [video4linux2,v4l2 @ 0x5594189760] Raw : uyvy422 : UYVY 4:2:2 : [video4linux2,v4l2 @ 0x5594189760] Raw : yuv422p : Planar YVU 4:2:2 : [video4linux2,v4l2 @ 0x5594189760] Raw : Unsupported : Y/CbCr 4:2:2 : [video4linux2,v4l2 @ 0x5594189760] Raw : yuv420p : Planar YUV 4:2:0 : [video4linux2,v4l2 @ 0x5594189760] Raw : yuv420p : Planar YUV 4:2:0 : [video4linux2,v4l2 @ 0x5594189760] Raw : yuv420p : Planar YVU 4:2:0 : [video4linux2,v4l2 @ 0x5594189760] Raw : nv12 : Y/CbCr 4:2:0 : [video4linux2,v4l2 @ 0x5594189760] Raw : Unsupported : Y/CrCb 4:2:0 : [video4linux2,v4l2 @ 0x5594189760] Raw : gray : 8-bit Greyscale : [video4linux2,v4l2 @ 0x5594189760] Raw : Unsupported : 16-bit A/XYUV 4-4-4-4 : [video4linux2,v4l2 @ 0x5594189760] Raw : Unsupported : Y/CbCr 4:4:4 : [video4linux2,v4l2 @ 0x5594189760] Compressed: mjpeg : JFIF JPEG : [video4linux2,v4l2 @ 0x5594189760] Raw : rgb565le : 16-bit RGB 5-6-5 : [video4linux2,v4l2 @ 0x5594189760] Raw : bayer_grbg8 : 8-bit Bayer GRGR/BGBG : /dev/video0: Immediate exit requested root@orangepi-rk3399:~# Profit !
 
but it's too early to rejoice ffmpeg and gstreamer  not runing
Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... New clock: GstSystemClock ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Device '/dev/video0' failed during initialization Additional debug info: gstv4l2object.c(3782): gst_v4l2_object_set_format_full (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Call to S_FMT failed for NV12 @ 1920x1080: Bad address Execution ended after 0:00:00.117020985 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline .. Parsing a group of options: input url /dev/video0. Applying option hwaccel (use HW accelerated decoding) with argument vaapi. Applying option f (force format) with argument v4l2. Applying option pix_fmt (set pixel format) with argument nv12. Applying option s (set frame size (WxH or abbreviation)) with argument 1920x1080. Applying option r (set frame rate (Hz value, fraction or abbreviation)) with argument 30. Successfully parsed a group of options. Opening an input file: /dev/video0. [video4linux2,v4l2 @ 0x5595907930] fd:3 capabilities:84200001 [video4linux2,v4l2 @ 0x5595907930] Current input_channel: 0, input_name: tc358749xbg, input_std: 0 /dev/video0: Bad address  

Hi there,
is the RK3399 (OrangePi4) already supported by Armbian?
The manufacturer claims support "Debian 9" but current Armbian is Debian Buster 10 - based.
Anyone tried this board with success?

IMHO is 85 celsius really hot. I don´t also know how a big themalpad could work. Is the heatsink warm when you run?
 
 
Mine have i running really slow and the temperature is arround 32 degrees on normal day with normal load. Full speed about 50 degrees. But i need to say that i have also a heatsink on the CPU from an old Fritzbox router. But even on fullspeed is the fan really quiet and you need to listen very well to here it run. In my opinion is 15 euros a really good deal when i compare with a lot of noisie fans i have. The only problem is that the fan is a little bit bigger than the fan opening of the Geekworm case... So i din´t have the original cover on the case...