chwe

merged both.. it's more or less the same.. @Igor might be related to recent changes?

Approving happens as soon as I unhide your post... It's just one spam protection more. For the rest... On which topic you tried to answer?

let's hope you guys don't have to repeat this often otherwise the pad might be gone..

it should be addressed public cause it is a public issue.. I prefer to have it this way. For sure there are topics which are dicussed in a more 'private' space but this is one which affects users & maintainers and IMO it's important.. the site/forum is just a 'side-product' of https://github.com/armbian if the side-product now takes too much time.. the main 'product' - providing a stable reliable OS for arm SBCs, get worse. Means 'the great community' isn't as attractive anymore cause images constantly break. IMO the only rational behind 'stricter' forum-rules must be that it reduces the time for those who answer to the topics to find a solution. If a new forum-rule or tool doesn't fulfill this, drop it. If it helps to reduce time for support (and doesn't make support worse) keep it.

As those doing in science know, Elsevier journals tend to be rather expensive (so for example Tetrahedron, one in my field has an annual subscription fee of ~14k $ for print - keep in mind, normally you read through ~10-50 different journals of your field to get a broad overview of what happens, doesn't mean that you read everything of them it's more like cherry-picking the hopefully good commits) but also often qualitative... Since years libraries and universities complain about those fees but Elsevier didn't really listen to them... This might change in the future cause more and more universities just drop the journal fully or partly (means that they try to publish their results elsewhere, don't provide free peer-review to their journals anymore and don't buy those unlimited access contracts anymore). Nevertheless even journal editors now leave elsevier to found a competitive journal which will be open access.. https://www.insidehighered.com/news/2019/01/14/elsevier-journal-editors-resign-start-rival-open-access-journal

