Search the Community

The newest revision does not boot from current SD images. I'm working to debug why. If anyone else has a board and can test it out, let me know. The eMMC will boot, no problem, so it's just the SD itself. Model: Pine64 Rock64 DRAM: 1022 MiB MMC: rksdmmc@ff520000: 0, rksdmmc@ff500000: 1 SF: Detected w25q128bv with page size 256 Bytes, erase size 4 KiB, total 16 MiB *** Warning - bad CRC, using default environment In: serial@ff130000 Out: serial@ff130000 Err: serial@ff130000 Model: Pine64 Rock64 misc_init_r cpuid=55524b50303930343200000000051f1a serial=f55c6806c317581 Net: eth0: ethernet@ff540000 Hit any key to stop autoboot: 0 Card did not respond to voltage select! mmc_init: -95, time 9 switch to partitions #0, OK mmc1 is current device ** No partition table - mmc 1 ** starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: Core Release: 3.10a USB3: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 1 for devices... 2 USB Device(s) found scanning bus 2 for devices... 2 USB Device(s) found scanning bus 3 for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Device 0: unknown device ethernet@ff540000 Waiting for PHY auto negotiation to complete......... TIMEOUT Ideally getting old an new to boot would be ideal, @Igor this might mean a fragmentation for this board though, like having a V2 and older and a V3 and newer build if we can't make them all play nice with one bootloader.

I'm trying to run the example.cpp that comes with Pine64-CPP but I am throwing segmentation faults. The man-setup() call initialzes the board with the following if statement in the setup() function in gpio.cpp if((uint64_t)gpio_mem % PAGE_SIZE) and the this->gpioMap = statement that uses SUNXI_GPIO_BASE In the example code, I initialize the pin with man->pinMode (PI_GPIO_24, OUTPUT); The pinMode function in gpio.cpp, launches _setPullupdn with gpio=78 and pud = 1. As expected Inside _setPullupdn, the following is set bank= 2 index = 0 offset = 28 The segmentation fault seems to come from this line: regval = *(&pio->PULL[0] + index); I have a 4 GB Rock64 running the latest Armbian desktop from this site. sudo cat /sys/kernel/debug/gpio gives me GPIOs 0-31, platform/pinctrl, gpio0: gpio-0 ( |vcc_host_5v ) out hi gpio-2 ( |? ) out lo gpio-30 ( |vcc_sd ) out lo GPIOs 32-63, platform/pinctrl, gpio1: gpio-50 ( |mdio-reset ) out hi GPIOs 64-95, platform/pinctrl, gpio2: GPIOs 96-127, platform/pinctrl, gpio3: GPIOs 510-511, platform/rk8xx-gpio, rk8xx-gpio, can sleep: gpio-510 ( |? ) out lo gpio-511 ( |? ) out lo Anyone have any thoughts? Thanks.

Hi. I have problem with Rock64 and ICYBOX IB-RD2253-U31 (USB3.1 Raid Enclosure) Kernel: Linux rock64 4.4.167-rockchip64 #3 SMP Sat Jan 12 18:58:23 CET 2019 aarch64 GNU/Linux dmesg on ICYBOX connected: [ 3.112348] usb 1-1: New USB device found, idVendor=1234, idProduct=5678 [ 3.112362] usb 1-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1 [ 3.112368] usb 1-1: Product: ASM1352R-Safe [ 3.112374] usb 1-1: Manufacturer: Asmedia [ 3.112379] usb 1-1: SerialNumber: 123412341249 [ 3.113303] input: Asmedia ASM1352R-Safe as /devices/platform/ff580000.usb/usb1/1-1/1-1:1.0/input/input1 Rock64#lsusb -v -t -d 1234:5678 /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usbtouchscreen, 480M As you can see Mass Storage uses Driver=usbtouchscreen and I can't change it using udev mapping ACTION=="add", ATTRS{idVendor}=="1234", ATTRS{idProduct}=="5678", RUN+="/sbin/modprobe uas" RUN+="/bin/sh -c 'echo 1234 5678 > /sys/bus/usb/drivers/uas/new_id'" After udev: rock64:~# lsusb -v -t -d 1234:5678 /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usbtouchscreen, 480M On Debian9 x86_64 and RaspberryPi 2, ICYBOX work perfectly. Any ideas why it doesn't work on Rock64?

