Search the Community

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 have the Rock64 4G Version with emmc module Since the latest Kernel Update two weeks ago on friday the board does not boot up anymore. (I was on Stretch initially and updated regularly since.) Even with a newly flashed sd card and without emmc module the board will not but into armbian. I managed to boot into raspbian buster 5.91 once, but after rebooting it, it failed again and stayed that way. until now I have tried the latest 3 images. The Kernel is now 4.4182 and is unchanged whatever I do. with any armbian on an sd card i am getting: Failed to start armbian zram config - failed to start journal service Failed to flush Journal to Persitent Storage rockchip64 #6 and at some point the boot sequence stops with something like: work_pending+0x10/0x14 or I am getting consistent timeouts from "waiting for device" with the original emmc card it gives me: ... BUG: spinlock bad magic on CPU#2 goes to: secondary_start_kernel +0x190/0xbc 0x2cxa188 repeats and stops there also since the beginning I sometimes get: "fixing recursive fault. Reboot is needed!" - without reboot improving anything of course.. I am afraid that at this point of failure notices and kernel panics I have no idea how to proceed anymore.

I cannot connect by VNC/ FTP from more than one computer on network to my Rock64 but can do multiple SSH. Once I have one computer connected by VNC I want to go elsewhere on my network and monitor same session or ftp in. but once one session is running others are not allowed. also only allows ftp from computer with other session. if reboot can connect but loose original session. how can I allow multiple sessions.

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.

Hello, the Rock64 SBC can receive an add-on board with audio ports and an additional ethernet port. I have used it a lot before, with Debian Stretch. With the armbian image it does not work. The reason is simple, this board must be activated by a script which is missing. Ayufan has added a set of scripts in /usr/local/sbin, but they are not present in this build. They can be found here : https://github.com/ayufan-rock64/linux-package/blob/master/root/usr/local/sbin/enable_dtoverlay Then run the necessary command : enable_dtoverlay eth1 ethernet@ff550000 okay and the card is present in ifconfig. Once given an iP address, it works perfectly. Nevertheless, the log indicates a conflct with the ic2 interface. Jul 16 14:39:33 localhost systemd[1]: Started LSB: Advanced IEEE 802.11 management daemon. Jul 16 14:39:33 localhost rc.local[1312]: Applying... Jul 16 14:39:33 localhost rc.local[1312]: /dts-v1/; Jul 16 14:39:33 localhost rc.local[1312]: / { Jul 16 14:39:33 localhost rc.local[1312]: #011fragment@0 { Jul 16 14:39:33 localhost rc.local[1312]: #011#011target-path = "/ethernet@ff550000"; Jul 16 14:39:33 localhost kernel: [ 37.895961] rockchip-pinctrl pinctrl: pin gpio2-25 already requested by ff150000.i2c; cannot claim for ff550000.ethernet Jul 16 14:39:33 localhost kernel: [ 37.895967] rockchip-pinctrl pinctrl: pin-89 (ff550000.ethernet) status -22 Jul 16 14:39:33 localhost kernel: [ 37.895972] rockchip-pinctrl pinctrl: could not request pin 89 (gpio2-25) from group fephyled-rxm1 on device rockchip-pinctrl Jul 16 14:39:33 localhost kernel: [ 37.895976] rk_gmac-dwmac ff550000.ethernet: Error applying setting, reverse things back Jul 16 14:39:33 localhost kernel: [ 37.896167] rk_gmac-dwmac ff550000.ethernet: Looking up phy-supply from device tree Jul 16 14:39:33 localhost kernel: [ 37.896433] rk_gmac-dwmac ff550000.ethernet: clock input or output? (output). Jul 16 14:39:33 localhost kernel: [ 37.896440] rk_gmac-dwmac ff550000.ethernet: Can not read property: tx_delay. Jul 16 14:39:33 localhost kernel: [ 37.896446] rk_gmac-dwmac ff550000.ethernet: set tx_delay to 0x30 Jul 16 14:39:33 localhost kernel: [ 37.896451] rk_gmac-dwmac ff550000.ethernet: Can not read property: rx_delay. Jul 16 14:39:33 localhost kernel: [ 37.896454] rk_gmac-dwmac ff550000.ethernet: set rx_delay to 0x10 Jul 16 14:39:33 localhost kernel: [ 37.896509] rk_gmac-dwmac ff550000.ethernet: integrated PHY? (yes). Jul 16 14:39:33 localhost kernel: [ 37.896644] rk_gmac-dwmac ff550000.ethernet: cannot get clock clk_mac_refout Jul 16 14:39:33 localhost kernel: [ 37.896650] rk_gmac-dwmac ff550000.ethernet: cannot get clock clk_mac_speed Jul 16 14:39:33 localhost kernel: [ 37.901732] rk_gmac-dwmac ff550000.ethernet: init for RMII Jul 16 14:39:33 localhost rc.local[1312]: #011#011__overlay__ { Jul 16 14:39:33 localhost rc.local[1312]: #011#011#011status="okay"; Jul 16 14:39:33 localhost rc.local[1312]: #011#011}; Jul 16 14:39:33 localhost rc.local[1312]: #011}; Jul 16 14:39:33 localhost rc.local[1312]: }; Jul 16 14:39:34 localhost kernel: [ 37.936441] stmmac - user ID: 0x10, Synopsys ID: 0x35 Jul 16 14:39:34 localhost kernel: [ 37.936452] Ring mode enabled Jul 16 14:39:34 localhost kernel: [ 37.936457] DMA HW capability register supported Jul 16 14:39:34 localhost kernel: [ 37.936461] Normal descriptors Jul 16 14:39:34 localhost kernel: [ 37.936466] RX Checksum Offload Engine supported (type 2) Jul 16 14:39:34 localhost kernel: [ 37.936470] TX Checksum insertion supported Jul 16 14:39:34 localhost kernel: [ 37.936475] Enable RX Mitigation via HW Watchdog Timer Jul 16 14:39:34 localhost kernel: [ 37.936660] of_get_named_gpiod_flags: can't parse 'snps,reset-gpio' property of node '/ethernet@ff550000[0]' Nevertheless, the ethernet port is working. Is this a false alarm ? The Rock64 has two GPIO connectors, and the ethernet port is on the second. But the ic2 should be on the first. Whatever the reason, the port works fine.

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

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

