Search the Community

For which OS? I have a Rock64 V2 running 24/7 Ubuntu Bionic with kernel 4.4.192 (Armbian Bionic 5.98), which I have recompiled myself to add back a driver, and it seems pretty stable as of now. With the previous versions I used to have some sporadic zram0 errors, but it's now two days of uptime since my last reboot and I haven't seem them.

Anyone has a reliable kernel version for the rock64? Any I have tried are kernel panicking like crazy I cannot have it up longer than a few minutes. The most stable kernel I have 4.4.133 but even that does intermittently during (heavy) IO on the USB3. Power is supplied through the power supply from pine.org so that should be good. This is driving me crazy!

Done! ayufan rock64 linux and armbian build pull requests As written in the pull request for armbian, once (and if) ayufan will include the patches into the kernel you will not need them any more.

As much as I like the Rock64 board, I couldn't agree more with you. It is a really nifty board, so much better in many aspects compared to the Pi, yet so badly supported by Pine. This board (REV. 2 in my case) has still the big problem of not being able to boot from the SSD when it's hooked on the USB3 port, not even with the recent U-Boot version provided by ayufan, for which I had some hope. Back on subject, I have no problem with REV. 2 and the latest 4.4.192 kernel. I have even finally solved the problem with the missing DTV-USB driver, more on this on the relevant thread.