Hello, In december, it was possible to install 4.19 kernel for Rock64. Unfortunately this kernel was removed from Armbian repo. 4.20 kernel is bogus, USB doesn't work and SD card is very slow. 4.19 was fine. Is it possible to make it available again in in the repo ? Thank you

THE MEDIA SCRIPT IS NOW DEPRECATED, IN FAVOR OF THE OFFICIAL MULTIMEDIA FRAMEWORK. PLEASE REFER TO THIS TOPIC: And, for last, the first version of: The UN-official, UN-supported, UN-expected RK3328 MEDIA TESTING SCRIPT This is the first release of the RK3328 media testing script. The script provides a functionality similar to its RK3288/3399 equivalents, except for the OpenCL related stuff, which is not supported by the SoC. So it includes: Installing all the libraries and system configurations necessary for GPU accelerated X desktop, Chromium WebGL, full VPU video play acceleration up to 4k@60 10-bit HEVC (the maximum supported by the SoC), and GLES 2.0 support. Three video players supporting full VPU acceleration (RKMPP) and KMS display (GBM or a X11 DRM "hack", as described by the authors), namely: MPV, Gstreamer and Kodi. A library that will act as an OpenGL to OpenGL-ES wrapper, allowing you to run programs that use OpenGL 1.5-2.0. Two additional features, that have no big interest from the Armbian development prospective, but I find them interesting to play with: Chromium browser with support for Flash and DRM-protected commercial web video streaming (tested with Amazon Prime, should also work with Netflix, Hulu, etc.), and a simple Pulseaudio GTK equalizer using LADSPA. Here is a more thorough documentation: >>> DOWNLOAD LINK <<< Prerequisites: You need a fresh Armbian Bionic desktop image with default kernel installed. Instructions: Download the file above Untar it: tar xvf media-rk3328_*.txz cd media-script ./media-rk3328.sh Notes: This script is not officially supported by the Armbian project. It is just a community effort to help the development of the main build, by experimenting with a possible implementation of the media capabilities of this particular SoC. Therefore, questions about the script should not be laid out as support requests, but as commentaries or community peer-to-peer assistance. That being said, all commentaries/suggestions/corrections are very welcome. In the same way, I will do my best to help solve any difficulty that may arise regarding the script. Enjoy!

I see the latest images for the Rock64 are marked as desktop. I am looking for a lightweight server only version. I still have an older server version that I downloaded a while ago, specifically 5.59. If I install 5.59, can I do and apt-get update/apt-get upgrade to get to the latest version? Any issues with that approach? Thanks!

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.

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.

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

Can someone please help me understand how Armbian for Rock64 is developed? In the past, there was an image for the Rock64 that was a server image, not a desktop image. Now, I see Ubuntu and a Debian Stretch desktop images, no server image. Is there a plan to build a server image going forward? Also, will a newer kernel be built at some point? Not trying to stir the pot or cause trouble, just trying to understand where the Rock64 support is going in the future. Thank you for all the spectacular work the Armbian team does.

I have a Rock64 powered by Armbian version 5.60 kernel 4.4.162-rockchip64 Ubuntu Bionic How can I activate i2c0 and i2s0 ports for connecting a 16x2 characters LCD display like 1602LCD and a PCM5102 DAC ? I'm trying armbian-config and I'm reading https://docs.armbian.com/User-Guide_Allwinner_overlays/ but I'm getting no help. Thanks for advance.

