Search the Community

Rock64 is cheap. It`s got Gb Ethernet, USB3, better ram, 64-bit os`es, eMMC socket, 4x1.5Ghz... The RK3399`s are blazing fast, also all the things the Rock64 has, but faster and even more. I like the Rock Pi 4b the most, there are many other choices. As Tony sais, the Raspberry`s are not very good. Undervoltage, lying about clockspeeds, slowest ram, unstable, and the biggest problem, a community of only trolls. When real problems are shownthey laugh you out and change what you`ve written in their forum. Here some video`s to help you in your choices: Video that shows the Raspberry £B+ doesn`t show the real clockspeed. https://www.youtube.com/watch?v=dDWv0A36W9s&t=2s Review of the Rock64(it has gotten better, now it`s really 1.5Ghz) https://www.youtube.com/watch?v=_oX7TabSROw&t=306s Review of the NanoPi M4 https://www.youtube.com/watch?v=rgj9mR6Pl04 Review of the Rock Pi 4B https://www.youtube.com/watch?v=5eV-uPOyVlg&t=2s Review of the Odroid C2 (old, but still good) https://www.youtube.com/watch?v=8_wmQN00vW8&t=1s

Last note on eMMC https://github.com/ayufan-rock64/linux-mainline-kernel/commit/686e1f1aa461afd4100a18f0374a59e86b23069b

I've done a build for Rock64 too, it's eMMC working too, but since there is no native WiFi there, I've a RTL8188ETV dongle ... It's connection seems to fail while it wasn't on 4.19.y ...

Bummer. Was there a few items merged into 4.19? Before posting this I did a quick double check and I see Ayufan has just released 4.20: https://github.com/ayufan-rock64/linux-mainline-kernel/releases His 4.20 doesn't boot for me but 4.19 release does and seems reliable across a few boots! Last I looked 4.19 was in RC. I'm going to run with the released 4.19 and see if can get everything standing up. Also it looks like some of the drivers I was after are now built into the kernel instead of as modules too. `xt_set` is missing but I may not use Weave for K8s this time or maybe it's time to retry building again. FWIW a fresh Armbian ./compile.sh built 4.19 rc4 again this morning. I'm not sure if this is correct as it did a checkout of Ayufan mainline kernel. Maybe there is a flag somewhere. `dpkg-deb: building package 'linux-source-4.19.0-rc4-dev-rockchip64' in '/home/vagrant/armbian/.tmp/linux-source-dev-rockchip64_5.68_all.deb'.`

Mainline has been a bit of a problem for Rockchip and the RK3328, however let me review the dev images/builds as well, and likewise, can you get the UART debug output / armbianmonitor -u output before and (if possible) after upgrade? I increased the drive level used to interface to the SD on the 4.4 kernel, but I don't think I did on the mainline, there could be some corruption happening due to malformed bits getting to the SD card. If the DTS changed to include higher speed modes, it would kill it for sure not to use 8 mA instead of 4. https://github.com/ayufan-rock64/linux-kernel/commit/501b604fcb0b317e82be21183f764bc3e4e1f519

Hi everyone, Big fan of debian based distro's. Have six Rock64's and looking for a newer kernel (4.9+) with default Ubuntu modules list. 3 have eMMC cards and 3 using the Pine64 USB->SATA adapter with SSD drives. I have powered usb hub, y cables, etc but am using USB2 without powered hub because it's reliable as is and USB3 boot with any distro power injection seems unreliable. Not too concerned about throughput. Ayufan's release bionic-minimal-rock64-0.7.11-1075-arm64.img.xz with 4.4 is very stable on these. However Ayufan's mainline kernels after 4.4 are stripped right back. I spent a couple days compiling kernels with Ayufan's 4.4 module set and variations merged with Ubuntu etc but never got a stable build happening. So I've been trying out Arch Linux and it was stable with 4.18 but not supported by the tools I want to use (kubespray, other ansible playbooks). I went through a converted a bunch of my Ansible stuff to suit both Ubuntu and Arch but kubespray is a beast and decided too much effort (also they don't want to support Arch if do PR which is fair enough - github issue by someone else). This led me to Armbian. I see there are later kernels here: https://apt.armbian.com/pool/main/l/ Before getting to this I put extracted Armbian_5.65_Rock64_Ubuntu_bionic_default_4.4.162.7z (.img) onto one of the SSD's with `dd`. It booted the first time, but wouldn't boot the second time. Re-`dd`ed the image on there. Any `apt upgrade` or just `reboot` would prevent future boots from happening. Tried downgrading to 5.59 without luck. Eventually got it to boot again but not sure what was different, then tried updating kernels and all was fine. Tried dd back to 5.65 and stuck again. Keep getting various crashes even after dd image again. Have tried powered USB for SSD's as well even though not needed with ayufan bionic build. Having a go at building new img now with the dev kernel to see if that will boot more reliably. The docs are great, thanks for all the hard work on this, I know the SBC manufacturers don't make it easy to get all these devices going and well supported by mainline. Any suggestions would be most welcome.