Hello everyone First congratulations for this project. I just started playing with it recently and I am very impressed. Good job! I am the developer of NextCloudPi, which basically consists on providing Nextcloud images for the Raspberry Pi, but has evolved to other flavours such as docker x86 and docker ARM. It also features many scripts for managing the instance that can be run from a classic whiptail like TUI or a simple web interface. The initial goal of the project is to drive as many people away from dropbox into selfhosting, so there's also a Wizard and I try to ease the process of DDNS, certificates and so on. I am after porting it to more powerful boards, so I adapted my build scripts for Armbian and I would like to share them here. I generated a first version of the SD armbian based image for the odroid HC1/X4, that you can find here. If anyone would be interested on trying this and even better help me adapt it further for performance and polish that would be fantastic The build code that I use to produce it is git clone https://github.com/armbian/build ncpbian cd ncpbian wget https://raw.githubusercontent.com/nextcloud/nextcloudpi/master/armbian.sh -O userpatches/customize-image.sh ./compile.sh docker BOARD=odroidxu4 BRANCH=next KERNEL_ONLY=no KERNEL_CONFIGURE=no RELEASE=stretch BUILD_DESKTOP=no NextCloudPi can be installer on any Debian Stretch system with curl -sSL https://raw.githubusercontent.com/nextcloud/nextcloudpi/master/install.sh | bash That script has been tested on Debian x86 servers and also a rock64 (@inos tested it) and an odroid HC1 (and rpi too). Now what I do for the SD images is basically that with a couple adjustments inside customize-image.sh Some issues that I found, maybe you have suggestions the most annoying one: there's about four places where the build process clones from git. There is around a 50% chance that the process will get just stuck there and I have to start over. This means that I sometimes have to try up to five times for the build to finish. Running top inside the container gives 1 root 20 0 21620 5104 2920 S 0.0 0.1 0:00.45 /bin/bash /root/armbian/compile.sh docker-guest BOARD=odroidxu4 BRANCH=next KERNEL_ONLY=no KERNEL_CONFIGURE=no RELEASE=stretch BUILD_DESKTOP=no CLEAN_LEVEL= NO_APT_CACHE+ 9945 root 20 0 4116468 9368 4364 S 0.0 0.1 0:00.16 /usr/bin/qemu-arm-static /bin/bash /tmp/customize-image.sh stretch odroidxu4 odroidxu4 no 9958 root 20 0 4116468 9500 4356 S 0.0 0.1 0:00.28 /usr/bin/qemu-arm-static /bin/bash 10356 109 20 0 4659004 106464 14556 S 0.0 1.3 0:01.66 /usr/bin/qemu-arm-static /usr/sbin/mysqld 13408 root 20 0 4116468 8408 3096 S 0.0 0.1 0:00.10 /usr/bin/qemu-arm-static /bin/bash 14636 root 20 0 4116468 11312 4452 S 0.0 0.1 0:00.12 /usr/bin/qemu-arm-static /bin/bash /usr/local/bin/ncp-update 14668 root 20 0 4116468 9488 4368 S 0.0 0.1 0:00.25 /usr/bin/qemu-arm-static /bin/bash ./update.sh 18087 root 20 0 4116468 8004 2788 S 0.0 0.1 0:00.03 /usr/bin/qemu-arm-static /bin/bash ./update.sh 18929 root 20 0 4116468 9928 4776 S 0.0 0.1 0:00.17 /usr/bin/qemu-arm-static /usr/bin/git clone https://github.com/letsencrypt/letsencrypt 18932 root 20 0 4182572 35188 8016 S 0.0 0.4 0:02.04 /usr/bin/qemu-arm-static /usr/lib/git-core/git-remote-https origin https://github.com/letsencrypt/letsencrypt 18936 root 20 0 4182544 12032 4596 S 0.0 0.2 0:00.24 /usr/bin/qemu-arm-static /usr/lib/git-core/git fetch-pack --stateless-rpc --stdin --lock-pack --thin --check-self-contained-and-connected --cloning https://github.com/le+ 18940 root 20 0 4182544 8980 1416 S 0.0 0.1 0:00.00 /usr/bin/qemu-arm-static /usr/lib/git-core/git fetch-pack --stateless-rpc --stdin --lock-pack --thin --check-self-contained-and-connected --cloning https://github.com/le+ 18942 root 20 0 19948 3652 3128 S 0.0 0.0 0:00.04 bash 18957 root 20 0 38328 3344 2904 R 0.0 0.0 0:00.01 top Also, I had to re-set the root password for installing some packages that use `sudo -u`, such as mariadb, or I get Setting up mariadb-common (10.1.26-0+deb9u1) ... update-alternatives: using /etc/mysql/mariadb.cnf to provide /etc/mysql/my.cnf (my.cnf) in auto mode Selecting previously unselected package mariadb-server-10.1. (Reading database ... 33975 files and directories currently installed.) Preparing to unpack .../mariadb-server-10.1_10.1.26-0+deb9u1_armhf.deb ... You are required to change your password immediately (root enforced) chfn: PAM: Authentication token is no longer valid; new one required adduser: `/usr/bin/chfn -f MySQL Server mysql' returned error code 1. Exiting. dpkg: error processing archive /var/cache/apt/archives/mariadb-server-10.1_10.1.26-0+deb9u1_armhf.deb (--unpack): subprocess new pre-installation script returned error exit status 1 Finally, postfix postinstallation script fails here /usr/sbin/postconf: fatal: inet_addr_local[getifaddrs]: getifaddrs: Address family not supported by protocol So it gets marked as not successfully installed until we run some apt action on the board. Not a big deal really but it would be nice to fix it without ugly hacks. It seems like a qemu-user-static issue https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg02382.html I tested this with my odroid HC1 and I also own a rock64 like this one. Next, I want to try it on the rock64, so what target should I use to build for this board? Thanks, and I hope this is helpful! Feedback is welcome!

Which hw revision is your board? There are at least three and some does not boot without updating boot loader. Those two versions boots with this image https://dl.armbian.com/rock64/archive/Armbian_5.91_Rock64_Debian_buster_default_4.4.184.7z I would question HW maker why they are making so many versions in 1st place?

update: found images now that are actually booting the board. still the latest 3 armbian images are not working for my rock64 4G neither on SD nor on emmc. I would exclude the sd (tried 2) and the power adapter as source of the problem at the moment. So right now sadly I can just stay away from armbian images as the simply will not boot.

I tried this https://github.com/ayufan-rock64/linux-build/blob/master/recipes/flash-spi.md not boot without sdcard edit i haw tested 4 nwme, only one of them boot (Radxa official) SPI, Armbian doesn't recognize this disc , 3 Armbian buster SD boot

