chwe

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.

Thanks boss

They are hidden if there is nothing new in them. This can be set per forum.
 
Probably. I'll try.
 
It's already enabled in Technical support section. Auto-lock will follow - i did testing in recycle bin and it seems to work properly.

I'm not a fan of this idea.. For sure it would reduce the support 'pressure'.. But I think it may also scare away the good people..
 
most of the support questions can be solved with google *fill in your preferred search engine*.. maybe we should encourage people more to use it.
tags could make sense.. e.g. in the sunxi.. where people must decide between H3/H5/H6 flag them with different colors and make H6 red..
this would simplify things a bit..
 
can we enforce an other input field where they've to post their armbianmonitor link? at least for those opening a thread.:D
 

There's a few problems with the UART driver on 5.0-rc2 kernels, since proper checks are not done correctly and lead to a Null Pointer dereference.
 
Here's a patch to avoid this issue :
 
From 7e43ae8446b420907f00b43308ad0b99b6fe4e51 Mon Sep 17 00:00:00 2001 From: "Miouyouyou (Myy)" <myy@miouyouyou.fr> Date: Wed, 16 Jan 2019 23:58:52 +0100 Subject: [PATCH] drivers: tty: serial: Bail out if no UART is detected Before the 5.0, serial8250_register_8250_port consisted of one BIG if(uart && uart->port.type != PORT_8250_CIR) block, which prevented NULL dereference if uart, a pointer to an "uart_8250_port" detected through "serial8250_find_match_or_unused", were to be NULL. However, a recent patch added a few bits of code just after that, and that code manipulates the "uart" pointer without checking if it's NULL or not. This patch changes the mechanism and bail out early if no UART structure pointer is provided serial8250_find_match_or_unused. A goto is used instead of returning directly, since we're inside a mutex and must release it correctly. Signed-off-by: Miouyouyou (Myy) <myy@miouyouyou.fr> --- drivers/tty/serial/8250/8250_core.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c index 189ab1212..11120c2d9 100644 --- a/drivers/tty/serial/8250/8250_core.c +++ b/drivers/tty/serial/8250/8250_core.c @@ -981,7 +981,12 @@ int serial8250_register_8250_port(struct uart_8250_port *up) mutex_lock(&serial_mutex); uart = serial8250_find_match_or_unused(&up->port); - if (uart && uart->port.type != PORT_8250_CIR) { + if (!uart) { + printk(KERN_INFO "One UART port failed to register correctly\n"); + goto no_uart; + } + + if (uart->port.type != PORT_8250_CIR) { if (uart->port.dev) uart_remove_one_port(&serial8250_reg, &uart->port); @@ -1081,6 +1086,7 @@ int serial8250_register_8250_port(struct uart_8250_port *up) uart->overrun_backoff_time_ms = 0; } +no_uart: mutex_unlock(&serial_mutex); return ret; -- 2.16.4  

The questions which come up in the 'development' forum are anyway more like the average 'supportquestions' there's not much a difference... IMO development was never used the way it was supposed to be used..

could we 'switch' the behavior as well? E.g. default is mainline kernel and subforum is outdated 3.4 kernel which is only available for H3 anyway? Some kind force that people should move to mainline..

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.

Tinkerboard "Next" Stretch and Bionic images available for download using kernel 4.19.
 
Notable changes include the use of device tree overlays.

Looks like we got an upstream DT for the T4: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm64/boot/dts/rockchip?id=e7a095908227fb3ccc86d001d9e13c9ae2bef8e6

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.

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.

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.

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.

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.

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.

yes and there are good reasons for it.
Linus salary is also partly paid by Microsoft... https://www.linuxfoundation.org/membership/members/
 
it's never too late..   for sure you'll find something else to contribute.

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.

well we have what you would call a militia parliament.. It's not always that they understand stuff better.. But hey.. data is the new oil.. we might need a few exxon valdez'es or deep water horizons to figure out how this new oil is handled safely..
some other bad jokes..
we don't understand it fully yet but let's build up a cartel (that's some years ago for the real oil)... wherever the pipeline goes.. someone is upset once it's in the environment it needs years until it disappears.. seems that this 'dataset' also contains information of their kids (account-names etc.), maybe this helps them a bit to understand the issue better...
 

 
feeling like grandpa simpson

With the SDIO changes for better strength done by @TonyMac32, it seems that the laggyness is gone !

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.

official lede from sinovoip still uses 4.9, but there is imho also a dsa-driver (backported from 4.1x afair),
there is openwrt with 4.14 which includes Patches for bpi-r2 (where i've got my Patches for second gmac).
 
if you have a dsa-driver (you see interfaces wan,lan0-lan3) you cannot work on eth0/eth1 (these are only the ethernet-connections between switch [mt7530] and SOC/Main-CPU [mt7623]), only bring them up...ip-config has to be done on dsa-interfaces.