USB3.0 boot is problematic for me with 6x Rock64's, 3 SATA->USB, Y cables and powered hub or not. Using USB2 is reliable for booting from USB with Ayufan's bionic image. I seem to get constant kernel crashes on boot with Armbian 4.4.162 though.

Hello, I'm new to Armbian which i just installed on a Rock64 board (Armbian_5.65_Rock64_Ubuntu_bionic_default_4.4.162.7z). I have to say that my first impressions are that Armbian is a nice Os and that this is the one that causes me the less troubles on the Rock64 to install and to start. My goal is the write/port an application in C++ preferably by using Qt. Here, it is the problem. I tried to install it using command: sudo apt-get install qtcreator sudo apt-get install qt4-designer "Qt 4 Designer" seems installed correctly and seems working properly. Qt Creator was not installed completely, the IDE is installed but there is no kits installed (nor Qt4.8, nor Qt5.x). I was not surprised because during the execution of "sudo apt-get install qtcreator", some errors happened; below the text of the error: Setting up nodm (0.13-1.3) ... Job for nodm.service failed because the control process exited with error code. See "systemctl status nodm.service" and "journalctl -xe" for details. invoke-rc.d: initscript nodm, action "start" failed. ● nodm.service - Display manager for automatic session logins Loaded: loaded (/lib/systemd/system/nodm.service; static; vendor preset: enabled) Active: activating (auto-restart) (Result: exit-code) since Thu 2018-12-27 16:51:04 CET; 26ms ago Docs: man:nodm(8) Process: 18678 ExecStartPre=/bin/sh -c [ "$(cat /etc/X11/default-display-manager 2>/dev/null)" = "/usr/sbin/nodm" ] (code=exited, status=1/FAILURE) dpkg: error processing package nodm (--configure): installed nodm package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: nodm E: Sub-process /usr/bin/dpkg returned an error code (1) I also see such error implying "nodm.service" (?) during the install of other packages. Someone can help? Regards Pascal

Thank you @balbes150 and Armbian team for making it possible for these tv boxes and sbc. A little background, I've found Armbian when I search for a good os for my odroid c1, then it serves as file and dnla server since. I also have a s905x box and I put LibreElec because I like how complete the os for that box; graphic, sound, wifi... When the S905X2 box come out (Beelink GT1 mini), I thought it's an upgrade to what I already have and the CPU is similar, then I get it and later found out that it a completely new cpu and there're no linux for it yet. However, I think there will be support in the future. I really want to have a nice Armbian box, I decided to get Beelink A1 (rk3328, GbE, USB3, 4GB ram, 32GB Rom) instead of rock64 for similar price. I like this beelink box because how small and come with complete set. Now I can run armbian and got to desktop when using rk3328-box.dtb but I have no ethernet, wifi and bluetooth. Other thing seems to work fine. So can you guide me how can I get a correct dtb for my box? And my box has etl8821cu, can I compile it somewhere else and load it in armbian? I can edit dts and convert to dtb.

I forgot this came up in this topic, I have modified the rk3328.dtsi to use 8mA drive strength on all rk3328 boards, that will fix the issues for most users as far as the electrical interface is concerned (it is default 4 mA). 12 mA is available, if someone spends enough time rigorously testing to determine it's needed (probably edge cases with crappier than normal cards or poorly routed designs with too much capacitance) Rock64 was having the same complaints. https://github.com/ayufan-rock64/linux-kernel/commit/501b604fcb0b317e82be21183f764bc3e4e1f519 For S905X, I'm afraid I haven't found a way to change the output drive level.