jschwart thanks, that you try to help! my problem still is, that I tried at least 3 different images now on an sd-card and on my emmc module and with non of these the board would boot to a usable state. I have no problem at all wiping all the data and start new but i highly doubt that tinkerOS would run on the rock64?

this line is present in /etc/environment, with the subsequent problems (impossible to type éèçà°µù§ on a French keyboard) in Armbian_5.91_Rock64_Debian_buster_default_4.4.184.img wich says, when it starts : Welcome to Debian Buster with Armbian Linux 4.4.182-rockchip64 I use it on a pine4 Rock64 card. Thanks a lot, @epsilonrt, you solved my problem. I was working on it for hours. is it good to file an issue on Github, Igor ?

Sharing a bit of feedback: I tried nightly buster minimal build with 5.3 kernel for Rock64 rev2.0 and it does not reach the state when it is accessible over the network. Both LEDs on the ethernet connector are off. I did not connected the HDMI display and moved on to other things. Hope this helps.

a short update on my rk3318 tv box (h96 max rk3318 2/16G) excursion in short: simply avoid those boxes in detail: i tried to boot armbian rk3288 tv box & rock64 images, the original rock64 image and the libre ROC-RK3328-CC image - none of them worked ... then i tried to get into maskrom mode of the box, tried all the test points on the board but none worked, the heavy way of zeroing the emmc worked of course and i'm in mask rom mode now and can boot from sd card without any interference from the installed loader on emmc - i tried to boot the above mentioned images again: no way (with different error scenarios, but non of them really looking promising), i built atf and u-boot from sources too, but this failed as well - some other experiments failed too - all in all i do not see any way right now to get linux booted in an easy way on it ... besides that the rk3318 hardware seems to be way lower speced than rk3328: on android the cpu frequency scaling only went up to 1.1ghz and there seemed to be only two mali pp cores enabled (just like on the rk3328) - so no gain at all of the rk3318 over the rk3328 - in the end better stick to rk3328 boxes instead trying your luck with rk3318 ones ... best wishes - hexdump

I've been working on a project to boot a custom kernel on my NanoPC-T4. I haven't gotten too far though because as soon as I make the smallest change to the source, everything goes to hell (see below). I've built 3 images following EXACTLY the same process. All I did was change the KERNELBRANCH variable in userpatches/lib.config to point to different branches in the same repository. For completeness, here's my lib.config (which simply points to my fork of ayufan-rock64/linux-mainline-kernel): KERNELSOURCE='https://github.com/ethDreamer/linux-mainline-kernel' KERNELBRANCH='branch:BRANCHNAME' Here's the script I wrote to ensure everything was built exactly the same way: #!/bin/bash for branch in master vanillacopy tinychange ; do # restart the box vagrant halt && sleep 5 && vagrant up # cleanup old build vagrant ssh -c 'cd armbian && sudo rm -r ./cache/sources/linux-rockchip64 ./output/images/Armbian*.img*' # edit lib.config sed -i ./userpatches/lib.config -e "s/branch:.*/branch:${branch}\'/" # build the image vagrant ssh -c 'cd armbian && sudo ./compile.sh BOARD=nanopct4 BRANCH=dev RELEASE=buster\ BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no' # move the image mkdir -p ../outimages/${branch} && mv output/images/*img ../outimages/${branch}/ && \ cp ./userpatches/lib.config ../outimages/${branch}/ done You can see from github that my fork is identical to ayufan's upstream fork; I've made NO CHANGES. Then I created 2 extra branches off of master: vanillacopy and tinychange. The first branch (vanillacopy) like the name implies, is simply a copy of master with no changes. The second branch tinychange contains one tiny change (click to see diff). All I wanted to do was change the kernel's release string that's output by uname -r so that I could be sure I had booted my kernel. RESULTS: the kernels built with master and vanillacopy boot just fine. When booting the image with the kernel built from the tinychange branch: HDMI output stops working networking stops working board takes FOREVER to boot I wouldn't even know it booted without the serial console which stops displaying output after booting the kernel (any kernel) and only resumes output once the system has fully boot on the bright side, the uname string did change: I can't see how this could possibly break everything like this.. what the hell am I missing?