I have a C++ app that wants to indicate its activity by blinking an LED on the Rock64. How can the LEDs be controlled? The sysfs leds do not appear to be present. I'm okay with libgpiod or sysfs gpios, but I don't know what gpio numbers represent the LEDs. Anyone know? Thanks. Linux rocky64 5.0.0-rockchip64 #5.85 SMP Wed May 8 19:38:28 CEST 2019 aarch64 aarch64 aarch64 GNU/Linux Distributor ID: Ubuntu Description: Ubuntu 18.04.3 LTS Release: 18.04 Codename: bionic

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.

Hey guys, I installed Armbian some months ago in my Rock64 and I had never updated the packages. Yesterday I decided to do an apt update + apt upgrade to update one of the applications I use. I noticed that meanwhile apt updated Armbian itself, and began to ask for a reboot. A few hours later I rebooted the board. At first I couldn't connect due to connection refusal, so I went plugged a keyboard and hdmi on the board to see what was happening. It looks like while doing this I unplugged the power source suddenly, and now the board won't boot the system in this OS. No image or response in the USB keyboard. I thought it could be SD corruption, but I'm able to open the SD card in my Desktop and see its contents. Since I had a lot of tweaking in the old system, is there a way to copy some parts of a new image and paste in the SD, so I can boot it again? Or maybe reflash the SD with the latest armbian, then pasting some folders over it (maybe home and /var/lib at least)? Thanks for the advices.

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

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.

That was a great suggestion. I launched several 4k, 1080p and 640x480 videos in the Rockchip Gst Player, and yes, I see the same behavior in all of them (now that I am looking closely for it) The first frame is displayed statically for ~1/4 sec for the 4k video, and then the video plays smoothly. Interestingly enough, the 640x480 delay is noticeably shorter, but I still see it. I see the same thing when running MPV-GBM. I see the same thing when playing a file on a ramdisk. And, I just launched VLC on my Windows i7, set it up to loop, and i see the startup delay there, too. Based on this test, I'm assuming this is just something inherent in setting up video playback streams. And unless someone has any additional ideas, there is nothing in gstreamer or the Rock64 media kit that I can set to reduce it. So, I'll have to work around it by making sure that the first second of the video is static. Thanks for the suggestion. -Jeff