I'm trying to build working player for this board via mpv or gstreamer. (spoiler - i failed). Here is total list of command (ubuntu commads.txt) i have tried to make this work. First i load all the library that ever may be needed (is that error?), then i has downloaded github master version of libmali+mpp+rockchip-gstreamer+rockchip-gstreamer-extra+ffmpeg+mpv+mpv-build. Then i did for libmali cd libmali && cmake CMakeLists.txt && make && make install && ldconfig for mpp cd mpp && cmake -DRKPLATFORM=ON -DHAVE_DRM=ON && make -j4 && make install && ldconfig for gstreamer there was a bit of change, since rkximage seems to be main idea behind all players commands i found around, so instead of ./autogen.sh --disable-rkximage && make i did nano gst/rkximage/rkx_kmsutils.c and changed DEF_FMT(NV12_10, P010_10LE) to DEF_FMT(NV12, P010_10LE) Yes, i have only roughly idea that this line was for 10 bits (maybe?), but my knowledge limited to googling and i failed to google how to actually fix it, so i did that. At least it complied. Then i did ./autogen.sh && make -j4 && make install && ldconfig and same thing for gstreamer-rockchip-extra nano gst/rkximage/rkx_kmsutils.c and changed DEF_FMT(NV12_10, P010_10LE) to //DEF_FMT(NV12_10, P010_10LE) nano gst/kms/gstkmsutils.c DEF_FMT(NV12_10, P010_10LE) to //DEF_FMT(NV12_10, P010_10LE) This video goes fine This video slideshow. This video results in ** (gst-play-1.0:24108): CRITICAL **: 15:20:22.782: gst_dmabuf_memory_get_fd: assertion 'gst_is_dmabuf_memory (mem)' failed Using gstreamer-rockchip from here doesn't solve anything. mpv...Just building it with correct flags and libmali doesn't do any good and results and errors like This https://github.com/ayufan-rock64/linux-build/blob/master/recipes/video-playback.md allow me to start 4k60fps as..30 fps video, but it's still fails on 10 bits refusing to show anything with this But maybe someone already walked this path and know how to make 10 bits video work on any kind of image of Linux with gstreamer or mpv? 8 bits can be player up to 4k60fps..but 10 bits? just black screen on any image except Libreelec from firefly site

OK, as this will give me the opportunity to see if 4.19 has the same i2s issues as explained to @TonyMac32 Count me in for the dt overlay and es90x8q2m alsa driver I contributed to the Asus TinkerOS kernel for Volumio's primo box (see https://volumio.org/blog/) However, I do not know in detail what else Asus initially changed to get PI compatible DACs to work with the Tinkerboard MCLK. This will need some digging. This DT overlay work will also get very interesting for Volumio and the Rock64. An upcoming board revision is going to to fix the RPi 40-pin gpio compatibily and then opens potential for a range of popular RPi compatible DACs.

Are you sure ? Last build I've done a week ago, we were using https://github.com/ayufan-rock64/linux-u-boot branch.

Currently running Armbian_5.67_Rk3328-tv_Ubuntu_bionic_default_4.4.143_desktop_20181203 on A5X Max - RK3328 4gb ram At the moment top cpu freq is 1.3GHz booting with rk3328-evb.dtb Using dtc I had a look at rk3328-rock64 and it had an entry for 1.5GHz, so I copy pasted that into rk3328-evb and successfully booted. cpufreq-info does show max freq as 1.5GHz but unfortunately unable to switch to it. Any pointers to make it happen?

Hi Tido, Thank you for the reply. I understand what you said but the reason I posted this is because I installed armbian on my Rock64 and then ran the dietpi script. I just don't understand what this error code means sicne it contains the armbian local paths. Apart from dietpi forum. Can you help me identify this error at least? Thank you