Hello, I've followed the steps on the Rock64 Armbian download page to enable overclock on my Rock64 running Armbian Xenial 5.60 (rock64 4.4.124-rk3328), yet I can't seem to increase the CPU clock frequency. I've also checked the Documentation-> Fine Tuning page where the same steps are listed. Steps: sed -i "s/MAX_SPEED=.*/MAX_SPEED=1510000/" /etc/default/cpufrequtils systemctl restart cpufrequtils I've checked the CPU frequency now and it looks like it's stuck at the default value. Shouldn't the new CPU frequency now be listed as 1.51GHz by the below commands ? rock64:~$ cpufreq-info -c 0 cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 68.0 us. hardware limits: 408 MHz - 1.30 GHz available frequency steps: 408 MHz, 600 MHz, 816 MHz, 1.01 GHz, 1.20 GHz, 1.30 GHz available cpufreq governors: conservative, ondemand, userspace, powersave, interactive, performance current policy: frequency should be within 600 MHz and 1.30 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 600 MHz. cpufreq stats: 408 MHz:0.00%, 600 MHz:94.66%, 816 MHz:0.00%, 1.01 GHz:0.00%, 1.20 GHz:0.00%, 1.30 GHz:5.34% (285924) pi@rock64:~$ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 408000 600000 816000 1008000 1200000 1296000 pi@rock64:~$ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 600000 pi@rock64:~$ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 1296000 pi@rock64:~$ I've found this post on the forum related to overclocking the Rock64, alas it does not specify the steps to increase the CPU frequency. *** I am aware of the issues that CPU overclocking might bring, yet I am willing to test stability and share the results and I already have a heat sink and 5V fan in place. *** I am using the official Rock64 PSU (5V DC at 3A).

Armbian version: Armbian_5.65_Rock64_Ubuntu_bionic_default_4.4.162 the stuck prompt message: rock64 login: [OK] Started Update UTMP about System Runlevel changes. I MUST press enter key to continue the startup progress, please help me to fix the bug. Thanks very much

Working on the rockchip64 family dev images, since 4.19 is an LTS and the RK3328 support is somewhat workable. With a reminder of something I failed to read by @JMCC, I got this today: ____ _ | _ \ ___ _ __ ___ __ _ __ _ __| | ___ | |_) / _ \ '_ \ / _ \/ _` |/ _` |/ _` |/ _ \ | _ < __/ | | | __/ (_| | (_| | (_| | __/ |_| \_\___|_| |_|\___|\__, |\__,_|\__,_|\___| |___/ Welcome to ARMBIAN 5.65 user-built Debian GNU/Linux 9 (stretch) 4.19.0-rockchip6 4 System load: 0.99 0.55 0.22 Up time: 2 min Memory usage: 3 % of 2000MB IP: CPU temp: 40°C Usage of /: 2% of 117G [ General system configuration (beta): armbian-config ] New to Armbian? Check the documentation first: https://docs.armbian.com Thank you for choosing Armbian! Support: www.armbian.com Building a Rock64 test image as I write this, then checking out the RK3399 boards in my possession. HDMI works after a plug cycle, may need to utilize some of @botfap's script-fu on boot to wake up the interface. Known Issues: Renegade bottom USB2 port is non-functional HDMI needs a friendly reminder to talk to the display Rock64 Same HDMI hickup Top USB2 port is non-functional Boot up your build machines (or launch you virtual ones, whatever) and get hacking!

Your build Armbian 5.65 kernel 4.4 and my build 5.65 the same kernel - system has sound only via HDMI monitor. Is it possible to enabled audio via 3.5 jack or external USB sound card?

I'm considering buying a Rock64 4GB to use a Docker server running media apps (plex,sonarr,radarr,jackett,smb,etc). I already have a 64GB SD card available for this system, probably overkill, but I have it. I noticed another post saying the SD card performance is not what it could be. I'd like to hear from other have a similar setup to what I'm thinking about. Does it perform well enough for what you're using it for? What are you using it for? What kind of samba through put do you get on the USB2 and USB3 (perhaps with the USB3->SATA adapter) Thanks.

/proc/sys/crypto doesn't exist, so anything checking the status of /proc/sys/crypto/fips_enabled fails terribly. (Specifically trying to bring up a FreeIPA server which includes tomcat-based Dogtag CA, it checks for FIPS during setup, dies). I see there is an rk_crypto kernel module available, so I don't know why /proc/sys/crypto itself is missing. I tried 'modprobe rk_crypto' and it loaded (appears in output of 'lsmod'), but /proc/sys/crypto still doesn't exist.