I had similar issue with Rock64 armbian buster trying to boot headless with USB WiFi I did change the boot firstrun txt to enable WiFi and set ssid/pass but it would never connect to AP for SSH access Unlike OP I had access to monitor, I found that the boot process stopped when asking to login root and change root password and create user Using monitor/keyboard, after changing root pass and creating user, I had to run armbian-config to have the WiFi connect After this it ran perfectly as headless and I was able to continue setup via SSH Would not been a good day had I been like OP with no access to monitor / keyboard

Update on stability issues. Sadly, I never discovered a way to make my gstreamer player stop crashing. As I noted in my July 20 2019 post, I created a very stripped down player that loops, but it continued to lock up between 20 and 700 minutes. Happily, I decided to try out the Kodi/LibreELEC player, and spent a couple days porting my looping/GPIO-triggered player to be a Kodi python addon. After a couple 8+ hour runs, I have not seen the crashing issues I saw with gstreamer. I'm not sure if the stability is from the stripped-down LibreELEC OS, or because Kodi is using OpenGL (or is gstreamer also using the OpenGL interface?) But, at least I know have a stable Rock64 4k player.

Thanks, Of course, you have right, not possible to boot this kernel . After creating a new sdcard with armbian last buster and update+upgrade, i have following error root@srv-orangepir1-150:~# [ 2201.407757] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mpage_map_and_submit_extent+0x5d5/0x5dc [ 2201.407757] [ 2201.408003] BUG: Bad rss-counter state mm:bc76d143 idx:0 val:15 [ 2201.412010] Unable to handle kernel paging request at virtual address cfa17500 [ 2201.412019] pgd = 0b15e16e [ 2201.412024] [cfa17500] *pgd=4fa1141e(bad) [ 2201.412038] Internal error: Oops: 8000000d [#1] SMP THUMB2 [ 2201.412043] Modules linked in: nf_tables nfnetlink veth dm_mod dax 8189es snd_soc_simple_card snd_soc_simple_card_utils sun8i_codec_analog sun4i_i2s sun8i_adda_pr_regmap snd_soc_core lima cfg80211 snd_pcm_dmaengine cdc_ether snd_pcm usbnet sun4i_gpadc_iio gpu_sched snd_timer r8152 ttm industrialio snd soundcore sun8i_ths cpufreq_dt uio_pdrv_genirq thermal_sys uio pwrseq_simple [ 2201.412130] CPU: 1 PID: 2856 Comm: monit Not tainted 4.19.62-sunxi #5.92 [ 2201.412133] Hardware name: Allwinner sun8i Family [ 2201.412141] PC is at 0xcfa17500 [ 2201.412152] LR is at try_to_del_timer_sync+0x3b/0x54 [ 2201.412157] pc : [<cfa17500>] lr : [<c016efeb>] psr: 60070013 [ 2201.412160] sp : cd945c68 ip : cd94403c fp : 00000001 [ 2201.412164] r10: c090ba6b r9 : 0000007d r8 : 00000000 [ 2201.412168] r7 : c0e04d48 r6 : c0e04d48 r5 : 00000002 r4 : cd945ca4 [ 2201.412172] r3 : e298f2ae r2 : e298f2ae r1 : 40070013 r0 : 0000007d [ 2201.412178] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 2201.412183] Control: 50c5387d Table: 4e16006a DAC: 00000051 [ 2201.412187] Process monit (pid: 2856, stack limit = 0xd700aa4c) [ 2201.412192] Stack: (0xcd945c68 to 0xcd946000) [ 2201.412200] 5c60: c013b33d 00000100 00000200 e298f2ae 00000200 c06f54a1 [ 2201.412209] 5c80: cfd48480 cde7c780 c0e04d48 cd945ca8 00000000 cd945ce8 000001f4 00000005 [ 2201.412218] 5ca0: 80000280 c06f548b 00000001 00020002 cd945c74 cd945c74 00000000 e298f2ae [ 2201.412227] 5cc0: 00000004 ce115c00 c0e04d48 cdb66000 00000004 00000133 0000b400 c06f5557 [ 2201.412235] 5ce0: 000000c0 ce115280 00000000 e298f2ae 00000000 ce115280 00000004 0000b400 [ 2201.412244] 5d00: 00000133 cf8ef580 00000001 00001000 cd945f78 bf8d209b 0000b400 00000133 [ 2201.412253] 5d20: ce115280 00000004 000001f4 c066e9ad 00000133 cf8ef580 c0e04d48 cf8ef580 [ 2201.412262] 5d40: cd945d80 bf8d31db cd945d80 c0e03d00 ffffe000 00000133 0000fffc bf8d408d [ 2201.412270] 5d60: 00000133 00000001 cd945dbc ffffb400 00000000 bf8d4119 00080040 cf228420 [ 2201.412279] 5d80: cf228498 e298f2ae cf8ef85c cd945e84 00000000 000002cf cf8ef000 bf8d4159 [ 2201.412288] 5da0: bf8d4131 c06d72fb cf8ef000 cd945e84 00000000 cf8ef87c ce44db38 cde7c300 [ 2201.412297] 5dc0: 00001000 bf8d289f bf8d286d c0e04d48 cf8ef000 bf8d97ec cd945e84 c07eb093 [ 2201.412305] 5de0: ce115c40 cdec7a20 00000000 cd245a90 ce60c900 c0a18848 00000000 ce60c900 [ 2201.412314] 5e00: cd0a3440 c0b939a8 00080040 c024656d 00000000 e298f2ae ffffffff c0e04d48 [ 2201.412323] 5e20: ce44d800 c0abf540 cd945e84 c07eb093 00000000 00000000 cee44088 c02499eb [ 2201.412331] 5e40: cd945edc c01959ef 00000000 00000004 00000000 c0e04d48 00000000 c0e04d48 [ 2201.412340] 5e60: be919b78 e298f2ae ffffe000 c0e04d48 ce44db30 ccaea000 ccaea000 c0805f47 [ 2201.412349] 5e80: 00000011 00000000 00000000 00200200 00000001 00000000 00000000 00000000 [ 2201.412356] 5ea0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 2201.412365] 5ec0: 00000000 00000000 00000000 e298f2ae c0ed1bc0 c0805efd c0a89dec c0662f3f [ 2201.412374] 5ee0: c0662f2d cd63fcb8 00001000 c029e98d c029e92d cd63fcb8 00000001 00001000 [ 2201.412382] 5f00: ce60c900 007000c0 cd63fcd0 c025ae3b 00000001 00000000 cd63fce8 00001000 [ 2201.412391] 5f20: 02069470 c023ecb5 ce60c900 00000000 02069470 00001000 ffffe000 cd945f78 [ 2201.412400] 5f40: ce60c900 00001000 020b78e8 c023ecb5 00004000 02069470 02069470 ce60c900 [ 2201.412409] 5f60: c0e04d48 ce60c903 02069470 00000000 00000000 c023f061 00000000 00000000 [ 2201.412417] 5f80: 00000000 e298f2ae 00000074 00001000 02069470 00000003 c0101224 cd944000 [ 2201.412426] 5fa0: 00000003 c0101001 00000074 00001000 00000006 02069470 00001000 00000000 [ 2201.412435] 5fc0: 00000074 00001000 02069470 00000003 b6f344d0 be919e18 00000000 020b78e8 [ 2201.412443] 5fe0: 00000003 be919bf0 b6b38555 b6ac1746 800f0030 00000006 00000000 00000000 [ 2201.412467] [<c016efeb>] (try_to_del_timer_sync) from [<c06f54a1>] (usb_start_wait_urb+0x7d/0xa4) [ 2201.412477] [<c06f54a1>] (usb_start_wait_urb) from [<cd945c74>] (0xcd945c74) [ 2201.412486] Code: 00000000 00000000 00000000 00000000 (00000000) [ 2201.412492] ---[ end trace 183b5afa6da22150 ]--- Thanks to find in attached file all logs with many reboot -!). My sdcard is a 16 Go SANDISK class 10. All my targets are using (from 2 years ago) this type of sdcard without any issue, but perhaps that this one is not OK (?). On other Armbian kernel, (Cubietruck, HC1, Rock64, nanopiR1), i have also the same SD without any issue. Of course, it is not the same kernel and sometimes stretch instead of buster Just after booting orangepiR1 target, i have : root@srv-orangepir1-150:~# LANG=C LC_ALL=C pstree -anp init,1 |-systemd-udevd,349 |-syslog-ng,2519 | `-syslog-ng,2520 -p /var/run/syslog-ng.pid --no-caps |-cron,2661 |-dbus-daemon,2689 --system |-sshd,2804 |-monit,2856 -c /etc/monit/monitrc | |-{monit},2867 | |-{monit},2884 | |-(verify_ipv4_add,3131) | |-(verify_ipv4_add,3132) | |-(verify_ipv4_add,3135) | `-(verify_ipv4_add,3138) |-getty,2879 115200 console |-getty,2880 38400 tty2 |-getty,2881 38400 tty3 |-getty,2882 38400 tty4 `-login,2883 -- `-bash,2890 `-pstree,3154 -anp root@srv-orangepir1-150:~# tty-from-srv-orangepir1-150-2019-08-16-14h-34min.ok.txt

