Search the Community

I was wondering if there is a solution to boot from a USB thumb drive and flash the OS to an eMMC. Currently I´m running ARMbian on a Rock64 with an eMMC module installed. Since I´m still trying to figure out how to set up the device I keep reinstalling the OS. So it would be nice to have a way without opening the case, take out the eMMC, hook it up to the PC to flash and reinserting. Thanks in advance.

From the media script thread: Chromium is unusable right now. I'm having to use Firefox. EDIT1: I ran the media-script .sh and it auto installed the default selection and I also ticked "streaming" which I know is Chromium... EDIT2: I'm on the latest Chromium for Ubuntu bionic... 73.x EDIT3: This is what Chromium says under "chrome://gpu": What am I doing wrong? es2_info: and glxgears:

I have seen many problems with the Rock64 v3 in the last few days. Many customers have told me that existing Rock64 images suddenly no longer boot in v3. We have verified this and found that apparently v3 can not cope with many SD cards. The booting of eMMC goes without problems. If a customer has bought a new v3 and nothing works, contact us, we will send you an emmc card for the purchase price without any profit. markus@humberg.de

Hi all. In download section i do see "large heatsink required" for Rock64. Can anyone post any links to eamples of good heatsink with proper size ? I will be migrating "home server" from Cubieboard2 to Rock64 and chasing long-term stable operation. When board just booted and "does nothing", cpu remains pretty cool. However i'd better be prepared. thanks in advance for tips.

Hello all! I bought a Rock64 V3 and it wouldn't boot Armbian, not any other GNU/Linux based OS that I tried, I got in touch with Pine64 and they said: >The issue on the SD boot on the ROCK64 SBC is the GPIO0_D6 (SDMMC0_PWREN) default needs to set high instead of lets this pin floating at Linux DT (Device Tree). The ROCK64 V3 has the high speed SD access design which can double boost up with proper software driver. We will advise developer to update the OS build (stock Android already implemented) accordingly. >Please refer to ROCK64 SBC v3.0 Change Notice, http://files.pine64.org/doc/rock64/Rock64%20Ver%203%20change%20notice.pdf >Now the developer is work on it. When the OS ready, the developer will update at Pine64 Forum. Please check on Pine64 Forum (https://forum.pine64.org/forumdisplay.php?fid=85) When is they estimate for when Armbian will support this new driver? Thank you, Joe.

I am having the same problem and dmesg output with my Ubuntu rock64 I am also getting errors in Xorg.log as described in What is the connection ?