2x595 or MCP23017 - no problem to switch. Actually 595 as simple shift register can be driven by SPI directly, yet on RPi header (first 10 pins) there is I2C, so no big deal to use MCP23017 instead. Why I have chosen 595 initially? As it saves some pennies and footprint. And it it really simple to send command using "software SPI". And commands are to be sent rarely, no need for high speeds. Concept picture of the automated test device: No spacers are visible. Rock64 is a MasterSBC here, it is to be used to control 8 system under test - SBCs. Each of them connected using 10pin header (power + serial) plus custom SD card adapter. On top of the MasterSBC is a (shorter) SD mux board, micro SD sockets placed on both sides of the PCB are invisible, as I have no 3D model for them (MOLEX 47219-2001 one). Also 4 pin headers would be replaced by JST XH2.54 ones. Yes, instead of single SD shared between all SUTs, newest design has 8 SD cards, and MasterSBC can connect those to SUT or to itself for image uploading process. Of course if SDx card is beeing used by MasterSBC, then SUTx shall be powered of as it will not see and SD card "inserted", will not boot. Next to it, top one its serial mux + power distribution board, with 8 sockets of type Molex KK 254 AE 6410 04AKK 254. Both add-on boards works together. When it comes to use cases, one shall use SPI / i2C interface to program 16 bit configuration word. From msb to lsb: ME M2 M1 M0 SE S2 S1 S0 | P7 P6 P5 P4 P3 P2 P1 P0 Meaning of particular bits: - "Px" is power section control (8 independent ports) - "Mx" is a SD card multiplexer control (8 micro SD cards) - "Sx" is a serial interface multiplexer control Meaning of bits ME & SE: ME : 0 - SUTx disconnected from SDx, MasterSBC connected to SDx pointed by M2-0 ME : 1 - SUTx uses SDx SE : 0 - MasterSBC connected to SUTx serial pointed by S2-0, 7-seg led active SE : 1 - No serial link crossed, 7-seg led inactive So with this design all 8 SUTs can be power controlled at the same time, serial console be connected to one of he powered SUT while at the same time other SD card can be used to upload new image. Examples: Upload image to SD card 3, SUT 5 & 7 working, Master listens to Serial from SUT7 0 0 1 1 0 1 1 1 1 0 1 0 0 0 0 0 Upload image to SD#1 (thus) SUT#1 disconnected, all other SUT are working 0 0 1 1 1 0 0 0 1 1 1 1 1 1 0 1 Upload image to SD#1 all SUT are working (SUT1 do not see SD card, will not boot) 0 0 1 1 1 0 0 0 1 1 1 1 1 1 1 1 Comments appreciated. I am attaching also schematics for anyone wanted to take a look. (now with 595 which can be replaced for I2C connectivity). serial-mux.pdf sd-card-mux.pdf

And works for me. I have created set of regular & mini bionic images for pineh64 and rock64. The thing I am struggling with is that latest kernels do not boot :/ but this is different story not for this topic.

For example Rock64 takes 0,9A at processor peak. Measured by myself. I will later check other SBCs I have, including Odroid XU4. Anyway the 4mm track I placed on PCB shall be enough to provide 7.5W to each of all 4 SUTs. Or max 30W in total, which better describes reality. But to not overload external power supply, I suggest to use such a board in a way to not start all SUTs at the same time, but boot them one by one, with let's say 2s delay. Then after ~15sec all SUT will be running, but power usage will be on reasonable level. Yes, but spacers will secure insulation. Using EDA for several years already. Long time ago I have started with Orcad, then moved to Protel 99, and now KiCad fan.

