Dante4

We need to work a bit on our download page for ROCK Pi 4 boards as I see you used 4B images - and these are the only ones easily accessible on the download page  (CC: @Igor)
 
For current use the images from here: https://dl.armbian.com/rockpi-4c/archive/ - all USB ports should work there.
In legacy they will not work right now. I have it on my TODO list so it is possible that with the next point release all USB ports will work in legacy too.

Probably best to make a dedicated pages since downloads are there, but hidden in the text ... which obviously not everyone reads 

"Images below are for model B. For A (without wireless) can be downloaded here and for C (dual monitor) here."

May I know what reason? Seems a bit drastic to do. Are you sure you need to do this>
 
 
You do realize you can use MIPI-DSI for a monitor? 

glmark2-es2.log
glmark2-es2-offscreen.log

Good to see that you like experimenting. As I said, if you use as a base anything other than Armbian Bionic Default image, results can be unpredictable. I invite you to use the build script to make a proper image, or wait until it is publicly released, if you want to take advantage of all the possibilities of the script.

As promised we prepare a little patch for our RockPi... Since it's a while since we created our branch it makes sense to sync our branch with upstream. with:
git fetch upstream && git merge upstream/master && git push (followed by your username & password to keep the branch updated)
 
 
 
It's not allays that much.. but it's worth to do it before you start with development. according to radxas device tree the RockPI has two configurable LEDs.
https://github.com/radxa/kernel/blob/c26d93d001494bbeec86d62e9954b932f254776c/arch/arm64/boot/dts/rockchip/rockpi-4b-linux.dts#L271-L284
gpio-leds { compatible = "gpio-leds"; user-led1 { gpios=<&gpio3 28 GPIO_ACTIVE_HIGH>; linux,default-trigger="heartbeat"; default-state = "on"; }; user-led2 { gpios=<&gpio3 29 GPIO_ACTIVE_HIGH>; linux,default-trigger="heartbeat"; default-state = "on"; }; If we don't know what we can do with those we can look into documentation:
https://www.kernel.org/doc/Documentation/devicetree/bindings/leds/leds-gpio.txt
and from there:
https://www.kernel.org/doc/Documentation/devicetree/bindings/leds/common.txt
 
you see we've quite some options to set our LEDs. At the moment there's different usage in Armbian but I prefer to have one LED always on, ant the other one in heartbeat (some indication in case the board crashes). We could also set one LED to disk-activity but as an example this should do the job. A bit a more useful name for the nodes could also help who knows which led is which if they're named led1 and led2...
so first make sure we're on the right branch and have create patch properly set nano default-config.conf: (cause we build dev image set EXPERT="yes")
CREATE_PATCHES="yes" # wait that you make changes to uboot a$ BUILD_ALL="no" # cycle through available boards and ma$ # set KERNEL_ONLY to "yes" or "no" to b$ BSPFREEZE="" # freeze armbian packages (u-boot, kern$ INSTALL_HEADERS="" # install kernel headers package LIB_TAG="rockpi_tutorial" # change to "branchname" to use$ CARD_DEVICE="/dev/mmcblk0" # device name /dev/sdx $ EXPERT="yes"  
if we now compile for our board we will be prompted to make changes once for ATF (we don't, our little change has nothing to do with ATF) u-boot (we could.. but heartbeat doesn't make sense here.. we want it once the board is booted fully up) and kernel.
ATF:
[ warn ] Make your changes in this directory: [ /home/chwe/armbian/build/cache/sources/arm-trusted-firmware-rockchip64/rockchip ] [ warn ] Press <Enter> after you are done [ waiting ] [ warn ] No changes found, skipping patch creation u-boot:
[ warn ] Make your changes in this directory: [ /home/chwe/armbian/build/cache/sources/u-boot-rockchip64/rockchip-master ] [ warn ] Press <Enter> after you are done [ waiting ] okay.. it might make sense to fix the RockPi DT in u-boot as well... That's how the DT looks at the moment (armbian/build/cache/sources/u-boot-rockchip64/rockchip-master/arch/arm/dts/rk3399-rockpi4b.dts):
as you can see.. wrong gpios and a naming which is IMO also not satisfying... Let's change it to:
as you can see, we didn't use heartbeat yet (and the gpios are also wrong).. and now for the kernel:
[ warn ] Make your changes in this directory: [ /home/chwe/armbian/build/cache/sources/u-boot-rockchip64/rockchip-master ] [ warn ] Press <Enter> after you are done [ waiting ] /home/chwe/armbian/build/cache/sources/linux-rockchip64/4.20.0-1083-ayufan/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts
keep in mind.. we've to change it in the LED node and the pinctrl node..
 
in build/output/patch we get two patches:
u-boot-rockchip64-dev.patch:
and for the kernel: (kernel-rockchip64-dev.patch)
now let's boot the image.. The green led is bright as hell.. and the red one shows heartbeat..  annoying.. let's change them vice versa and hope that everything was right..
as long as we keep the patches in output without renaming them, they get applied in the next run we build an image.. and the can "edit" them. so it's just change gpios in the DT..
hmm seems that now both LEDs are always on.. so something is wrong here.. either the DT from the BSP kernel isn't correct.. or it doesn't work..
means, we've no idea how to trigger the green LED. But we know how to trigger the RED LED. Now let's write a patch which only triggers the RED LED and erase the other LED node cause we've no clue how to trigger it.
U-boot:
diff --git a/arch/arm/dts/rk3399-rockpi4b.dts b/arch/arm/dts/rk3399-rockpi4b.dts index 5d73ce5..5574e9b 100644 --- a/arch/arm/dts/rk3399-rockpi4b.dts +++ b/arch/arm/dts/rk3399-rockpi4b.dts @@ -65,14 +65,9 @@ status = "okay"; compatible = "gpio-leds"; - power-led { - label = "power"; - gpios = <&gpio0 11 GPIO_ACTIVE_HIGH>; - }; - - standby-led { - label = "standby"; - gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>; + system-status { + label = "status"; + gpios = <&gpio3 28 GPIO_ACTIVE_HIGH>; }; }; Kernel:
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts b/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts index 7f10da2a8..1d4721dcc 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpi4b.dts @@ -140,20 +140,15 @@ }; leds { + status = "okay"; compatible = "gpio-leds"; pinctrl-names = "default"; - pinctrl-0 = <&work_led_gpio>, <&diy_led_gpio>; - - work-led { - label = "work"; - default-state = "on"; - gpios = <&gpio0 RK_PB3 GPIO_ACTIVE_HIGH>; - }; + pinctrl-0 = <&status_led_gpio>; - diy-led { - label = "diy"; - default-state = "off"; - gpios = <&gpio0 RK_PA2 GPIO_ACTIVE_HIGH>; + system-status { + label = "status"; + gpios = <&gpio3 29 GPIO_ACTIVE_HIGH>; + linux,default-trigger = "heartbeat"; }; }; @@ -643,12 +638,8 @@ }; leds { - work_led_gpio: work_led-gpio { - rockchip,pins = <0 RK_PB3 RK_FUNC_GPIO &pcfg_pull_none>; - }; - - diy_led_gpio: diy_led-gpio { - rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>; + status_led_gpio: status_led_gpio { + rockchip,pins = <3 28 RK_FUNC_GPIO &pcfg_pull_none>; }; }; Now since we know that our patch works, let's give it a meaningful name and move it in the correct folder. the patchname makes it easy for you.. and rename it to a meaningful name. (build/patch/kernel/rockchip64-dev & build/patch/u-boot/u-boot-rockchip64-dev). For the beginnings fix-rockpi4b-led.patch sounds ok-ish. We've to check if those new patches apply correctly after moving to the right folder:
uboot:
[ o.k. ] * [l][c] add-board-renegade.patch [ o.k. ] * [l][c] add-board-rockpi4b.patch [ o.k. ] * [l][c] add-missing-SDMMC0_PWR_H-rockpro64.patch [ o.k. ] * [l][c] add-u-boot-delay-rockpro64.patch [ o.k. ] * [l][c] board-renegade-updates.patch [ o.k. ] * [l][c] enable-DT-overlays-support.patch [ o.k. ] * [l][c] fix-rockpi4b-led.patch and kernel:
[ o.k. ] * [l][c] RK3328-enable-1512mhz-opp.patch [ o.k. ] * [l][c] RK3399-enable_1.5_2.0_ghz_cpufreq_opp.patch [ o.k. ] * [l][c] add-board-rockpi4b.patch [ o.k. ] * [l][c] add-fusb30x-driver.patch [ o.k. ] * [l][c] board-rockpi4-dts-wip-fixup.patch [ o.k. ] * [l][c] firefly-rk3399-enable-wifi.patch [ o.k. ] * [l][c] fix-rockpi4b-led.patch [ o.k. ] * [l][c] fix-rockpro64-emmc.patch [ o.k. ] * [l][c] fix-spi1-flash-speed.patch [ o.k. ] * [l][c] general-add-overlay-compilation-support.patch [ o.k. ] * [l][c] general-increasing_DMA_block_memory_allocation_to_2048.patch [ o.k. ] * [l][c] general-packaging-4.17-dev.patch [ o.k. ] * [l][c] general-rockchip-overlays.patch [ o.k. ] * [l][c] nanopi4-dts.patch [ o.k. ] * [l][c] orangepi-rk3399-dts.patch [ o.k. ] * [l][c] renegade-add-HDMI-nodes.patch [ o.k. ] * [l][c] renegade-enable-usb3.patch [ o.k. ] * [l][c] rk3328-sd-drive-level-8ma.patch [ o.k. ] * [l][c] rk3399-sd-drive-level-8ma.patch [ o.k. ] * [l][c] timekeeping32-tweaks-for-4.20.y.patch [ o.k. ] * [l][c] unlock-temperature.patch seems that everything is okay. So it's time to bring them back to armbian. Let's check our repo with git status:
chwe@chwe-HP:~/armbian/build$ git status On branch rockpi_tutorial Your branch is up to date with 'origin/rockpi_tutorial'. Untracked files: (use "git add <file>..." to include in what will be committed) patch/kernel/rockchip64-dev/fix-rockpi4b-led.patch patch/u-boot/u-boot-rockchip64-dev/fix-rockpi4b-led.patch nothing added to commit but untracked files present (use "git add" to track) there are our two new patches.. lets add and commit (with a meaningful commit message) them with: git add -A && git commit followed by git push
chwe@chwe-HP:~/armbian/build$ git push Username for 'https://github.com': chwe17 Password for 'https://chwe17@github.com': Counting objects: 9, done. Delta compression using up to 8 threads. Compressing objects: 100% (9/9), done. Writing objects: 100% (9/9), 1.50 KiB | 1.50 MiB/s, done. Total 9 (delta 5), reused 0 (delta 0) remote: Resolving deltas: 100% (5/5), completed with 4 local objects. To https://github.com/chwe17/build.git a156fddf..bb63ed6d rockpi_tutorial -> rockpi_tutorial https://github.com/chwe17/build/tree/rockpi_tutorial
our features branch is now one commit ahead of armbian master and we can create a PR against armbians master:
https://github.com/armbian/build/pull/1236
 
You see, just adding something simple like triggering an LED to heartbeat can give you some headache.. and takes more time that we expected cause the second LED didn't behave as we thought. But finally, we got it.
 
Edit: this post was written 'on the fly'.. If something isn't clear, just let me know.. and I'll try to explain it better.
Edit2: cause 'we know' that @TonyMac32 does a lot with RK boards we request him as reviewer.

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!

Talking about config-default.conf and a bit of my workflow (others might do it different and I do boardbring up, kernel-patching by accident not by training - I normally do in science not in computes stuff ) for patching today:
actually the first line describes everything you need here... just read the docs and you'll get most of the things well described. For simplicity we use the menu which opens by starting the script with sudo ./compile.sh without any additional flags (docs explain also how to do it with flags but that not really needed, it's just faster than searching your board in the menu.
LIB_TAG becomes important cause it defines on which branch you build images (e.g. normally you do it on master when you just want to build the newest image for your board with armbians settings - as a developer who doesn't commit directly into armbians master, the workflow differs a bit and other branches than master become more important).
 
I assume that you've a GitHub account and already forked the project online. If you look at my masters tree (https://github.com/chwe17/build) it's mostly a few commits behind armbians masters tree (depends when I last synced my master with armbians - github explains perfectly how to sync a fork and how to add another remote) but it's never commits ahead of armbians master I do want to have the same git history in master as armbian has it just makes things simpler (git merge will always works without issues ).. On my current buildmachine I cloned directly my fork for building and not armbians. In case you have cloned the original and you don't want to loose all your stuff in cache (e.g. compilers which just need a bunch of time) you'll have to delete the remotes and set origin to your fork (google will help you on this one) and upstream to https://github.com/armbian/build.git (or dealing everytime with the proper commands when push stuff online - if you're not a git-ninja  just set origin to your fork and upstream to armbians). Example:
chwe@chwe-HP:~/armbian/build$ git remote -v origin https://github.com/chwe17/build.git (fetch) origin https://github.com/chwe17/build.git (push) upstream https://github.com/armbian/build.git (fetch) upstream https://github.com/armbian/build.git (push)  
First make sure that (at least) your local master branch is synced with armbians (due to set origin to your fork, this doesn't happen automatically during build! it will only sync it with your fork which is quite sure some commits behind armbians):
check on which branch you are. We will do all the development in features branches not in master! So you might be on a different one from your last build: chwe@chwe-HP:~/armbian/build$ git branch * master mt7623 r2_gmac  
 in this case everything is fine but it happened quite often in the beginnings that I was on one of my features branches which then ended in a mess (I've some features branches which have a lot of changes compared to armbians master)... if you're on a features branch make sure you've a clean working tree before you switch. git status can help you here to ensure your tree is clean. Example for a clean one: chwe@chwe-HP:~/armbian/build$ git status On branch mt7623 Your branch is up to date with 'origin/mt7623'. nothing to commit, working tree clean or a dirty one:
chwe@chwe-HP:~/armbian/build$ git status On branch mt7623 Your branch is up to date with 'origin/mt7623'. Untracked files: (use "git add <file>..." to include in what will be committed) some_random_fancy_shit_i_did_in_my_features_branch.txt nothing added to commit but untracked files present (use "git add" to track) (either with git stash or git add -A && git commit see git manuals what might be appropriate here - I prefer often to commit stuff if it's (partly) working and stash only when I'm quite sure I'll switch back to the features branch soon, commit messages can help you sometimes if you don't remember the rational behind a changes you did a few weeks back on features which need a bit more time to develop ISP1 driver on rk3288 was a feature I tried over weeks and failed more than once - btw. got never merged into master for good reasons). If the tree is clean switch to master with git checkout master!
now we sync our master with armbians master (and push it online to our fork as well, example in spoiler):
git fetch upstream git merge upstream/master git push if you visit your fork online this should be visible: This branch is even with armbian:master.
Let's create a features branch for our funny new feature locally and on remote (git checkout -b branchname && git push -u origin rockpi_tutorial):
chwe@chwe-HP:~/armbian/build$ git checkout -b rockpi_tutorial Switched to a new branch 'rockpi_tutorial' chwe@chwe-HP:~/armbian/build$ git push -u origin rockpi_tutorial Username for 'https://github.com': chwe17 Password for 'https://chwe17@github.com': Total 0 (delta 0), reused 0 (delta 0) remote: remote: Create a pull request for 'rockpi_tutorial' on GitHub by visiting: remote: https://github.com/chwe17/build/pull/new/rockpi_tutorial remote: To https://github.com/chwe17/build.git * [new branch] rockpi_tutorial -> rockpi_tutorial Branch 'rockpi_tutorial' set up to track remote branch 'rockpi_tutorial' from 'origin'. now config-default.conf and especially LIB_TAG becomes important. We tell the build-script now that by default we want to build images on our new features branch. So change LIB_TAG="master" to LIB_TAG="rockpi_tutorial" with your favorite editor. Cause we go to create a patch, change it to yes as well CREATE_PATCHES="yes".
In the next days I'll have a look if there's an easy but meaningful example of patching something for RockPi including the pull request to bring it back to armbian. I'm quite confident we'll find something in the device tree to fix...
 
The reason I work with features branches is quite simple.. In case my random ponny feature doesn't make it in the pull request (maybe the change isn't that smart or it breaks something I didn't consider) and therefore doesn't get merged into armbians masters I simply can delete my branch or let it collect dust but I don't have to do anything in my masters branch (e.g. 'rewrite' the git history to have it even with armbians for my next features branch which is hopefully better than the one which didn't make it - it's just painful to clean up a messed up masters to get it back to the githistory of armbians - believe me, I did it more than once when I wasn't that familiar with git - as said in the starter, we all didn't start as git-kernel-u-boot-userspace ninjas ). On a features branch this doesn't happen. delete it or let it collect dust once you don't need it anymore. 

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.

As most of us were in the beginnings..
 
I don't guarantee but I think it's not that easy to fry something with a wrong devicetree.. It's a way easier with connecting random crap to the pin-header.
 
Since you want to get closer to group 1 let's give an example:
 
That's the original DT for the RockPi4b (4.4.x kernel) spoiler cause it just messes up to show the whole one for everyone (https://github.com/radxa/kernel/blob/release-4.4-rockpi4/arch/arm64/boot/dts/rockchip/rockpi-4b-linux.dts):
 
the first few lines after comment tell us which other DT files are included here e.g. (rk3399.dtsi):
#include <dt-bindings/pwm/pwm.h> #include <dt-bindings/input/input.h> #include "rk3399.dtsi" #include "rk3399-linux.dtsi" #include "rk3399-opp.dtsi" basically just another 'layer' of describing hardware, since a lot of stuff is shared with all rk3399 based boards this stuff is usually described once there and the nodes are used again and again for every board.
 
The nodes after it describe the hardware and how it is connected (also partly software e.g. there are multiple UARTs available, a node has to tell the kernel which one should be used to output the debug console).
 
Now let's look at such a node:
fiq_debugger: fiq-debugger { compatible = "rockchip,fiq-debugger"; rockchip,serial-id = <2>; rockchip,signal-irq = <182>; rockchip,wake-irq = <0>; rockchip,irq-mode-enable = <1>; /* If enable uart uses irq instead of fiq */ rockchip,baudrate = <1500000>; /* Only 115200 and 1500000 */ pinctrl-names = "default"; pinctrl-0 = <&uart2c_xfer>; }; the compatible part is the first one which is interesting cause it gives you some hints where you get further information. (https://github.com/radxa/kernel/blob/release-4.4-rockpi4/Documentation/devicetree/bindings/serial/rockchip_fiq_debugger.txt)
From there you get most of the information out what this node does and how it can be configured.. E.g. for the fiq node, it could be worth to set baudrate to 115200 cause this is the common baudrate for all SBCs (except rockchips which often favor higher baudrates for whatever reasons ). So obviously when you connect an USB-UART you've to set it to 1500000 not the default 115200 (keep in mind, if it's patched in the kernel, it should also be patched in u-boot, otherwise things get messy).
 
That's just a short introduction and you've to read a lot of stuff until all this stuff makes sense. Maybe I write something about the buildsystem tomorrow.

you can start with testing: https://github.com/armbian/testings
maybe not yet for the RockPi 4b but for other boards you have?
 
google is a good helper which I quite often use.
 
If you want to dive into this it might be worth to start with some basics in device tree. The kernel comes with docs, docs are great to understand what a *random devicetree node* does. Combine this stuff try to build images, get errors on building or that the DT doesn't work, use google (or ask here), build again and learn step by step.
 
You need a virtual machine with ubuntu on it and some spare-time. You may file a few times until you get something working but that's fine. Happens to all of us.

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.

Correct, there is no way to use windowed accelerated mpv. Gstreamer uses a hack to simulate X11 windowed playing.

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

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

I'm not sure about ayufan's mpv version. I can tell you that I am working on a script for Armbian that has RKMPP enabled mpv. The proper way to start mpv with hardware decoding is like this:
LD_LIBRARY_PATH=/path/to/your/libmali-gbm mpv --hwdec=rkmpp --vo=gpu --gpu-api=opengl --gpu-context=drm "<filename.mkv>" It works with my mpv, not sure about ayufan's

You can have a look at my script when I release it. It includes info about the sources.

Heatsink and M.2 Expander Board are out. You can buy them here https://shop.allnetchina.cn/collections/rock-pi-4-accessories?page=2

You can copy-paste this code into a root console, and it will give you a Qt5 player using the RK GStreamer plugin:
apt-get -y install qtgstreamer-plugins-qt5 gstreamer1.0-plugins-bad gstreamer1.0-plugins-ugly gstreamer1.0-plugins-good gstreamer1.0-plugins-base libqt5opengl5 libqt5qml5 libqt5quick5 libqt5widgets5 libqt5gui5 libqt5core5a qml-module-qtquick2 libqt5multimedia5 libqt5multimedia5-plugins libqt5multimediaquick-p5 qtmultimedia5-examples qtmultimedia5-doc-html echo '#!/usr/bin/env xdg-open [Desktop Entry] Type=Application Name=Rockchip Gst Player GenericName=Media Player Comment=A gstreamer base player Exec=env QT_GSTREAMER_WIDGET_VIDEOSINK=rkximagesink /usr/lib/aarch64-linux-gnu/qt5/examples/multimediawidgets/player/player --geometry 960x640+0+0 Icon=/usr/share/icons/gnome/48x48/categories/applications-multimedia.png Terminal=false Categories=Qt;AudioVideo;Player;Video; MimeType=application/ogg;application/x-ogg;application/mxf;application/sdp;application/smil;application/x-smil;application/streamingmedia;application/x-streamingmedia;application/vnd.rn-realmedia;application/vnd.rn-realmedia-vbr;audio/aac;audio/x-aac;audio/vnd.dolby.heaac.1;audio/vnd.dolby.heaac.2;audio/aiff;audio/x-aiff;audio/m4a;audio/x-m4a;application/x-extension-m4a;audio/mp1;audio/x-mp1;audio/mp2;audio/x-mp2;audio/mp3;audio/x-mp3;audio/mpeg;audio/mpeg2;audio/mpeg3;audio/mpegurl;audio/x-mpegurl;audio/mpg;audio/x-mpg;audio/rn-mpeg;audio/musepack;audio/x-musepack;audio/ogg;audio/scpls;audio/x-scpls;audio/vnd.rn-realaudio;audio/wav;audio/x-pn-wav;audio/x-pn-windows-pcm;audio/x-realaudio;audio/x-pn-realaudio;audio/x-ms-wma;audio/x-pls;audio/x-wav;video/mpeg;video/x-mpeg2;video/x-mpeg3;video/mp4v-es;video/x-m4v;video/mp4;application/x-extension-mp4;video/divx;video/vnd.divx;video/msvideo;video/x-msvideo;video/ogg;video/quicktime;video/vnd.rn-realvideo;video/x-ms-afs;video/x-ms-asf;audio/x-ms-asf;application/vnd.ms-asf;video/x-ms-wmv;video/x-ms-wmx;video/x-ms-wvxvideo;video/x-avi;video/avi;video/x-flic;video/fli;video/x-flc;video/flv;video/x-flv;video/x-theora;video/x-theora+ogg;video/x-matroska;video/mkv;audio/x-matroska;application/x-matroska;video/webm;audio/webm;audio/vorbis;audio/x-vorbis;audio/x-vorbis+ogg;video/x-ogm;video/x-ogm+ogg;application/x-ogm;application/x-ogm-audio;application/x-ogm-video;application/x-shorten;audio/x-shorten;audio/x-ape;audio/x-wavpack;audio/x-tta;audio/AMR;audio/ac3;audio/eac3;audio/amr-wb;video/mp2t;audio/flac;audio/mp4;application/x-mpegurl;video/vnd.mpegurl;application/vnd.apple.mpegurl;audio/x-pn-au;video/3gp;video/3gpp;video/3gpp2;audio/3gpp;audio/3gpp2;video/dv;audio/dv;audio/opus;audio/vnd.dts;audio/vnd.dts.hd;audio/x-adpcm;application/x-cue;audio/m3u; ' > /usr/share/applications/demo-player.desktop  

Libreelec has some patches to libdrm for 10-bit formats: https://github.com/LibreELEC/LibreELEC.tv/tree/master/projects/Rockchip/patches/libdrm

No, it is not obvious. I knew it because I had to deal with the LibreElec source tree when I was preparing the RK-enabled Kodi for the Tinker Board . RK used to have their own version of libdrm, but for some reason they discontinued the project. ASUS TinkerOS still included the library as of version 2.0.5, not sure if it is present in last release.