not really.. A tinkerboard is able to do the job.. could be network card.. could be network cable.. for example the BPi R2 drops to 100mb/s with a bad cable (but even with good cables it isn't able to deliver the claimed GbE.. ) Well that's the tools issue not yours. As long as you get what you need it isn't much an issue. Unfortunately more and more websites start to bloat you with multimegabyte javascript garbage when you open them which is annoying.. I start to like pure static HTML websites..

I think that was never the intention that 'armbian people' only answer to questions.. fist cause there are for sure other smart(er) people here and their contributions are highly appreciated. Personally I wouldn't participate in such an sub-forum. But I don't spend as much time in armbian when my 'dayjob' doesn't allow it. By paying for support people expect solutions, solutions aren't that easy. If *random hardware feature* doesn't work the pressure should be on the boardvendors side to fix it not on ours. For maintainers spending much more time to keep the project running (e.g. Igor) some sort of a salary might be mandatory and ways to make this possible isn't as easy but I don't think that such a payed supportforum is the way to go. This can also mean that even more radical approach is needed? There will always be people who will ignore everything. how about a less radical approach. Just ignore topics which don't provide the needed information? Those really interested in getting their issue heard/solved may get it that there's information missing. challenge accepted. (we shouldn't lose our sense of humor even if it's a dark one ) Besides that, I'm fine with stupid questions. Even in the field I'm good in (chemistry) I sometimes have stupid questions.. Happens.. but the way you react when you realize that you asked a stupid question makes the difference.. If you start to complain about support and and come up with "but the users are most important" I'll answer you with a polite form of "Go fu... *have sex with yourself*"... If you look at a forum from an SBC armbian doesn't support you'll see that moderators there have some sort of a scheme for questions they don't want to answer - always ends with: believe us we sold 20 millions boards we know what we're doing.. We've to accept that there are people on forums which don't spend as much time on SBCs to get trivial issues solved on the other side, they've to accept that if they're not willing to invest time to fix things on their own/help us figuring out what's wrong, I'm not willing to waste my time with their issues. The first iteration of the new mandatory parts for opening a topic in technical support was a failure: the new version with: is at least not as harsh anymore.. but as @zador.blood.stained and @martinayotte showed (https://forum.armbian.com/topic/9400-does-not-see-emmc-after-component-change/) here, there's still room for improvement. Maybe it needs some days/weeks/months until we have a solution which is "more or less" satisfying but I still think setting some pressure to people to provide armbianmonitor in their starter isn't a bad thing. Cause it is annoying to ask always for it and hope that he gets it after you asked for it 10 times.. (and it's also annoying to find different polite forms of the part from the "personal non rational rant" ) For me this thread should be merged with "Improve 'Support over Forum' situation" - IMO it belongs to it. If nobody disagrees on that let's move it there.

Updated with wanted list: at least not as a board maintainer.. But anyway.. I don't plan to maintain a board in the next months.. (it's enough to do some CSC work for the R2 and some initial board bring up for the rockpi - and if I still want to trash more time there's a camera driver for rockchip bsp waiting.. )

hopefully not.. I don't think that we ban people for doing something wrong in their first posts.. I think it's related to this one. since @@lex version is newer than debians/ubuntus default it will be picked from our repo. Maybe some of the adjustments only worked for big.LITTLE with 6 core systems? Hope that lex can comment on this one.

Testing download speed................................................................................ Download: 207.35 Mbit/s Testing upload speed...................................................................................................... Upload: 203.69 Mbit/s from my wifi.. my ISP claims it's symmetrical 1000 but even on wired network they mostly can't deliver.. But seriously I don't care..

for whatever reason compiling ATF fails from time to time.. 3.2.1.make -C plat/rockchip/rk3399/drivers/m0 BUILD=/home/chwe/armbian/build/cache/sources/arm-trusted-firmware-rockchip64/rockchip/build/rk3399/debug/m0 make[1]: Entering directory '/home/chwe/armbian/build/cache/sources/arm-trusted-firmware-rockchip64/rockchip/plat/rockchip/rk3399/drivers/m0' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/home/chwe/armbian/build/cache/sources/arm-trusted-firmware-rockchip64/rockchip/plat/rockchip/rk3399/drivers/m0' make: Nothing to be done for 'bl31'. out:trust.bin E: [mergetrust] filter_elf ./build/rk322xh/debug/bl31/bl31.elf file failed merge failed! [ error ] ERROR in function compile_atf [ compilation.sh:83 ] [ error ] ATF file not found [ trust.bin ] [ o.k. ] Process terminated the sources with ATF were still there.. but int fails.. the merge looks like doing it for the wrong soc? someone has a clue? Edit: if you build an image for the rockpro first.. it normally doesn't break..

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.

for whatever reasons pinned threads are hidden and you had to click on them to get they appearing.. are others also affected? I would write armbianmonitor -u . Is it possible to combine it with a checkbox (can't provide armbianmonitor) and make one of them mandatory? some slight force to fill it in..

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

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..

my UART script which does some funny monitoring in case the SBC doesn't respond anymore wouldn't need a $BAUDRATE variable anymore.... The only gain IMO is that all other armbian supported SBCs run (to my knowledge) at 115200... But as said.. Don't think it's really worth it..

didn't saw any progress in the last days.. So not sure that they really prepare a PR. In case yes.. they should sync first with the current stage..

no.. It could probably set to 115200 in DT. but then it had to be changed in u-boot as well.. and to keep stuff in a proper order.. for all RK3399 boards.. Is it worth to write a whole patchseries just for such a change.. I thought about it but I'm not sure..

I think official support for the BBB is still unlikely. I think the basics for letting it boot with 'Armbian' (e.g. adding the new boardfamily, and some random linux config for it and the boardconfig file) could be done within a weekend. But improve it over time.. test and fix stuff, search for patches which aren't mainlined but do help a lot integrate (test again) and maintain them is the hard work which takes a lot of time. If people are interested in bringing up the beagle bone on armbian I (we) can for sure give you some guidance how things work here.. e.g. go through those threads may help: and after deep sea for sure it would be fun to see Armbian in space as well (we then would need a new extreme where our images on *random SBC* do serious work - someone plans to fly to mars? ).. IMO supporting a board only for one project may be not worth for Armbian as project - but helping such a project to get Armbian flying on their board might be. I would agree that the beagles might be relevant when it comes to 'serious projects' where failure of random hardware components have a big impact. Still believe that TI understands the difference between a industrial grade component and an industrial grade SBC. In terms of long time availability I would assume that beagles are also better than most boards (you can still buy the beagleboard xM - I think mine is now something like 10 years old..).

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.

seems to be 'very simple' patches for upstream u-boot are there, and recent kernels as well (maybe it could be worth to compare them with upstream).. So building images built by armbians buildscript doesn't look that hard. Getting them officially into our build-script on the other hand will be harder (we try to reduce workload - there must be good reasons for a new soc family).

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.