Hello, when I run dietpi-software and select some software to install, it gives me this error. Can someone help me? I had to install armbian on my Rock64 and then ran the install dietpi script. Thank you DietPi-Software: G_AGUG │ - Exit code: 100 │ - DietPi version: v6.19.6 (Fourdee/master) | HW_MODEL:22 | HW_ARCH:3 | DISTRO:4 │ - Image creator: Dev │ - Pre-image: armbian │ │ Log file contents: │ Reading package lists... │ Building dependency tree... │ Reading state information... │ Calculating upgrade... │ 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. │ 1 not fully installed or removed. │ After this operation, 0 B of additional disk space will be used. │ Setting up initramfs-tools (0.130) ...^M │ update-initramfs: deferring update (trigger activated)^M │ Processing triggers for initramfs-tools (0.130) ...^M │ update-initramfs: Generating /boot/initrd.img-4.4.162-rockchip64^M │ /etc/initramfs/post-update.d//99-uboot: 3: .: Can't open /etc/armbian-release^M │ run-parts: /etc/initramfs/post-update.d//99-uboot exited with return code 2^M │ dpkg: error processing package initramfs-tools (--configure):^M │ subprocess installed post-installation script returned error exit status 1^M │ Errors were encountered while processing:^M │ initramfs-tools^M │ E: Sub-process /usr/bin/dpkg returned an error code (1) │ │ │ │ Unable to continue, DietPi-Software will now terminate.

I have the same issue and i "solved" it using a usb3 hub between the drive and the rock64, its more like a workaround than a fix but maybe it can help you too, in my case said hub can be powered but its not relevant since the issue goes away no matter if i power it or not...and its a noname hub, if you need any extra information tell me how...also i dont have a serial interface yet, gonna get one in a week or two when i have some extra time... I commented about this on the same post you reference on the ayufan github...

On Rock64, I use youtube-dl CLI app.to download the video (720p) during my off-peak bandwidth time, and watch with MPV or VLC later in fullscreen (1920x1080). It plays OK, but this drives the temperature up to 89-92 ! This is a monitor of the results: http://davekimble.net/problem.video.replay.txt . I think the dropped frames are because of 25 fps v 60 fps of the monitor. I know it is a lot of work, but any ideas for reducing the workload welcome. Anybody else get this?

I had to recompile the Armbian kernel for the DS1307 RTC Module. The details are in this thread: https://forum.armbian.com/topic/8856-solved-how-to-add-an-external-rtc-module-to-rock64-board/

ROCK64 is a RK3328 Quad-Core ARM Cortex A53 board with up to 4 GB of RAM. Unfortunately it has a non-functional RTC (/dev/rtc0), which is not battery backed. If your board is not connected to internet 7/24, you can not use the NTP or systemd-timesyncd. Therefore you need to connect a battery-backed external RTC module to the ROCK64 header, and get the time via the i2c protocol. The good news is, the GPIO headers on ROCK64 is compatible with Raspberry Pi headers. Therefore almost any Raspberry Pi RTC module will work on ROCK64. But you need to do some tweaking to communicate with the RTC module. I will explain the required steps which worked for me. 1. Buy an external RTC module for Raspberry Pi, preferably with DS1307 chip. Here is an example: https://www.abelectronics.co.uk/p/70/rtc-pi 2. Install i2c-tools package: sudo apt-get install i2c-tools 3. Connect the RTC module to the board as in the attached picture. 4. Right now, you can not probe the RTC module, because most of the GPIO headers on ROCK64 board is disabled by default. (See https://github.com/ayufan-rock64/linux-build/blob/master/recipes/additional-devices.md for details.) Therefore if you try to probe i2c-0, you will get the error below: root@rock64:~# sudo i2cdetect -y 0 Error: Could not open file `/dev/i2c-0' or `/dev/i2c/0': No such file or directory Ayufan wrote a nice script named "enable_dtoverlay" to enable the GPIO headers on-the-fly. Here is the link: https://raw.githubusercontent.com/ayufan-rock64/linux-package/master/root/usr/local/sbin/enable_dtoverlay Download this script and copy it under /bin and make it executable. We will enable "i2c-0" with this script, which we need for the RTC module. The command to enable i2c-0 is as follows: /bin/enable_dtoverlay i2c0 i2c@ff150000 okay After you run this command, /dev/i2c-0 becomes available, and we can probe it via the command below: root@rock64:~# sudo i2cdetect -y 0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- If you see the number 68, you are on the right track. 5. Now we need the kernel driver for DS1307. Unfortunately DS1307 driver is not available with armbian kernel (see below). root@rock64:~# cat /boot/config-4.4.162-rockchip64 | grep DS1307 # CONFIG_RTC_DRV_DS1307 is not set So we need to recompile the Armbian kernel with this option enabled. I will not cover the steps to compile the kernel, you can find it here: https://docs.armbian.com/Developer-Guide_Build-Preparation/ Let's hope @Igor or any other Armbian developer will enable this module by default, and save us from this burden. After we compile the kernel with DS1307 driver, we are almost done. We need to tell the kernel that a DS1307 chip is using the i2c-0. Here is the way to do that: echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-0/new_device After we execute this command, /dev/rtc1 becomes available, and points to our external RTC module. Please note that /dev/rtc0 is the onboard RTC, which does not work, and should be avoided. We need to update the date/time information from the system for the first time. Here is the command to do that: hwclock --rtc /dev/rtc1 --systohc Now our external RTC clock is set, and ready to take over NTP. 6. Edit /lib/udev/hwclock-set. Find the lines below, and update as shown: if [ -e /run/systemd/system ] ; then # exit 0 /bin/enable_dtoverlay i2c0 i2c@ff150000 okay echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-0/new_device fi 7. Edit /etc/rc.local, add the following lines to set the system clock for every boot: /lib/udev/hwclock-set /dev/rtc1 8. Disable the below services, as we don't need them anymore: systemctl stop systemd-timesyncd.service systemctl disable systemd-timesyncd.service systemctl stop fake-hwclock.service systemctl disable fake-hwclock.service 9. Reboot and enjoy your RTC module.