In my project I would like to create Armbian ISO that has only the packages that are really needed for system itself and literally few I need for my application. Just to use smallest possible SD card and not update packages I will never use. Regardless how I configure build at the end I got 1GB image. While I know it is possible to go down to 100MB using Ubuntu bionic and latest kernel. Shall debootstrap use configurable —variant option? For me “minbase” would be perfect. But it does not change anything. Shall I put into lib.config my version of PACKAGE_LIST? Still a rootfs is forced to download. No success. So how to strip down the packages in rootfs compilation? I am using Rock64 modules.

None of the LEDs present on Rock64 is attached to SoC, they are connected to PMIC and VCC_SYS. You will need to add one directly on GPIO header ...

Hi, I have following error on Rock64 when trying to update with apt tools: -1- My config file is : root@srv-rock64-130:~# cat /etc/apt/sources.list.d/armbian_apt_v_9_stretch.list |grep -v "#" deb http://apt.armbian.com stretch main stretch-utils stretch-desktop -2- to get all keys, i run ... /usr/bin/wget \ --tries=3 \ --output-document=/tmp/Release.key \ --quiet \ --no-check-certificate \ http://apt.armbian.com/armbian.key \ && \ /usr/bin/apt-key add - < /tmp/Release.key \ && \ /bin/rm -f /tmp/Release.key root@srv-rock64-130:~# /usr/bin/wget \ > --tries=3 \ > --output-document=/tmp/Release.key \ > --quiet \ > --no-check-certificate \ > http://apt.armbian.com/armbian.key \ > && \ > /usr/bin/apt-key add - < /tmp/Release.key \ > && \ > /bin/rm -f /tmp/Release.key OK -3- Issue ? but when launching apt update root@srv-rock64-130:~# apt update Réception de:1 http://security.debian.org stretch/updates InRelease [94,3 kB] Atteint:2 http://ftp.fr.debian.org/debian stretch-backports InRelease Ign:3 http://ftp.debian.org/debian stretch InRelease Atteint:4 http://ftp.debian.org/debian buster InRelease Atteint:6 http://ftp.fr.debian.org/debian stretch-updates InRelease Atteint:7 http://ftp.debian.org/debian stretch Release Réception de:8 http://deb.ayufan.eu/orgs/ayufan-rock64/releases InRelease [1 339 B] Réception de:9 http://deb.ayufan.eu/orgs/ayufan-rock64/pre-releases InRelease [1 339 B] Ign:5 https://apt.armbian.com stretch InRelease Err:10 https://apt.armbian.com stretch Release server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none Lecture des listes de paquets... Fait E: The repository 'http://apt.armbian.com stretch Release' does not have a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. Thanks in advance for your help