Topic: Stability of gst based player using RK3328 Media Script My earlier post today regarding Buster made me recall that I have a stability problem with my gst video player, and maybe one of you can help. My gst-based video application plays one video file that is actually a concatenation of 4 other videos of the same format. A GPIO input selects which of the 4 videos to be played, and the program loops that video until a different selection is made. The seek command in the concatenated video is much faster than loading a new video each time. This is largely based on the examples in the gstreamer/gst-docs files at Github. It all worked, but the program occasionally freezes, anywhere from 20 to 700 minutes into a test. I ran with GST_DEBUG=2 (WARN), and I found a bunch of warnings and errors, including many warning and error messages at startup (some of these may be audio related – I did not have speakers hooked up) frequent frame drops - <mppvideodec0> can't process this frame timestamp issues - <mppvideodec0> decreasing timestamp But, I was never able to see a specific error associated with the program lockup My first guess was that there was a data streaming problem somewhere, so I forced a CPU speed increase from 408 MHz to 1200MHz. No difference. So, I did a clean build using the latest Bionic (to make sure that it was not a random package that I installed that was the problem) and still see the errors. This occurs with several different videos, from 640x480 up to 4k, and using both h264 and h265 encoding. Configuration: Rock64, 4GB board OS: Latest Bionic, downloaded from: www.armbian.com/rock64/ Armbian_5.90_Rock64_Ubuntu_bionic_default_4.4.182_desktop.img (see my other post about my attempt to move to Buster) VIdeo: Big Bunny 1080p, 30fps, h264 from http://bbb3d.renderfarming.net/download.html I installed the Media Script, downloaded from this thread, dated Jan 13, 2019 I installed gstreamer1.0-tools gstreamer1.0-plugins-base-apps libgstreamer1.0-dev X11VNC I stripped the program down to get rid of everything I could (removing config files, keyboard watch, GPIO watch, debug statements, etc) and made a simple player that just loops after 30 seconds. The code is attached, as is the log file based on a GST_DEBUG=2 setting. Anyone have any thoughts? I’d love some advice, or a pointer to a person or group that I could get in contact with. Thanks! -Jeff simple_player_log_bunny_20190720.log simple_player.c

I did a test build using Armbian Buster on my Rock64 TLDR: It failed Hardware: Rock64 4 GB OS downloaded from: https://www.armbian.com/rock64/#kernels-archive: Armbian_5.91_Rock64_Debian_buster_default_4.4.184_desktop.7z Media script: downloaded from this thread, dated Jan 13, 2019 I imaged the SD card, booted, setup a user and password, and connected to wifi. That's it. I then ran the media script, using the first 4 options (system, dev, mpv, gstreamer) and the Armsoc version. The script seemed to run OK, but ended in a message that said there were errors during installation. I've attached the install.log. There are no FAIL, ERROR or WARN messages. The only issue I found was this sequence: Could not open file /var/lib/apt/lists/apt.armbian.com_dists_buster_main_binary-armhf_Packages.lz4 - open (2: No such file or directory) E: Could not open file /var/lib/apt/lists/apt.armbian.com_dists_buster_main_binary-arm64_Packages.lz4 - open (2: No such file or directory) E: Could not open file /var/lib/apt/lists/security.debian.org_dists_buster_updates_main_binary-armhf_Packages.lz4 - open (2: No such file or directory) E: Could not open file /var/lib/apt/lists/security.debian.org_dists_buster_updates_main_binary-arm64_Packages.lz4 - open (2: No such file or directory) I then rebooted and it failed to boot, showing : [FAILED] Failed to start Light Display Manager Per the bootstrap.log, I ran "systemctl status lightdm.service" (the output is also attached) I'm not sure what the error messages mean, or what "Unit plymouth-quit.service not found" implies. So, obviously something in the media script did something to mess up the desktop. Perhaps an old Bionic library incompatible with Buster? So, I was eager to try the new build to see if it got rid of some stability problems I'm having with my gst based player. But it looks like I'm going to have to go back to my Bionic build, unless someone has any idea on how to repair the Light Display Manager and get me booted. Thanks, -Jeff sysctl_log.txt install.log

I wonder if this dependency shows up only if EXTERNAL=YES is selected? Side note, while I am building something I see following error: [ o.k. ] Applying distribution specific tweaks for [ bionic ] /home/op/armbian-build/lib/distributions.sh: line 380: /home/op/armbian-build/.tmp/rootfs-default-rock64-bionic-no/etc/netplan/armbian-default.yaml: No such file or directory [ o.k. ] Applying common tweaks