Search the Community

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.

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?

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

Hello everybody, bought a Rock64 4 GB recently and I´m not able to boot it with any provided armbian Debian/Ubuntu image. With the Ubuntu Image ethernet doesnt seem to be initialized and with Debian there is activity on the eth port, but no connection, neither of the images show any output on the screen. Also i tried various SD-Cards and different image burning programs. Openmediavault works flawlessly, so I can exclude Hardware issues.

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.

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.

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

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

The wireless interfaces are not coming up [ 16.959456] cfg80211: Loading compiled-in X.509 certificates for regulatory database [ 16.969238] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [ 16.971635] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ 16.971650] cfg80211: failed to load regulatory.db [ 41.751941] rk_gmac-dwmac ff540000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off [ 41.751976] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

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!

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

Hello, Each time I'm booting the Rock64, it starts on Jan, 21 of 2016 but the filesystem has a superblock on Jan,28 of 2018, so in the future. It's inconsistant and the filesystem is checking each time and I'm waiting a few seconds. How can I avoid this trouble ? Here is the screen shot of logs through the tty/usb console. I'm booting from the spi flash and a sd-card with Ubuntu 18.04.1.

I'm trying to switch the upper USB port to peripheral mode so I can use the ethernet gadget on it. Has anyone done anything like that before? I've got an issue here https://github.com/ayufan-rock64/linux-build/issues/117 with some of the things I've tried already.

Good evening, I have a Rock64/4G board and just downloaded and installed the Armbian_5.42_Rock64_Debian_stretch_default_4.4.124_desktop.7z to the SD card. After the reboot I saw X11 login interface and everything was great. After that I installed the latest packages with an apt update and then apt upgrade and restarted. Now I only see "rock64 login:" on the screen. The Xorg.0.log I have attached looks actually quite good. Xorg.0.log

I'm trying to get wifi working on my Rock64 running the nightly server image. Is this possible?

rock64 rk3328 orange pi one Can the rock64 rk3328 run several programs simultaneously? Browse internet with little latency? When I tested orange pi one youtube would stutter. Thank you.

New user of a Rock64 board, I've tinkered with a RaspberryPi and BeagleBone before but wanted something to set up as a home media server. I flashed the SD card with an "Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124" image and it worked perfectly fine at home, connecting to my network, etc. However, I took it to a new location and it straight up refuses to boot. I've tried it on several displays and with several HDMI cables. It hangs for a solid 30-45 seconds after initiating boot with a black HDMI screen, and then turns off and back on dumping a log citing either spinup shutdown errors or a temperature shutdown on Core 0. I've flashed a separate SD card with the same image as well as the stretch image off the main Armbian page and both of them work for a short while but then proceed to crash seemingly without change ~24 hours later. Is there a large chance my board is simply intermittently dead or is the Rock64 known for being extremely picky with HDMI cables/monitors at boot? Edit: Got it home to my original setup and I have no dice there. I'm at a loss - everything seems to work perfectly with the board after flashing but only for a day or so, then it gets stuck on boot. At this point I'm keen to put it down as a defective board, I'm not sure what else it would be after trying different images, SD cards, HDMI cables, and monitors.

I do have a setup: 2.5" disks connected to the powered USB 3.0 hub. The power adapter is 10A. If I do start rsync copy from one disk to another after a while I'm getting the error: rsync error: error in file IO (code 11) at receiver.c(393) [receiver=3.1.2] All disks disappired. There is no way to return them back, only reboot helps. In dmesg I could find that device jsut stopped and disappired: [ 2342.927583] usb 5-1.1: USB disconnect, device number 3 [ 2342.931057] usb 4-1: USB disconnect, device number 2 [ 2342.931975] usb 5-1: USB disconnect, device number 2 [ 2345.629932] usb 5-1.3: USB disconnect, device number 4 [ 2345.663838] usb 5-1.4: USB disconnect, device number 5 [ 2342.904003] xhci-hcd xhci-hcd.9.auto: xHCI host not responding to stop endpoint command. [ 2342.904016] xhci-hcd xhci-hcd.9.auto: Assuming host is dying, halting host. [ 2342.927380] xhci-hcd xhci-hcd.9.auto: Host not halted after 16000 microseconds. [ 2342.927400] xhci-hcd xhci-hcd.9.auto: Non-responsive xHCI host is not halting. [ 2342.927416] xhci-hcd xhci-hcd.9.auto: Completing active URBs anyway. [ 2342.927502] xhci-hcd xhci-hcd.9.auto: HC died; cleaning up [ 2342.927543] xhci-hcd xhci-hcd.9.auto: xHCI host not responding to stop endpoint command. [ 2342.927552] xhci-hcd xhci-hcd.9.auto: Assuming host is dying, halting host. [ 2342.930928] xhci-hcd xhci-hcd.9.auto: HC died; cleaning up Any ideas? How to find the reason of this crash?

I'm trying to use it with a TV that has HDMI input but it's 1360x766. xrandr says it's running at 1920x1080. It's very small, like keep a magnifying glass handy, and I don't have the bottom of the screen where LXDE puts the pager and buttons. I thought from my Raspberry Pi experience that I'd just change the mode in my config.txt https://www.raspberrypi.org/documentation/configuration/config-txt/video.md but apparently the Rock64 isn't that evolved. Can I set an HDMI mode in my armbianEnv.txt? Can it use CVT modes? The standard 1360x768 mode isn't quite right. I've been around this stuff since you had to work out an xfree86.conf file on paper and take timings into account but that was with CRT monitors where the resolution didn't have to exactly match LCD resolutions. Where do I change it? I have a couple monitors that a Pi's EDID parser doesn't work right on either, which is OK as long as there's a way to set the mode manually. FWIW this is an Axess TVD-1801 a couple years old. The PDF I just grabbed says 1366x768, something else said 766 vertically.

Hey fellow tinkerers, I'm pretty happy with my Rock64 boards so far, however, when I recently upgraded the kernel on the oldest one and rebooted, I couldn't ssh back in. So I hooked it up to a monitor and was blown away from all the error-like text that kept flowing on my screen. Since I have if this is logged anywhere (I looked but couldn't find anything after mounting the sdcard in my laptop), I had to film it. See attached video. It basically consists of lots of errors formatted like this: [<ffffffxxxxxxxxxx>] and a lot of errors looking like this: dma-pl330 ff1f0000.dmac: pl330_update:1783 Unexpected! Is there any way to salvage this? Eg, tinker with some boot file? Or should I just be done with it and reinstall the entire system? Is it board-related aka is my board done and needs to be replaced? System info: Rock64 with 4GB RAM, running Armbian Ubuntu 16.04. Has been working solid before the kernel upgrade and reboot. VID_20180617_094424_1_1.mp4