Status update. DHL parcel received. New boards photos: and SD adapter inserted into Rock64 Now I am waiting for remaining components then soldering/assembly will start.

Can we incorporate the following patch please: https://github.com/torvalds/linux/commit/a8772e5d826d0f61f8aa9c284b3ab49035d5273d It makes the USB ports work again on my rock64 v2.0/4GB. Thanks! I'm also willing in lending a hand at testing.

just in case someone else would like to play around with mainline on rk3328 tv boxes: i have created dts files for the t9 and the mx10 rk3328 tv boxes, which work with mainline - you can either try the dtb files or drop the dts files into this tree: https://github.com/ayufan-rock64/linux-mainline-kernel.git plus apply the attached patch to build them from source. for me it works quite well, but its not deeply tested yet and not all hardware supported by the 4.4 kernels will be supported by mainline most probably. i think one or the other should work for most rk3328 tv boxes where the corresponding 4.4 dtb's work with the 4.4 kernels. @balbes150 - maybe they are interesting for you to include into future rk3328 images? best wishes - hexdump rk3328-t9-mainline.dtb rk3328-mx10-mainline.dts rk3328-mx10-mainline.dtb mx10-t9-mainline.patch rk3328-t9-mainline.dts

Hi, few days delay as I had to do also other things Anyway... By latest I meant respective versions of default NOT dev branches. Thus: Pine H64 - branch next results in kernel 4.19.59 Rock64 - branch default results in kernel 4.4.184 Both had problems to boot. PineH64 did not start kernel at all while Rock64 has some crashes during kernel initialization resulting in no /bin/init. As I had to progress somehow I decided to switch to dev branch. After that numbering changes to: Pine H64 - kernel 5.2.2 Rock64 - kernel 5.2.0 Using dev branch I have successfuly build minimal images for those two boards using Ubuntu Bionic as base. Both boards works fine using mini images. Only one issue I have noted: pineh64:~$ /etc/update-motd.d/10-armbian-header error: could not load font standard Welcome to Ubuntu Bionic with Armbian Linux 5.2.2-sunxi64 This is because there is no standard font for toilet usage. https://packages.ubuntu.com/xenial/all/toilet-fonts/filelist Standard font is available for figlet. But figlet is not installed and not in use by 10-armbian-header script. Shall other available be used instead, like mono12?

