Search the Community

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

Speaking of the needed hardware. As I understand you need a multiplexer that will connect a real SD card to some connected SBCs under test (let's call them SUT) and the controller itself. Why real SD? As I do believe there is no point to emulate it. So the HW shall be something like hat on top of one of cheapest SBC, like Rock64 (that I will call MasterSBC), that multiplex: - SD card to USB-to-SD adapter connected to MasterSBC, for writing new image to it or one of SUT for read/write - Serial port of selected SUT to MasterSBC, - Select SUT by applying also power to it, trivial circuit with MOSFET will do the job, controlled by HC4515 chip (4 to 16 decoder) (I suggest to power SUTs via 40pin header) Of course with such mux only one SUT will be possible to control at the time. With this setup, MasterSBC will use native USB to access SD card, using 4 GPIO to select SUT and serial port for monitoring what SUT is doing. Capacity? 15 connected SUTs All easy scriptable with basic python commands. In my free time, I can design such a hat and publish schematics & gerber files here.

Hi, Shall work with any combination of SBS/kernel/OS. Like rock64/default/bionic or pineh64/dev/stretch and others To trigger this variant when selecting image type "server" a new dialog will pop up to specify development image (former config) or minimal. Alternatively simply put following options in command line: BUILD_MINIMAL=yes together with BUILD_DESKTOP=no. Observe BUILD_DESKTOP must be set and takes priority, i.e. BUILD_MINIMAL=yes BUILD_DESKTOP=yes will be interpreted as BUILD_MINIMAL=no BUILD_DESKTOP=yes. When no BUILD_DESKTOP option is given in command line, appropriate dialog box will pop up thus BUILD_MINIMAL may be overwritten. Now the changes are put as PR to the mini branch of armbian/build git repository. https://github.com/armbian/build/pull/1463 Final images for minimal and development variants: root@armbian:~/armbian-build# ls -l output/images/*.img -rw-rw-r-- 1 root root 1107296256 Jul 20 12:12 output/images/Armbian_5.91_Rock64_Ubuntu_bionic_default_4.4.184.img -rw-rw-r-- 1 root root 591396864 Jul 20 12:33 output/images/Armbian_5.91_Rock64_Ubuntu_bionic_default_4.4.184_minimal.img root@armbian:~/armbian-build# I was using following command line for testing (note IGNORE_UPDATES=yes FORCE_CHECKOUT=no shall - to my understanding - only be applicable for testing purposes): ./compile.sh CLEAN_LEVEL=none IGNORE_UPDATES=yes FORCE_CHECKOUT=no EXTERNAL=NO BOARD=rock64 BRANCH=default RELEASE=bionic KERNEL_ONLY=no KERNEL_CONFIGURE=no BUILD_MINIMAL=[yes|no] BUILD_DESKTOP=no

Sounds great for me Could you please tell whene and how its use/testable? Do we need two ./compile.sh lines/starts or only one? Is the seperate branch automatically selected when using BUILD_MINIMAL="yes"? Does it work only for the rock64 or on any sbc?

Booting 5.2 bionic on Rock64 v2 was fine first boot then subsequently future starts crash loops a few times but eventually gets to login. Please let me know what I can do/supply to help. Happy to iterate on it.

Hi. The Armbian site for Rock64 has the Buster release. https://www.armbian.com/rock64/#kernels-archive The release notification includes: "Video and 3D acceleration addon" with a hyperlink to this forum topic. Does that mean that I only have to apt-get install gstreamer1.0, apps, tools and utilities to get my gst program to run? Or do I need to dissect he media script to figure out what to install?

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.

I'll give 5.2 a spin on my Rock64 4gb this weekend. Thanks very much.

So using the old sysfs (/sys/class/gpio/) interface, you "export" a gpio by spitting the gpio number into /sys/class/gpio/export. The GPIO number depends on the board and relevant documentation. Having once found that I need GPIO number 76, I'm migrating code to the new "gpio character device" interface (/dev/gpiochipn) on my Rock64. However, "gpioinfo" shows that hardly any gpios have useful labels, and Google searches always turn up Raspberry Pi results. So, can I just calculate the new gpio identify? Old gpio is 76, all /dev/gpiochips have 32 lines, 76/32 = 2 rem 12, so old gpio 76 is now /dev/gpiochip2 line 12? Edit: I tried this, and it was correct. Is this anywhere documented to be correct in all/most/many/some cases?

I'll for sure forget some of them. It all started with the Raspberry Pi2B(4 years ago now) ... and then ... Odroid C2 (For 3 years my favorite. Clocked at 1.75Ghz, with 128Ghz eMMC and ram OC it's amazingly fast. Low power consumption, good video playback(low display resolution), great gaming on it. Still use it as my SBC laptop, but the VIM3'll replace it Raspberry Pi3B (Not better than the pervious model. Dissapointed by it) Raspberry Pi Zero (+ 2 x Zero W) (was handy, had build a Pi0Camera with it and an audio recorder, got in dissuse) Orange Pi+2 (hated it, I still believed the 1.6Ghz bs, afterwards started to love it for what it is) Tinker Board (x2) (Worst buy ever, too expensive for what it's. First broke, I was so stupid to buy another one without using it much) Khadas VIM2 Max (Too slow for what it is. Otherwise a good designed board when used for what it's good) Odroid XU4 (Loved it. It was my 2nd desktop with a HDMI-hub so I could switch to it when my PC was bussy. Amazing performance and great games. But a lot of issue's too) Rock64 (a lot of issue's, nice on paper but doesn't deliver it's promises) Banana Pi M2 Zero (nice little board, runs too hot to be useful, but had a lot of fun with it) NanoPC T3+ (Love it a lot. Amazing for Blender renders, at a low power consumption. But single core performance is too low, should be default overclocked to 1.6Ghz in my opinion. It can handle it and cooling solution is sufficient) Raspberry Pi 3B+ (What a garbage board. DDR2 with a ok SoC is a bad combination. Bad power delivery, not very useable) NanoPi M4 (My favorite until the VIM3 came, all-round a great board. Too bad there's a lack of Linux drivers for great gaming on it) Rock Pi 4B (First impression was great. But that went away after a while. Many software issues. I hate that I can't reach my eMMC with the big heatsink on) NanoPi DUO2 (Still need to review it, but my first impression wasn't too good. Bad thermals, no hardware video encoding for the camera. This should be fixed by now, maybe a next video someday...) Orange Pi 3 (Ok SoC, badly designed board) Pine H64 model b (Ok SoC better designed board, it's their second try tho) Odroid N2 (Great board, amazing performance and no fan needed. But runs at 12V so I can't run it on my power banks. I use it headless with VNC to do render jobs together with the NanoPC T3+) Nitrogen8M Mini (I don't know yet, no HDMI and all proprietary connectors for everything. It is an industrial board for KIOSK's, but I'd like to see HDMI to set it up easily. It does have great audio assets, amplifier, audio in-out) Khadas VIM3 (My newest favorite. What a performance for such low consumption at 5V. I've got the Basic, so much want the Pro... It's perfect to take with me to do heavy video render tasks. I love it...) Raspberry Pi4B (My biggest surprise ever. Not thinking too much of it. But it's a lot more than I thought. Performs amazing. But still has its faults. I think that's it. In chronological order I bought them. The first 2 were great boards that I still use a lot. But then I bought a lot of them that never delivered what they promissed. Only the XU4 and NanoPC T3+ were great. I started to get them for free to review starting with the NanoPi M4, and those were again very good. Only bought the Odroid N2 after that. Good I review SBC's, I'm saving myself a lot of money now I've spend enough in the past on them. Cheers

Humble apologies to Martin and Tido. I ask for advice and don't take it. There is a reason, age, if I patch things and it works, sure as hell in a few weeks when I want to make a change I'll have forgotten or lost the links to the changes. I have wired in the PCF8574, it works with no changes to the system. Crazy, when all those pins are sticking out of the Rock64, defeatist maybe but it is working, I understand what is going on and I can tidy things up now. If Armbian ever fixes the GPIO I would pull out the 8574 and go direct. It's tidier.

I must admit to enjoying freecell. Everything is looking like a fudge. I've looked at all the links and all basically say "this does not work properly". I returned a Tinker Board soon after they came out, I assumed that with the name ASUS on it that it might work, but no. The Rock64 tried the same job, screwed on the back of a TV for watching bike racing via Eurosport. That failed too, not reliable. A bog standard second hand Dell running Mint works faultlessly. Eurosport seems to lack enough servers for race day internet and the little boards ( inc RPi ) can't buffer it sufficiently. I do have an LCD running on the i2c bus, as a last desperate move I could add an PCF8574 expander board and use that to pulse the start SIM900 signal. In fact this is probably the best idea, it's using a service that is properly implemented. Watch this space. Just as a matter of interest, this is what is running perfectly right now: mosquitto - brokering many ESP8266 boards 20x4 LCD on i2c - status display so monitor can be turned off. SIM900 - send/receive text messages with no changing ip address problems Android phones/tables works well with mosquitto.

Not quite for the moment but it's looking hopeful. It's very frustrating but I'm retired and this keeps my brain going. Everything has been developed on a Mint PC ( apart from this one control signal ). Move it to an RPi and it drops incoming serial chars. Move it to the Rock64 and it works like the PC then I hit this GPIO problem. Do your libraries still hit the sudo GPIO problem ?

Thanks for a quick reply Martin. You have replied to someone who has spent half a lifetime programming embedded systems since before MSDOS. Linux is new to me, I jumped to Mint when W10 got totally intolerable. ( before MSDOS - that would be 6809 FLEX ) I have many pythons in bin/ I'm using idle-3.5 so do I copy from python python3.5 or python3.5m ? where <same_group_as_user> is the same group as the user you wish to grant gpios: user is me "brian" and there is a group "brian" So - chown root:brian /usr/bin/python-suid ?? Then I'd call "python3-suid MQTTsms2.py" sort of thing. Will this work in idle3 ? Sorry for all the questions, it's working so well I don't want to screw it up at this stage. Rock64 is hard work, I've had so many failures.

https://www.armbian.com/rock64/ Scroll down. All works as AP just fine.

Can anyone recommend a usb adapter that works with Armbian on Rock64 wifi access point/hotspot. I tried a few I had but none work as access point. Thanks

Rock64. Running mosquitto. Running my python script for home automation, measures temps, does a bit of control and uses an SIM900 for SMS outside access with no IP address issues. I've run this for ages with an Rpi doing mosquitto and an ESP8266 doing the SMS part. I tried using the RPi for everything but it can't keep up with the 19200b SIM900. The Rock64 does it beautifully. So, all works beautifully but for pulsing the SIM900 to power it up. I have R64.GPIO which works only if I sudo into idle or python. Otherwise I get the dreaded "cannot export GPIO". So close, so far. My eyes and the lcd are dim from searching for an answer. Trying to add me to gpio results in no gpio found. Surely there's a one line answer to this ?

I did builds for RockPro64 and RockPi4B. The latest will need fix for DTB filename. I've also done preliminary trial for OPi-RK3399 and NanoPCT4, this latest also needs tweak of DTB filename. EDIT : For NanoPCT4, it doesn't boot with new DTB, searching for rootfs and get mmc errors, I'm using old 5.1.y DTB for now and will investigate latter. EDIT2: Rock64 is fine without any glitch.

@lanefu Sorry, I forgot to share my benchmark file. I did find out that 7-zip multicore results are not to be trusted on SBC's with different cluster performance. The VIM3 has a very big difference so it only uses 500% of 600%. The N2 has a smaller difference in performance between A73/A53 so uses 550% in 7-zip multicore scores. (also lack of memory is a problem) CPU Miner is good, 7zip single core benchmarks are good. And for me Blender is important too. Reasons why benchmarks can be misleading ---------------------------------------- throttling 32-bit/64-bit Difference in cores A53/A7/A15/A72 distro (ubuntu/debian...) distro version kernel version driver versions compiler version software version/outdated repositories desktop Mate/Xfce/LXDE/... display resolution/headless background processes cpu clockspeed ram clockspeed/latency ram useage/swap/zram process sheduler optimizations for the system/distro crypto engine for encryption Undervoltage config settings Wifi dongle CONFIG_HZ=250 - 1000 or any other 7-zip works a bit better on 32-bit vs 64-bit, it doesn't use all cores at 100% in multi-core scores. The percentage differs with different distro's and boards. So it's not completely exact. 7-zip has problems with big-LITTLE architecture for multi-core benchmark. Better to test the clusters seperately. Blender works a lot better on 64-bit than on 32-bit. It uses 100% of the cores. CPU Miner only works on 64-bit. Works better in Ubuntu Bionic than in Debian Stretch. Blender : BMW render @ 1080p 7-zip : Numbers are average of 3 of decompressing only All tests are done with a fan when necessary so no throttling occurs. 64-bit SBC's Khadas VIM3 |SBC bench result |CPU Miner |7-zip s/c A53 |7-zip b/c A73 |7-zip multi avg. of 3 |Blender Ubuntu 18.04.02 http://ix.io/1MFD 13.10kH/s 1577 2311 10578 42m51s Armbian@1.9S.C./1.7B.C. http://ix.io/1NRJ 48m45s Odroid N2 |SBC bench result |CPU Miner |7-zip s/c A53 |7-zip b/c A73 |7-zip multi avg. of 3 |Blender Ubuntu Bionic http://ix.io/1Brv 11.35kH/s 1564 1879 9988 50m28s NanoPC T3+ |SBC bench result |CPU Miner |7-zip s/c |7-zip b/c |7-zip multi avg. of 3 |Blender Armbian Bionic http://ix.io/1iRJ 10.99kH/s 1290 10254 1h10m25s Arbmian Stretch http://ix.io/1qiF 8.55kH/s 1275 10149 1h13m55s Rock Pi 4B |SBC bench result |CPU Miner |7-zip s/c |7-zip b/c |7-zip multi avg. of 3 |Blender Ubuntu http://ix.io/1uVr 9.50kH/s 1242 1818 7802 1h17m22s NanoPi M4 |SBC bench result |CPU Miner |7-zip s/c |7-zip b/c |7-zip multi avg. of 3 |Blender Armbian bionic hz1000 http://ix.io/1nLh 10.23kH/s 1335 2005 8352 1h13m50s CONFIG_HZ=250 http://ix.io/1BLW 10.45kH/s 1335 2007 8320 1h08m28s Armbionic@1.4/1.8 hz250 1253 1828 7821 1h12m52s Armbian bionic nightly http://ix.io/1pDo 10.24kH/s 1329 1990 8292 1h13m28s Armbian stretch desktop http://ix.io/1odF 8.66kH/s 1350 1977 8400 1h14m12s Armbian stretch dsk nightly //ix.io/1pM0 8.80kH/s 1359 1993 8500 1h15m04s Armbian stretch core no fan //ix.io/1pKU 8.80-8.65kH/s 1353 1989 8461 Armbian stretch core //ix.io/1pL9 8.76kH/s 1354 1988 8456 Armbian stretch core nightly //ix.io/1pLf 8.82kH/s 1357 1994 8494 Lubuntu Bionic arm64 http://ix.io/1oGJ 9.24kH/s CPU Miner 1056 1551 6943 1h28m13s Lubuntu Bionic armhf http://ix.io/1pJ1 1111 1769 7705 2h02m54s Lubuntu Xenial armhf http://ix.io/1oCb 989 1507 6339 2h20m51s Khadas Vim2 Max |SBC bench result |CPU Miner |7-zip s/c |7-zip b/c |7-zip multi avg. of 3 |Blender Ubuntu Xenial http://ix.io/1qkA 6.86kH/s 823 1134 6682 1h14m39s 7-zip only 600% of 800% used Odroid C2 |SBC bench result |CPU Miner |7-zip big core |7-zip multi avg. of 3 |Blender Armbian Stretch Core http://ix.io/1pZu 4.65kH/s 1390 5342 Armbian Stretch Core Nightly //ix.io/1pZJ 4.66kH/s 1391 5340 Armbian Stretch Desktop http://ix.io/1q1C 4.65kH/s 1394 5363 Armbian Stretch Desktop NGHT //ix.io/1p02 4.59kH/s 1394 5356 2h38m18s Meveric Stetch No-OC 1337 5223 2h40m00s Meveric Stretch Only RAM OC 1361 5292 Meveric Stretch OC 1548 6049 2h14m17s Ubuntu Mate Bionic http://ix.io/1q2S clocked to 100Mhz 2h35m10s Ubuntu Mate Bionic OC Doesn't work/Clocked to 100Mhz 1607 5960 2h10m21s Rock64 |SBC bench result |CPU Miner |7-zip small core |7-zip multi avg. of 3 |Blender Armbian Stretch 1.5Ghz http://ix.io/1nCj 4.06kH/s 1406 5407 3h00n32s OLD Armbian Stretch 1.3Ghz //ix.io/1iHB 3.80kH/s 1211 4904 Armbian Bionic 1.5Ghz core //ix.io/1qbK 5.00kH/s 1384 5379 Armbian Bionic 1.5Ghz dsk //ix.io/1qcb 4.94kH/s 1379 5326 2h55m56s 32-bit SBC's Odroid XU4 |SBC bench result |7-zip s/c |7-zip b/c |7-zip multi avg. of 3 |Blender Debian Jessie http://ix.io/1q6X 950 1653 8823 1h12m19s Ubuntu Bionic http://ix.io/1qbL 1219 2094 9395 1h44m19s Asus Tinker board |SBC bench result |7-zip big core|7-zip multi avg. of 3 |Blender Tinker OS 9.5 Stretch http://ix.io/1pRN 1983 7536 2h55m00s Raspberry Pi 3B+ |SBC bench result |7-zip small core |7-zip multi avg. of 3 |Blender Raspbian Default no fan http://ix.io/1q10 1471 5027 Raspbian Default http://ix.io/1q1Q 1411 5371 5h47m31s Raspbian OC http://ix.io/1q5J 1591 6141 Ubuntu Mate Xenial http://ix.io/1q65 7-zip didn't work Software versions ----------------- GIMP Blender GTKPerf SysBench SBC-bench M4 : Lubuntu Xenial armhf 2.8.18 2.79b 0.40 0.4.12 0.6.1 Lubuntu Bionic armhf : 2.8.22 2.79b 0.40 1.0.11 LuaJIT 2.1.0-beta3 0.6.1 Armbian Stretch desktop 9.5 : 2.8.18 2.79b 0.40 0.4.12 0.6.1 Armbian Bionic : 2.8.22 2.79b 0.40 1.0.11 LuaJIT 2.1.0-beta3 0.6.1 Tinker : TinkerOS 9.5 Stretch : 2.8.18 2.79b 0.40 0.4.12 0.6.1 Odroid C2 : Armbian Stretch 9.5 : 2.8.18 2.79b 0.40 0.4.12 0.6.1 : Ubuntu Mate Bionic : 2.8.22 2.79b 0.40 1.0.11 LuqJIT 2.1.0-beta3 0.6.1 Doesn't work clocks to 100Mhz Meveric Stretch 9.5 : 2.8.18 2.79b 0.40 0.4.12 Doesn't work Rock64 : Armbian Stretch 9.5: 2.8.18 2.79b 0.40 0.4.12 0.6.1 : Armbian Bionic : 2.8.22 2.79b 0.40 1.0.11 0.6.2 RPi 3b+ : Raspbian Stretch 9.5 : 2.8.18 2.78a 0.40 0.4.12 0.6.1 Ubuntu Mate Xenial : 2.8.16 0.40 0.4.12 0.6.1 Odroid XU4 : Debian Jessie : 2.8.14 2.72b 0.40 0.4.12 0.6.1 7-zip doesn't work : Ubuntu Bionic : 2.8.22 2.79b 0.40 1.0.11 0.6.2 NanoPC T3+ : Armbian Bionic : 2.8.22 2.79b 0.40 1.0.11 0.4.6 Armbian Stretch : 2.79b 0.40 0.4.12 0.6.2 Khadas Vim2 Max : Ubuntu Xenial : 2.8.16 2.76b 0.40 0.4.12 0.6.2 CPU Clocks ---------- Khadas VIM3 : Ubuntu Bionic : 2x1.8Ghz(A53) + 4x2.2Ghz(A73) 64-bit Odroid N2 : Ubuntu Bionic : 2x1.9Ghz(A53) + 4x1.8Ghz(A73) 64-bit NanoPi M4 : Armbian Bionic/Stretch : 2x2Ghz + 4X1.5Ghz 64-bit Lubuntu armhf/ARM64 : 2x1.8Ghz + 4X1.4Ghz armhf 32-bit / ARM64 64-bit Tinker Board : TinkerOS Stretch : 4x1.8Ghz 32-bit Odroid C2 : Armbian Stretch : 4x1.5Ghz 64-bit Ubuntu Mate Bionic : 4x1.5Ghz RAM 912Mhz 64-bit Ubuntu Mate Bionic OC : 4x1.75Ghz + RAM 1104Mhz 64-bit Rock64 : Armbian Stretch : 4x1.5Ghz 64-bit Armbian Bionic : 4x1.5Ghz 64-bit RPi 3B+ : Raspbian Stretch : 4x1.4Ghz no fan 4x1.2Ghz above 60°C 32-bit Raspbian Stretch OC : 4x1.570Ghz over_voltage=4 core_freq=500 sd_freq=510 32-bit Ubuntu Xenial : 4x1.4Ghz 32-bit Odroid XU4 : Debian Stretch : 4x1.4Ghz + 4x1.9Ghz 32-bit : Ubuntu Mate Bionic : 4x1.5Ghz + 4x2Ghz Underclocks when above 75°C 32-bit NanoPC T3+ : Armbian Bionic : 8x1.4Ghz 64-bit Some benchmark tools can give an estimate of the performance. But they are never an exact reflection.

Add me to the list. Currently I've reluctantly solved by moving the SSD to the USB2 port, which nulls one of the main reasons for having chosen the Rock64. However, I have this idea that the problem is not the kernel, but u-boot which does not properly initialize the USB3 port. It is a fact that sometime you are able to boot from USB3, as long as you have no other current-dragging devices connected (included the HDMI cable). It is still a shot in the dark, i.e. will mostly fail, but if you have other devices connected, in my own experience, there is 0% possibility that the boot from USB3 succeeds. And no, using an USB3 hub does not make any difference, I agree.

Hello, I have a Rock64 V2 which I am using as a Tvheadend server, among other stuff. For some months I put the kernel/dtb packages on hold, because I discovered that linux-image-rockchip64 after version 5.75 did not include the kernel module for th USB DVB-T stick I need (an EyeTV DVB-T device, i.e. a clone of Hauppauge), that is dvb-usb-dib0700 or the like (I am trying to remember). I have recently unhold the Linux packages and let apt to update them. Now at version 5.90, I see that the kernel module is still not included, and my USB device cannot be used. Going back to Linux image 5.75 makes the stick to work again, but I'd like to have the latest versions running. Questions: 1) Am I missing an extra package? 2) How can I get back on driver? (Well, a third one would be why it has been removed from the latest versions) Thanks!

I have left it running now for a few weeks and it runs fine. It did error out on one update and I rebooted it and updated it again and it is fine. NOTE: this is only for the T95Z Max S912 TVBox. Thinking though of freezing the updates now on it.... _____ ___ ____ _____ ____ ___ _ ____ |_ _/ _ \| ___|__ / / ___|/ _ \/ |___ \ | || (_) |___ \ / / \___ \ (_) | | __) | | | \__, |___) / /_ ___) \__, | |/ __/ |_| /_/|____/____| |____/ /_/|_|_____| Welcome to ARMBIAN 5.73 stable Ubuntu 18.04.2 LTS 3.14.29 System load: 1.45 1.29 1.22 Up time: 18:57 hours Memory usage: 10 % of 2733MB IP: 192.168.244.250 CPU temp: 35°C Usage of /: 29% of 29G [ Menu-driven system configuration (beta): sudo apt update && sudo apt install armbian-config ] Last login: Wed Jul 3 20:46:17 2019 from 192.168.244.232 root@HS3-ATL:~# Note that I updated the release version to indicate that it is a S912 as it kept going to showing a Rock64 on the update. I also found that I had a bad SD card running for a while which caused me much grief. This box is running Home Assistant, HomeSeer, Node Red, Mosquitto, Leviton OmniLinkBridge (MQTT) and testing with a Digi 8 port edgeport. So in addition it is running a connection to a UPB controller, ethernet ZWave, RFID. I am testing a LoRa RFID connection via two transievers with a range of 8 Km. I do not know what dtb file it is using cuz it is not in the uEnv.ini file such that it is using defaults. root@HS3-ATL:/boot# ls aml_autoscript fan.sh aml_autoscript.zip hdmi.sh armbianEnv.txt Image armbianEnv.txt.out initrd.img-4.4.182-rockchip64 armbian_first_run.txt.template s905_autoscript boot.cmd s905_autoscript.cmd boot.scr System.map-4.4.182-rockchip64 config-4.4.182-rockchip64 uEnv.ini dtb uInitrd dtb-3.14.29.old zImage dtb.old root@HS3-ATL:/boot# cat uEnv.ini bootargs=root=LABEL=ROOTFS rootflags=data=writeback rw console=ttyS0,115200n8 console=tty0 no_console_suspend consoleblank=0 fsck.fix=yes fsck.repair=yes net.ifnames=0 mac=${mac} It just works fine as an Ubuntu server for automation. I have no keyboard, mouse or HDMI monitor connected to it. Note that the kernel is old: root@HS3-ATL:/boot# uname -a Linux HS3-ATL 3.14.29 #26 SMP PREEMPT Sun Jul 29 11:26:15 MSK 2018 aarch64 aarch64 aarch64 GNU/Linux It is only for this model TVBox S912. Rest of the S912 boxes are running with newest kernels just fine. IE: when trying a new kernel on this one the Gb NIC wasn't working and only wireless and bluetooth worked. Download and install this build for this box to work. (note that I never tried WLAN or Bluetooth with it and do not need it). It is listed as Armbian_5.44_S9xxx_Ubuntu_bionic_3.14.29_server_20180729.img.xz dated 07292018. Going to kernels 4.X and 5.X did not work for me with this specific device. Never did boot it to Android or even looked. Maybe my approach was wrong? Any guidance on updating Android and extracting DTB file for use with Armbian would be appreciated. Just purchased a second BeeLink BT3 Pro here. NOT for TV rather just for Automation. Got the first one new for $65 and second one for $100. It is not worth the $150 that Amazon is selling them for. I do now see a similiar to BeeLink BT3 pro with an SSD card slow underneath for around $100. For KODI use have settled on using CoreElec with an old kernel just for the HD 4K features. For server use and no video have settled on currently posted kernel. Still liking the footprint versus the RPi (even the RPi 4).

@Igor :-/ @arox speaking personally (not "for Armbian") the Rock64 is a troubled piece of hardware, there are 3 revisions in the wild, each one with differences not addressed by the vendor to work together. Other options with more consistency and a bit more conservative release approach will yield better results.