I have an external RTC module, which I bought from from AB electronics for my Rasberry Pi (see https://www.abelectronics.co.uk/p/70/rtc-pi). As the pinouts for Raspberry Pi and Rock64 are same, I can connect this RTC module to the ROCK 64 board and i2cdetect detects the module with some minor tweaks. The only missing part is the DS1307 kernel driver. I can change the armbian config and compile my own kernel, but I don't want to do that again and again whenever the kernel gets updated. Therefore if the CONFIG_RTC_DRV_DS1307 option is set to "m" in the default config, every ROCK64 owner can use DS1307 based external RTC modules with the default armbian kernel. I can even write a howto for that.

Gentlemen, I have a rock64 board, and I would like to use an external RTC module with DS1307 chip. Unfortunately the armbian kernel does not provide DS1307 driver by default: root@rock64:~# cat /boot/config-4.4.162-rockchip64 | grep DS1307 # CONFIG_RTC_DRV_DS1307 is not set I don't have the programming skills for sending a pull request to enable this module. Could you please enable this module for ROCK64? I believe other ROCK64 owners may also benefit from this driver, as the board does not expose a working RTC, and DS1307 is a very common RTC chip. Thanks in advance.

So now I am playing with Rock64 4GB. I installed the Armbian_5.65 server edition OS and then installed xorg, lxde, and lxdm., then rebooted into a working system. Final stage of setting up was to test rhythmbox_3.4.2 and there was no sound. pavucontrol > playback shows the app is running and the worm is leaping about, but absolutely no sound. Same playing a .wav file with mpv, or indeed any player. Is there something unusual about the audio socket, or some other limitation. armbianmonitor -u = http://ix.io/ltt0

Yes, I have Rock64 working with I2C and a 20x4 LCD display like this one Aliexpress and the dbrgn/RPLCD under Python 3.6.6 (Ubuntu Bionic 18.04) : git clone https://github.com/bazooka07/RPLCD.git -b test-entrypoint-1811 ( I fix a little bug for the test ) I have too an ESP8266 (Nodemcu) and a OLed 0.96" display. I'm trying for running Oled with Rock64. The following library is working but don't keep the display on when I leave my script pip3 install luma.oled My script : #!/usr/bin/env python3 from luma.core.interface.serial import i2c, spi from luma.core.render import canvas from luma.oled.device import ssd1306 serial = i2c(port=1, address=0x3C) device = ssd1306(serial) with canvas(device) as draw: draw.rectangle(device.bounding_box, outline='white', fill='black') draw.text((30, 40), 'Hello World', fill='white') Don't forget to connect on i2c-1 pin #27 (sda) and pin #28 (scl) unlike RPI3

Sorry to resurrect an old thread! As a new Armbian user on Rock64, I found this thread while searching for a guide on how to boot from a usb device. After playing around with partitions and the armbian-config utility, I realized that after copying rootfs to the usb device, the board will still read from the /boot partition on the sd card, then will load rootfs from the external drive. If the board is powered on without the sd card, boot will fail. This method works fine for my purposes. If there is a way to configure the rock64 to read from a /boot partition on a usb device, I haven't found one. I hope this helps any other new folks like myself who want to run Armbian from usb/ssd on Rock64. Cheers!