I hope you can understand my question just from the title but here's more information in case you need it. BACKGROUND ON MY END GOAL IN CASE YOU HAVE ADVICE: I'm attempting to create a hardened linux image for running on my nanoPC-t4. I gotta give you guys props because Armbian appears to be wayyyyy ahead of the alternative distributions I checked out (gentoo/arch/lubuntu) in terms of support/customizability/documentation for ARM development. As a first step, I'm trying to build & boot a hardened Linux kernel. After some googling, I settled on this repo as my best option for free & open-source hardened kernel sources (unless anyone has a better suggestion). ON MY ORIGINAL QUESTION: I've already booted a manually built image using the Armbian Build Tools. Now I'm trying to create an image with custom linux sources but I'm not very familiar yet with the build scripts and the development guide doesn't detail the process of adding new kernel sources into the tool. I tried the naive option of simply editing the sources configuration file to point to a different repo: - KERNELSOURCE='https://github.com/ayufan-rock64/linux-mainline-kernel' - KERNELBRANCH='tag:5.2.0-1116-ayufan' - KERNELDIR='linux-rockchip64' + KERNELSOURCE='https://github.com/anthraxx/linux-hardened' + KERNELBRANCH='tag:5.2.a' + KERNELDIR='linux-hardened' And this worked up to a point - obviously all the patches failed to apply but the tool continued anyway. `make oldconfig` had me update the config with the missing options and I was eventually dropped into menuconfig. That went fine but eventually the build failed and the script stopped (sorry I don't have the exact error right now because I'm at work). But most importantly I noticed the script DIDN'T FAIL because of a kernel compilation error. So something else went wrong/is needed to get this source integrated into the build system. I'm just wondering what the process is for doing that.

I was actually able to successfully do the opposite (merge commits from ayufan-rock64/linux-mainline-kernel into anthraxx/linux-hardened). I thought this might be easier since there wasn't a whole lot of commits to aufan's branch after forking from torvalds/linux. Either way I can't test either kernel until I know how to integrate a new kernel source into the Armbian build system.