after several minutes, a 3 line error message is output on 2 old original rock64's. network works, I can log in from my local net, and dmesg says: [ 35.867400] Unbalanced IRQ 47 wake disable [ 35.867422] WARNING: CPU: 0 PID: 1580 at kernel/irq/manage.c:900 irq_set_irq_wake+0x108/0x148 [ 35.867447] Modules linked in: rfkill joydev snd_soc_spdif_tx gpio_ir_recv rc_core lz4hc cdc_acm lz4 hantro_vpu(C) rockchip_vdec(C) rockchip_iep snd_soc_simple_card v4l2_h264 snd_soc_rockchip_i2s rockchip_rga videobuf2_dma_contig snd_soc_rockchip_pcm snd_soc_hdmi_codec snd_soc_rk3328 snd_soc_simple_card_utils v4l2_mem2mem snd_soc_rockchip_spdif videobuf2_dma_sg videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 snd_soc_core videobuf2_common videodev snd_pcm_dmaengine mc snd_pcm snd_timer snd soundcore cpufreq_dt zram binfmt_misc sch_fq_codel ramoops reed_solomon pstore_blk pstore_zone ip_tables x_tables autofs4 hid_logitech_hidpp hid_logitech_dj realtek dwmac_rk stmmac_platform stmmac lima dw_hdmi_cec pcs_xpcs gpu_sched dw_hdmi_i2s_audio gpio_syscon [ 35.867680] CPU: 0 PID: 1580 Comm: NetworkManager Tainted: G C 5.15.74-rockchip64 #22.08.6 [ 35.867693] Hardware name: Pine64 Rock64 (DT) [ 35.867699] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 35.867709] pc : irq_set_irq_wake+0x108/0x148 [ 35.867724] lr : irq_set_irq_wake+0x108/0x148 [ 35.867734] sp : ffff80000a7e3b30 [ 35.867739] x29: ffff80000a7e3b30 x28: ffff00000184d880 x27: 0000000000000000 [ 35.867757] x26: 0000000000000000 x25: 0000000000000000 x24: 0000ffffe172c0f8 [ 35.867774] x23: 000000000000002f x22: 0000000000000000 x21: 00000000ffffffea [ 35.867790] x20: ffff80000954c7c8 x19: ffff000000711200 x18: 0000000000000001 [ 35.867806] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000280 [ 35.867822] x14: ffff80000a7e3840 x13: 00000000ffffffea x12: ffff800009b1fd10 [ 35.867838] x11: 0000000000000003 x10: ffff800009b07cd0 x9 : ffff800009b07d28 [ 35.867855] x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001 [ 35.867870] x5 : ffff8000f501a000 x4 : 0000000000000000 x3 : 0000000000000002 [ 35.867886] x2 : 0000000000000001 x1 : 8cf7ed973ed99a00 x0 : 0000000000000000 [ 35.867903] Call trace: [ 35.867908] irq_set_irq_wake+0x108/0x148 [ 35.867920] stmmac_set_wol+0x74/0x128 [stmmac] [ 35.867985] dev_ethtool+0x1400/0x20b0 [ 35.867998] dev_ioctl+0x1fc/0x3f8 [ 35.868008] sock_do_ioctl+0xb4/0xf8 [ 35.868018] sock_ioctl+0x2d4/0x3b8 [ 35.868027] __arm64_sys_ioctl+0xa8/0xe8 [ 35.868038] invoke_syscall+0x44/0x108 [ 35.868050] el0_svc_common.constprop.3+0x94/0xf8 [ 35.868061] do_el0_svc+0x24/0x88 [ 35.868071] el0_svc+0x20/0x50 [ 35.868080] el0t_64_sync_handler+0x90/0xb8 [ 35.868089] el0t_64_sync+0x180/0x184 [ 35.868099] ---[ end trace b82369d81dab89d6 ]--- [ 147.094526] hdmi-audio-codec hdmi-audio-codec.4.auto: Only one simultaneous stream supported! [ 147.095731] hdmi-audio-codec hdmi-audio-codec.4.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -22 [ 147.096881] ff000000.i2s-i2s-hifi: soc_pcm_open() failed (-22) [ 147.250755] overlayfs: "xino" feature enabled using 2 upper inode bits. ================== on both machines. These have a primary assignment of running octoprint as part of my printer farm and hdmi video is required. Any clues as to what will restore their video?

I have the same problem with a rock64 running the latest Ubuntu XFCE

Sorry if this in the wrong spot. I need a bit of help here, I once or twice updated the kernel on the Rock64 from older versions but I've always ran into an issue where it just wouldn't boot anymore and needed to be re-flashed. I run a always up server that has to have little to no downtime and I wish to avoid having to re-flash again. So I want to know if its safe or not to upgrade to 4.4.174 from 4.4.167 I can provide more info if needed. Thanks

I just did another apt upgrade on one of the rock64's that included 8 packages, some of it Xorg stuff, but the problem persists, no video on the rock64's own monitor. Both of them. They are both running well enough i can login with an "ssh -Y nameofmachine" So I have extracted a fresh copy of the dmesg error stanza, and the /var/log/Xorg.0.log generated by the reboot after the update. Attached. If that can't ID the problem, what else do you need? I see you are asking for help. I don't code well, but I'll certainly play the canary in the coal mine as a test mule. Both machines are up to date as of half an hour ago. Thanks for any help. dmesg-clipXorg.0.log.txt

Since 23 hours, 23 views, no reply's. So I have ordered a 4 pack of the latest 4gig bananna pi's, and would like to know: 1. if Armbian will work on them, and 2. If octoprint-1.8.6 can be installed in a python venv so I can get back to work on a room full of 3d FDM printers. off topic, I have been running an apt update at about 8 hour intervals on the rock64's but while error msgs are, or were displayed on the hdmi output, no xserver appears to be start-able, the hdmi display has now gone dark without its declaring a loss of signal so I have to assume it is generating a synch signal of some sort. I can ssh -Y into both from this machine 3 rooms away, but the local displays are blanked. Thank you all, take care & stay well.