Hi there, I'm trying to made a dts file to handle a pican2 hat on ROCK64 armbian, but now I'm stuck. I'm a noob in writing dts files, I've tried to take as exemple dts from RPI and Thinker. edit: I've rebuild the kernel, and build the mcp251x.ko module, it load like a charm. But I assume I've to write a correct .dts file to link it to my devices tree. here is my loaded modules list: Module Size Used by can_bcm 24576 0 can_raw 20480 0 can 53248 2 can_bcm,can_raw mali 262144 0 rt2800usb 28672 0 rt2800lib 81920 1 rt2800usb rt2x00usb 20480 1 rt2800usb rt2x00lib 49152 3 rt2x00usb,rt2800lib,rt2800usb zram 32768 5 lz4_compress 16384 1 zram mcp251x 20480 0 dw_hdmi_i2s_audio 16384 0 can_dev 20480 1 mcp251x binfmt_misc 20480 1 ip_tables 24576 0 x_tables 32768 1 ip_tables autofs4 40960 2 uas 20480 0 usb_storage 61440 1 uas Cannot find device "can0" eth0 lo wlx00c141390c5a And as you can see, there is no can0 devices in /sys/class/net. here is my dts file: /dts-v1/; /plugin/; / { compatible = "rockchip,rk3328", "pine64,rock64"; fragment@0 { target-path = "/spi@ff190000"; //target = <&spi0>; __overlay__ { status="okay"; spidev@0{ status = "disabled"; }; spidev@1{ status = "disabled"; }; }; }; /* the interrupt pin of the can-controller */ fragment@1 { target-path = "/pinctrl/gpio3@ff240000"; //target = <&gpio3>; __overlay__ { can0_pins: can0_pins { rockchip,pins = <0 7 0 &pcfg_pull_none>; //phandle = <1>; }; }; }; /* the clock/oscillator of the can-controller */ fragment@2 { target-path = "/"; __overlay__ { /* external oscillator of mcp2515 on SPI0.0 */ can0_osc: can0_osc { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <16000000>; }; }; }; /* the spi config of the can-controller itself binding everything together */ fragment@3 { target-path = "/spi@ff190000"; //target = <&spi0>; __overlay__ { /* needed to avoid dtc warning */ #address-cells = <1>; #size-cells = <0>; can0: can0@0 { //phandle = <1>; reg = <0>; compatible = "microchip,mcp2515"; pinctrl-names = "default"; pinctrl-0 = <&can0_pins>; //pinctrl-0 = "/pinctrl/gpio3@ff240000/can0_pins/"; spi-max-frequency = <10000000>; interrupt-parent = <&gpio3>; //interrupt-parent = "/pinctrl/gpio3@ff240000"; interrupts = <7 0x2>; // 7 2 //clocks = "/can0_osc"; clocks = <&can0_osc>; }; }; }; }; here is what I can read from dmesg: pi@rock64:/boot/overlay-user$ dmesg | fgrep -i spi [ 0.199580] bus: 'spi': registered [ 0.199591] device class 'spi_master': registering [ 0.215439] device: 'ff190000.spi': device_add [ 0.215471] bus: 'platform': add device ff190000.spi [ 0.215560] PM: Adding info for platform:ff190000.spi [ 2.069101] bus: 'spi': add driver cros-ec-spi [ 2.069297] device class 'spi_transport': registering [ 2.069329] device class 'spi_host': registering [ 2.070797] bus: 'spi': add driver m25p80 [ 2.070861] device class 'spidev': registering [ 2.070890] bus: 'spi': add driver spidev [ 2.070956] bus: 'platform': add driver rockchip-spi [ 2.071145] bus: 'platform': driver_probe_device: matched device ff190000.spi with driver rockchip-spi [ 2.071162] bus: 'platform': really_probe: probing driver rockchip-spi with device ff190000.spi [ 2.071495] rockchip-spi ff190000.spi: no init pinctrl state [ 2.071552] rockchip-spi ff190000.spi: no sleep pinctrl state [ 2.071566] rockchip-spi ff190000.spi: no idle pinctrl state [ 2.071795] rockchip-spi ff190000.spi: no high_speed pinctrl state [ 2.071820] device: 'spi32766': device_add [ 2.072075] PM: Adding info for No Bus:spi32766 [ 2.072326] device: 'spi32766.0': device_add [ 2.072362] bus: 'spi': add device spi32766.0 [ 2.072582] PM: Adding info for spi:spi32766.0 [ 2.072661] rockchip-spi ff190000.spi: chipselect 0 already in use [ 2.072675] spi_master spi32766: spi_device register error /spi@ff190000/flash@0 [ 2.072692] spi_master spi32766: Failed to create SPI device for /spi@ff190000/flash@0 [ 2.072709] driver: 'rockchip-spi': driver_bound: bound to device 'ff190000.spi' [ 2.072758] bus: 'platform': really_probe: bound device ff190000.spi to driver rockchip-spi [ 8.643523] bus: 'spi': add driver mcp251x [ 8.643560] bus: 'spi': driver_probe_device: matched device spi32766.0 with driver mcp251x [ 8.643570] bus: 'spi': really_probe: probing driver mcp251x with device spi32766.0 [ 8.643678] mcp251x spi32766.0: no pinctrl handle [ 8.646051] mcp251x spi32766.0: Looking up vdd-supply from device tree [ 8.646071] mcp251x spi32766.0: Looking up vdd-supply property in node /spi@ff190000/can0@0 failed [ 8.648100] mcp251x spi32766.0: Looking up xceiver-supply from device tree [ 8.648120] mcp251x spi32766.0: Looking up xceiver-supply property in node /spi@ff190000/can0@0 failed [ 8.661924] mcp251x: probe of spi32766.0 rejects match -19 pi@rock64:/boot/overlay-user$ help me plz.

Hi all. I'm trying to figure out how to use gstreamer to encode h264 video on Rock64 (Rockchip RK3328). I'm using Armbian Bionic 5.60 (stable Ubuntu 18.04.1 LTS 4.4.156-rockchip64). I compiled mpp and gstreamer-rockchip from https://github.com/rockchip-linux and installed both, but I'm still missing mpph264enc, how do I get that? gst-inspect-1.0 mpph264enc says: No such element or plugin 'mpph264enc' Many thanks for reading, any help would be greatly appreciated. Regards. Christian

Hi, I received my new rock64 today and I downloaded this image https://dl.armbian.com/rock64/Debian_stretch_default_desktop.7z I used Etcher as recommended to create the SD card and booted off of it with just power and network connected as I assumed it would boot, assign a dhcp address and bring up sshd so I could remote onto it. I scanned my network to see if any new devices had been added with dhcp, but couldn't see anything new so I connected the rock64 up to a TV and then booted it up, connected up a keyboard and noticed it ran through an install process on first local login. I followed all the directions and a desktop appeared on screen. However, there was no network connectivity so I had a look at /etc/network/interfaces and could see that nothing at all had been set for eth0. Only the loopback interface was defined. I manually edited /etc/network/interfaces and added my eth0 static IP config in there and rebooted and the eth0 network came up as expected. source /etc/network/interfaces.d/* # Network is managed by Network manager auto lo iface lo inet loopback allow-hotplug eth0 iface eth0 inet static address 10.0.0.42/24 gateway 10.0.0.2 dns-nameservers 10.0.0.2 Is this expected behaviour for the rock64 Debian image? In that, you have to manually configure eth0 after running through the install process or is this a bug? Thanks very much for your help and for maintaining a distribution for the rock64.

Trying to choose between an eMMC module or a USB Flash drive for the boot volume on a Rock64. I have a few Rock64's that I'm building as various services (Nextcloud, Pi-Hole, VPN, OMV, and/or Netatalk Backup). None of these devices will need large boot volumes as the data will be in secondary (Hard or SSD) Drives or will require VERY little data storage. On the RPi's that the Rock64's are replacing, I've been using USB Flash drives for booting. I get the feeling that an eMMC module is a better choice, but do have any real knowledge. Are the eMMC modules more reliable and less prone to corruption that USB Flash Drives? I do have some 32GB and 64GB eMMC models from Pine64 and am going to try them out shortly. Any thoughts and advice? Thank you all in advance. Armbian ROCKS!

I'm building a portable battery powered NAS because syncing and having everything multiple times on all my Android devices sucks. I took my old Banana Pi connected a SSD to the SATA port and made it a access point (no Samba yet installed). Booting from the 16GB SanDisk Ultra A1 is 27 seconds. Moving everything to the SSD in armbian config is also 27 seconds (no difference?) I know the Banana has not the fastest SATA and NIC and that USB 3 on the Rock64 is faster. But i don't copy tons of gigabyte to the device everyday and for streaming over the WiFi stick it's fast enough. I'm interested on the boot time of the Rock64 (eMMC or USB/SSD). If its not much faster then i see no reason to by a Rock64 for that. Also the Banana has the advantage that you can solder a battery to it.

Hi! I'm trying to create a vpn access point with a Rock64. I'm receving a low speeds with openvpn but the openssl tests show that there is crypto acceleration. I'm new to all of this. I assume the vpn speeds would be much higher since crypto extensions are enabled in armbian, that's why I choose the Rock64 and Armbian. This is the openssl test: openssl speed -evp aes-256-cbc Doing aes-256-cbc for 3s on 16 size blocks: 14416568 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 64 size blocks: 10625804 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 256 size blocks: 4907054 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 1594735 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 218375 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 16384 size blocks: 109757 aes-256-cbc's in 3.00s OpenSSL 1.1.0f 25 May 2017 built on: reproducible build, date unspecified options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/lib/ssl\"" -DENGINESDIR="\"/usr/lib/aarch64-linux-gnu/engines-1.1\"" The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-256-cbc 76888.36k 226683.82k 418735.27k 544336.21k 596309.33k 599419.56k My internet speed is around 76 MB download and 19 MB upload. The rock64 without a vpn connection is capable of reaching those speeds but with the openvpn connected and using the same cipher aes-256-cbc these are the results: speedtest-cli Retrieving speedtest.net configuration... Testing from Zare (185.44.76.118)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by fdcservers.net (London) [0.96 km]: 38.804 ms Testing download speed................................................................................ Download: 20.42 Mbit/s Testing upload speed.................................................................................................... Upload: 17.88 Mbit/s I've been reading posts from other people talking about speeds of 60 or 80 MB/s through openvpn connections. Is 20MB the maximum speed I will achieve with the Rock64? If not, what should I do? As I said, I'm new to this and I don't know how to proceed, my ideas are that perhaps openvpn is not compiled to use the crypto engine but maybe I'm just talking nonsense. I'm using Armbian Stretch with desktop legacy kernel 4.4.y Thank you very much for your help

Hi everybody, I recently set up a small server with the Rock64 booting armbian stretch 5.59 stable directly from a 120 GB SSD attached via USB3. Booting is handled with U-Boot from ayufan on the SPI flash. The Rock64 is board revision 2.0, the power supply is the original Pine64 one for the Rock. Besides the SSD, there are no other peripherals connected. The board often (3 out of 4 times) hangs when booting. In this case, all LEDs are lit, the orange network LED will flash and the board is not reachable by SSH and not pingable. My impression is, that it is stuck because the SSD either powered up too late or the USB connection is delayed. However, I cannot confirm my suspicion, because the board also does not output any HDMI signal to my monitor (even if it boots up correctly). If I cut power, re-power and give it another try, it will boot at some point and everything (except the HDMI) will work perfectly. My issue seems to identical to the one described here for the ayufan build. It is noted in that thread, that an external power supply for the SSD might mitigate the problem. I did not have a chance to test this, yet. But I also hope that you guys have a better insight into this and might catch a bug in the armbian image.