further info on the x failure on rock64's. This is something I've not seen in 24 years of a linux only house. An update session on both very early rock64's killed the local video. Xorg.0.log

Hi, I've built the Ubuntu 18.04 image with legacy kernel (4.4) and tried to install wireguard. The problem was the kernel module which seems to be build by dkms. I've installed kernel headers from the linux-headers-rk3328_5.44_arm64.deb (built by armbian's build procedure) and tried to install wireguard-dkms package. It fails: Unpacking wireguard-dkms (0.0.20180513-wg1~bionic) over (0.0.20180513-wg1~bionic) ... Setting up wireguard-dkms (0.0.20180513-wg1~bionic) ... Loading new wireguard-0.0.20180513 DKMS files... Building for 4.4.131-rk3328 Building initial module for 4.4.131-rk3328 Error! Bad return status for module build on kernel: 4.4.131-rk3328 (aarch64) Consult /var/lib/dkms/wireguard/0.0.20180513/build/make.log for more information. The content of make.log DKMS make.log for wireguard-0.0.20180513 for kernel 4.4.131-rk3328 (aarch64) Thu May 17 21:24:11 UTC 2018 make: Entering directory '/usr/src/linux-headers-4.4.131-rk3328' Makefile:643: arch//Makefile: No such file or directory make: *** No rule to make target 'arch//Makefile'. Stop. make: Leaving directory '/usr/src/linux-headers-4.4.131-rk3328' The line 643 is include arch/$(SRCARCH)/Makefile so SRCARCH is not set for some reason. Any suggestions how to fix it? Also I've tired to build wireguard module manually with dkms and/or from source. In both cases it fails because of absent scripts/recordmcount. I've tried to build that stuff with 'make scripts' in the /usr/src/linux-headers-4.4.131-rk3328 and this fails too: HOSTCC scripts/selinux/genheaders/genheaders scripts/selinux/genheaders/genheaders.c:13:10: fatal error: classmap.h: No such file or directory #include "classmap.h" This classmap.h exists in the kernel source tree, but was not included into kernel-headers deb. Do I need to fix something in kernel makefiles?

Hi, Is it possible to boot from SSD? How it should be partitioned? Can I use any arbitrary partition for rootfs? Should I follow the procedure from this thread ? It assumes I should write the armbian image to a whole drive instead of partition, right? Well, I actually tried some way... First, I've tried to just run some utility from ambian-config that transfers rootfs to a partition. Device did not boot after this (with SD card ejected). Then I've flashed the ayufan's u-boot-flash-spi-rock64.img.xz. This also fails (boot log is attached) but the log looks promising. BTW, I'm experimenting with Ubuntu 18.04 image built by myself from armbian's development branch. Should I use 16.04 instead? Does armbian have its own image/procedure to place uboot into SPI? Just in case here is the drive partitioning (fdisk log from Linux PC): Disk /dev/sde: 232.9 GiB, 250059350016 bytes, 488397168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 33553920 bytes Disklabel type: dos Disk identifier: 0x22138112 Device Boot Start End Sectors Size Id Type /dev/sde1 2048 119769087 119767040 57.1G 83 Linux /dev/sde2 156354560 488396799 332042240 158.3G 83 Linux /dev/sde3 * 119769088 156354559 36585472 17.5G 83 Linux Partition table entries are not in disk order. And I'm trying to use third partition for rootfs. This partition was actually created after shrinking partition 1 in the freed space. Drive is attached to USB3. minicom.cap

I am so frustrated with my rock64 (SoC RK3328), there is no support. Pine 64 takes the money and dumps all the issues on a community. The product is a lemon. Can’t watch YouTube, there is no audio I am very disappointed in Pine64, I will try and return this device.

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?

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.

The above thing is a $10 accessory that can be ordered together with ROCK64 (and maybe other Pine Inc. devices like Pine64 or Pinebook?). It's an USB-to-SATA bridge (JMicron JMS578 based) to be used together with 2.5" SSD/HDD or 3.5" HDD. For the latter purpose it's equipped with a separate power jack suitable for the usual 12V 5.5/2.1mm power barrels (centre positive) you find PSUs with literally everywhere. TL;DR: If you want to add storage to your ROCK64 order this cable too. It works great with both 2.5" and 3.5" disks and it's somewhat sad it's not available separately since it's a great storage companion for many other devices too. Basics first: Mechanical quality of USB jack is excellent, Pine folks took care that the jack fits really tightly in USB receptacles so USB3 contact issues should not be an issue here (tested on ODROID-XU4 which is my worst device in this regard. The Pine adapter worked great and these pretty nice XU4 USB3 storage performance numbers were produced with Pine's adapter) The device is not really black but it's just a very dark but translucent plastic. If it's connected to an USB port and thereby powered a solid blue led is shining through. Disk activity is shown with a blinking red led in parallel. If you hate blinking leds like me turning the device 180° over is sufficient JMS578 as USB-to-SATA bridge is an excellent choice since amazingly fast, 'USB Attached SCSI' capable, same with 'SCSI / ATA translation' and even TRIM (though software support for this still missing in Linux) When combined with 2.5" disks the whole power consumption happens through the USB cable. Keep in mind that USB2 ports are rated for 500mA and USB3 ports for 900mA max. ROCK64 AFAIK allows 650mA on the USB2 ports and 950 mA on the USB3 ports. In other words: chances are great to run in underpowering problems when you connect 2.5" disks to the USB2 ports and run heavy loads on it (see below). 3.5" HDDs need not only 5V but also 12V. Usually the motor spinning the platters is on the 12V rail while internal electronics and the stepper motors to move around the head(s) are on the 5V rail. Please always keep in mind that Pine's SATA cable unlike any 'real' 3.5" HDD disk enclosure uses the separately provided 12V only to feed pins 13-15 on the SATA power connector. 5V consumption for the JMS578 and the disk's 5V rail has still to be provided by the device the SATA cable is connected to since coming from the USB power lines. On 'real' disk enclosures the 12V are internally also used to generate the 5V so an external disk is NOT powered in any way by the connected host. With this cable it's different! Below is the standard SATA power connector pinout. 3.3V are usually not used, 12V are needed for 3.5" HDDs and 5V are always required. The JMS578 bridge chip needs some 5V juice too which is also taken from the connected host/board via USB power lines. We already have a lot of performance numbers with fast SSDs connected to JMS578 (see https://forum.armbian.com/index.php?/topic/1925-some-storage-benchmarks-on-sbcs/&do=findComment&comment=34192 or there for example) so let's focus on real-world use cases this time: A large 3.5" HDD connected to a ROCK64 serving as a NAS or backup disk. Let's start with some consumption numbers with an idle ROCK64. In the meantime I've 3 different ROCK64 generations on my desk (1st dev sample with 2GB and unusable USB3, 2nd gen dev sample with 4 GB and now a production board with 1 GB DRAM and a different Gigabit Ethernet PHY). Measurements done without PSU taken into account: Pre-production board, 4GB, RTL8211E PHY: Idle, Fast Ethernet active, nothing connected: 1100mW Idle, GbE active, nothing connected: 1430mW Production board, 1GB, RTL8211F PHY: Idle, Fast Ethernet active, nothing connected: 1180mW Idle, GbE active, nothing connected: 1300mW Idle, GbE active, JMS578 connected: 1720mW Idle, GbE active, JMS578 with sleeping disk: 2850mW With RTL8211E PHY the difference between GbE and Fast Ethernet was 330mW (on most GbE boards with 8211E it's exactly like this: ~350mW) and now with RTL8211F the difference is just 120mW (difference on ODROID-C2 which also uses 8211F is 230mW). When adding the JMS578 cable w/o connected disk consumption increases by 400mW. In this (rather useless) mode the JMS578 hides itself on the USB bus (lsusb output shows nothing -- interestingly on ODROID HC1 which also relies on JMS578 this is different) and obviously JMS578's USB and SATA PHYs are powered off. As soon as a disk is connected but sent to sleep JMS578 now consumes +1.5W and appears on the USB bus (now JMS578 has to power 2 highspeed PHYs: USB3 and SATA 3.0). So with production ROCK64 boards minimal idle consumption is 1.2W (PSU's own consumption excluded). But as soon as we connect this cable with a disk behind idle consumption more than doubles (+1550mW) even if we send the disk to sleep. That's bad news for use cases that require a connected disk only running from time to time since now the JMS578 consumes more energy than the board itself. Edit: I discovered recently that the HDD I was testing with has a rather high standby/sleep consumption so the +1550mW are not JMS578 alone but maybe even largely the Seagate Barracuda. See here for details but keep in mind that while on ODROID HC2 also a JMS578 is used it runs a different firmware which influences idle consumption behaviour a lot. More details on JMS578 firmwares: https://forum.armbian.com/topic/3317-orange-pi-zero-nas-expansion-board-with-sata-msata/?do=findComment&comment=43735 What are the options? With ROCK64 production boards we're fortunately able to toggle power provided to USB ports: https://forum.pine64.org/showthread.php?tid=5001 So the SATA cable connected to an USB2 port would allow to regain lowest idle consumption since we could unmount the disk when not needed, then send the disk to sleep using 'hdparm -y' (JMS578 fully supports 'SCSI / ATA translation so you can access every disk feature with hdparm or other low level tools!) and finally switch JMS578 off by cutting power on the USB2 port. My personal use case is a ROCK64 with a huge 3.5" HDD to backup various macOS devices in the household. Backup performance is close to irrelevant and the only events needing top 'NAS performance' would be large restores or 'desaster recovery'. In other words: for normal backup operation once a day it would be sufficient to connect the disk to an USB2 port. Nope, doesn't work any more, see below for details. How does performance look like with a 7.2k 3.5" HDD (Seagate Barracuda from a few years ago): The Barracuda is totally empty so able to achieve nice maximum sequential performance scores since testing only on the outer tracks (~170 MB/s): USB3 / UAS (7.9W vs. 3.3W) random random kB reclen write rewrite read reread read write 102400 4 11738 23147 25131 25087 1091 948 102400 16 62218 77830 84257 84768 4246 4136 102400 512 150052 148303 154342 163817 58563 97809 102400 1024 148290 148324 156772 164963 85125 113412 102400 16384 149840 149248 144297 151440 153146 133806 1024000 16384 167750 169544 172970 174205 160859 151406 When connected to an USB2 port performance drops a lot (maxing out at ~37MB/s): USB2 / UAS (6.4W vs. 3.3W) random random kB reclen write rewrite read reread read write 102400 4 7735 7849 6821 7925 998 916 102400 16 17687 19040 20793 19430 3624 4096 102400 512 33472 33662 33738 34329 26020 33683 102400 1024 33836 34030 34855 35505 29941 28791 102400 16384 34294 34373 35599 36694 36174 33714 1024000 16384 33600 34516 36576 36902 36372 34111 I tested backing up the same MacBook Air twice with ~70 GB data using Gigabit Ethernet (the usual Thunderbolt Ethernet adapter) and time difference was negligible comparing HDD connected to USB2 or USB3. When backing up through Wi-Fi there is no difference any more since Wi-Fi is the bottleneck. In other words: from a performance point of view for this use case connecting the SATA cable to an USB2 port and being able to totally cut power to both cable/JMS578 (+1.5W consumption) and a sleeping 3.5" disk (less than 0.1W consumption with almost all disks) is worth the efforts. Once your MacBook gets stolen you simply disconnect the backup HDD from the USB2 and reattach it to an USB3 port and start the restore on your new device with +80 MB/s (Gigabit Ethernet now being the bottleneck) What about power requirements? ROCK64 only provides up to 650 mA on the USB2 ports! I tried to test this precisely with my usual 'monitoring PSU' approach. All I was getting were some nice kernel panics due to UNDERPOWERING. The Banana Pro I used to provide power (and measure consumption) simply does not provide enough current so Linux on ROCK64 started to fail in many funny ways once USB accesses happened. So I had to revert on measuring with PSU included with a cheap powermeter (more realistic but not that precise). When measuring only the 12V rail of my 3.5" Barracuda the disk consumed up to 18W when spinning up. In normal operation (either idle or with any workload) 12V consumption varied between 6W and 8W (12V only needed to spin the platters). The 5V power requirements for JMS578 + 3.5" HDD disk were as follows: USB2: 6.4W vs. 3.3W (full load vs. idle). Numbers with 5V PSU included so we're talking about needed power provided on an USB2 port of approximately ~3W which fits perfectly in the power budget of ROCK64's USB2: 650mA * 5V == 3250mW USB3: 7.9W vs. 3.3W (full load vs. idle). Numbers again with 5V PSU included so we're talking about needed power provided on an USB3 port of approximately ~4W which fits perfectly in the power budget of ROCK64's USB3: 950mA * 5V == 4750mW At least with my 3.5" HDD it worked pretty well to let it operate on both USB2 and USB3 ports when board powering was appropriate (with insufficient powering all weird sorts of issues popped up. My favourite was a kernel panic when issueing 'lsusb' after 30 seconds. Once I powered ROCK64 reliably all these 'software issues' were gone immediately -- again and again: insufficient powering is one of the most severe problem sources)

On Armbian Buster, rockchip (rock64), kernel 5.16.69. This was also happening on the latest backported version of 5.10, I think 5.10.72? I tried upgrading to fix it to no avail. I have a couple 8TB HDDs that I use as backups. All I did was reformat one of them as btrfs and start copying the data back over from the other (still EXT4). I tried rsync and simple cp. Without fail, a few minutes into the operation, the copy operation will hang indefinitely, and all open terminals receive these kernel messages: Message from syslogd@localhost at Oct 1 16:59:57 ... kernel:[ 339.539365] Internal error: Oops: 96000004 [#1] PREEMPT SMP Message from syslogd@localhost at Oct 1 16:59:57 ... kernel:[ 339.560387] Code: cb0100a3 cb0d015c 7100019f 9b167c00 (9adb2400) After that, every subsequent copy operation from the EXT4 drive to this new btrfs partition will hang until I reboot the rock64. However, the drive otherwise continues to work fine. fsck and btrfs scrub find no problems. The super weird thing is I can still write files, and copy a small shell script from the home folder, all just fine--but copying from the other 8TB drive will immediately hang. I have had zero issues with either drive until trying btrfs now. I'm able to rsync between them just fine when they're both EXT4. journalctl.txt specific-error.txt

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

Thanks for your feedback and advice. Appologies for late response, I can only post once a day as a new user. I am not using Microsoft virtualization, despite what Linux says. This issue has nothing to do with virtualization though, it's easily reproducable on bare metal with Ubuntu 22.04/Debian 11, or in docker, hyper-v, Xen, KVM, even LXC as this u-boot compilation error is before anything that LXC might not support (though this doesn't mean LXC is supported, it might fail later on for some other reason!). Upon further investigation, I did find that the compilation log file had some useful information that led to a solution. The error listed there was a ton of syntax errors and such. I've included the full log file below for anyone with the same issue who might want to actually fix the issue rather than work around it. The error I found led me to this page https://github.com/hardkernel/u-boot/issues/73. While there was no solution there, it did give me the idea to try an older OS since perhaps Ubuntu 22.04 and Debian 11 packages are too new for this old code. Turns out I was right. Using Peppermint 10 (Based on Ubuntu 18.04, I'm sure it'd work fine on Ubuntu 18.04 too) this error is gone. In order to get it to run on Ubuntu 18.04, you have to edit line 1447 of ./build/lib/general.sh to include bionic as a supported version. You also need to install libncurses-5.dev if you don't have it already or else it errors later on due to missing ncurses. I know this is obviously unsupported but if you need the u-boot compile to actually work and this isn't fixed by the time anyone else is reading this in the future, that's how I got it to work. I didn't try Ubuntu 20.04 but it could have a chance of working too since it has older packages than 22.04 but as of now, is listed as a supported version in the general.sh file. ---------------------------- Start u-boot error compilation.log ----------------------------------- == u-boot make == In file included from tools/../include/libfdt.h:54, from tools/fdt_host.h:11, from tools/imagetool.h:24, from tools/aisimage.c:8: /usr/include/libfdt_env.h:27:30: error: conflicting types for ‘fdt64_t’; have ‘uint64_t’ {aka ‘long unsigned int’} 27 | typedef uint64_t FDT_BITWISE fdt64_t; | ^~~~~~~ In file included from <command-line>: ././include/libfdt_env.h:19:16: note: previous declaration of ‘fdt64_t’ with type ‘fdt64_t’ {aka ‘long long unsigned int’} 19 | typedef __be64 fdt64_t; | ^~~~~~~ In file included from ././include/libfdt_env.h:12, from <command-line>: /usr/include/libfdt_env.h:47:24: error: expected ‘)’ before ‘x’ 47 | static inline uint32_t fdt32_to_cpu(fdt32_t x) | ^~~~~~~~~~~~ ././include/compiler.h:66:16: error: expected ‘)’ before ‘&’ token 66 | ((((x) & 0xff000000) >> 24) | \ | ^ ././include/compiler.h:66:30: error: expected ‘)’ before ‘>>’ token 66 | ((((x) & 0xff000000) >> 24) | \ | ^~ ././include/compiler.h:66:37: error: expected ‘)’ before ‘|’ token 66 | ((((x) & 0xff000000) >> 24) | \ ----------------------------- End u-boot error compilation.log ------------------------------------ Full log (LOTS more errors I left out for brevity): https://files.electrohaxz.host/file/e3872aa444605cab978c45b683c00b44/compilation.log Incase something is missing, here's an archive of the entire debug folder contents for the u-boot compilation error (all logs) https://files.electrohaxz.host/file/f1df43da7dbaffb65bd634e7ba1e2c07/uboot-err-logs.7z Now my issue is unrelated to u-boot. The whole reason for recompiling was to enable kvm support (and preferably support lxc too but didn't attempt that yet), however after enabling KVM in the compile options, the compile fails with the below error. Is this something you or someone else would be able to help with? I'm not too sure since this is a CSC board and I don't want to ask too much. I figured there's a reason KVM isn't enabled in the kernel by default on this platform, despite it being enabled on others like rock64. Perhaps this is something unsolvable for one reason or another, I don't know. Any help regarding this would be greatly apprecaited as I've got about $1000 worth of these boards in a cluster and without lxc or kvm, I'm not sure what I can use them for unfortunately. If this isn't something I can get help on then I understand too. I would also be willing to donate a bit to whomever could help get kvm and lxc working in this kernel if I can donate with crypto. If anyone willing to help needs a development system to build on if you don't have your own, I can also provide remote access to a server with any OS of your choice and plenty of compute and fast networking for that for as long as needed (for free, of course!). I can also provide remote access to as many nano pi fire 3's as you need if that's needed for any reason. ---------------------------- Start KVM error Output.log --------------------------------------- arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.c:574:9: error: implicit declaration of function ‘arch_timer_get_kvm_info’; did you mean ‘arch_timer_get_cntkctl’? [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[1]: *** [arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.o] Error 1 make: *** [arch/arm64/kvm] Error 2 [ error ] ERROR in function compile_kernel [ main.sh:595 -> main.sh:489 -> compilation.sh:509 -> general.sh:0 ] [ error ] Kernel was not built [ @host ] [ o.k. ] Process terminated ----------------------------- End KVM error Output.log ---------------------------------------- Full log: https://files.electrohaxz.host/file/338487ce6b7e665d521325acadc0791a/output.log ---------------------------- Start KVM error compilation.log ----------------------------------- == kernel == arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.c: In function ‘kvm_timer_hyp_init’: arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.c:574:9: error: implicit declaration of function ‘arch_timer_get$ info = arch_timer_get_kvm_info(); ^~~~~~~~~~~~~~~~~~~~~~~ arch_timer_get_cntkctl arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.c:574:7: warning: assignment to ‘struct arch_timer_kvm_info *’ f$ info = arch_timer_get_kvm_info(); ^ cc1: some warnings being treated as errors make[1]: *** [arch/arm64/kvm/../../../virt/kvm/arm/arch_timer.o] Error 1 make: *** [arch/arm64/kvm] Error 2 make: *** Waiting for unfinished jobs.... fs/proc/task_mmu.c: In function ‘show_smap.isra.13’: fs/proc/task_mmu.c:764:7: warning: ‘last_vma’ may be used uninitialized in this function [-Wmaybe-uninitialized] bool last_vma; ^~~~~~~~ ----------------------------- End KVM error compilation.log ------------------------------------ Full log: https://files.electrohaxz.host/file/e555ae72e83a95e2909bd5bc448909e3/compilation.log Incase something is missing, here's an archive of the entire debug folder contents for the KVM error (all logs) https://files.electrohaxz.host/file/6afc42fcb211b8562eb73040c352a652/kvm-err-logs.7z

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.

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.

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.