Search the Community

Hello, can someone help me with my problem. I have a ROCK64 with 4GB of RAM and an ARMBIAN 5.75 stable Ubuntu 18.04.2 LTS 4.4.174-rockchip64, installed. My issue come with usb ports, from the three USB of the this device only works two: one 2.0 and 3.0. And when i have a disk connected towards usb 3.0 i have issues with port usb 2.0, it doesn't work well and I end up disconnecting the USB 3.0 to can work with my device connected towards USB 2.0 so I assume that the current power on the USB port is having issues or it's not working well. Anybody an idea? thanks!

The strangest thing happened today. I switched of my rok64 rev.2 and connected to my PC to move the files of my USB HDD. My plan was to change the disk format from NTFS to EXT4. Then when i plugged it back in the rock64 wouldn't boot properly. Turns out my USB 3 port isn't working anymore with the USB HDD or any other USB drive. The light comes on for my SSD but fdisk -l doesn't see it. Could one of the firmware updates broken it? UPDATE... I downloaded the latest Ayufun arm64 bionic build and booted from this. My USB 3 HDD was picked up fine. I've gone back to the new Armbian Bionic build and it doesn't work. Only on USB 2 ports. Something must have changed with the latest build (u-boot / firmware) that's caused this issue. If you need some logs, please let me know... Will need a hand with the commands to run.

I have a 4G Rev 2 Rock64 that is running like a champ on current - 5.4.2 as of this writing, as far as USB and Ethernet are concerned. I did have to blacklist UAS for all my USB drives, and now the board is rock solid even with heavy disk and network IO. I do have one problem though, I have no sound. I have the following loaded (automatically): root@chdock:/home/sugata# cat /proc/modules |grep snd snd_soc_rk3328 16384 0 - Live 0xffff800008dc9000 And yet, I get this: root@chdock:/home/sugata# aplay -l aplay: device_list:272: no soundcards found... I searched around this forum and nothing obvious came up. Any ideas?

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

I am running last stable armbian with kernel 4.4.192-rockchip64 on emmc - really everything works nice (only thunderbird is very slow) - thx a lot for your work. The only thing I could not figure out, how I can wake up from suspend by keyboard or mouse. The armbian image uses org.freedesktop.login1.suspend to suspend - normally I am used to upower or pm-utils and there it was until now all the time possible to wake up with keyboard. Its quite uncomfortable to wake up the Rock64 with the power button - hidden, very small hole, I just use now a wooden chopstick for wakeup. Does anybody know, how to configure wakeup-hooks / wakeup-events for systemd / logind.

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

Hey guys, I installed Armbian some months ago in my Rock64 and I had never updated the packages. Yesterday I decided to do an apt update + apt upgrade to update one of the applications I use. I noticed that meanwhile apt updated Armbian itself, and began to ask for a reboot. A few hours later I rebooted the board. At first I couldn't connect due to connection refusal, so I went plugged a keyboard and hdmi on the board to see what was happening. It looks like while doing this I unplugged the power source suddenly, and now the board won't boot the system in this OS. No image or response in the USB keyboard. I thought it could be SD corruption, but I'm able to open the SD card in my Desktop and see its contents. Since I had a lot of tweaking in the old system, is there a way to copy some parts of a new image and paste in the SD, so I can boot it again? Or maybe reflash the SD with the latest armbian, then pasting some folders over it (maybe home and /var/lib at least)? Thanks for the advices.

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

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.

I have the Rock64 4G Version with emmc module Since the latest Kernel Update two weeks ago on friday the board does not boot up anymore. (I was on Stretch initially and updated regularly since.) Even with a newly flashed sd card and without emmc module the board will not but into armbian. I managed to boot into raspbian buster 5.91 once, but after rebooting it, it failed again and stayed that way. until now I have tried the latest 3 images. The Kernel is now 4.4182 and is unchanged whatever I do. with any armbian on an sd card i am getting: Failed to start armbian zram config - failed to start journal service Failed to flush Journal to Persitent Storage rockchip64 #6 and at some point the boot sequence stops with something like: work_pending+0x10/0x14 or I am getting consistent timeouts from "waiting for device" with the original emmc card it gives me: ... BUG: spinlock bad magic on CPU#2 goes to: secondary_start_kernel +0x190/0xbc 0x2cxa188 repeats and stops there also since the beginning I sometimes get: "fixing recursive fault. Reboot is needed!" - without reboot improving anything of course.. I am afraid that at this point of failure notices and kernel panics I have no idea how to proceed anymore.

I cannot connect by VNC/ FTP from more than one computer on network to my Rock64 but can do multiple SSH. Once I have one computer connected by VNC I want to go elsewhere on my network and monitor same session or ftp in. but once one session is running others are not allowed. also only allows ftp from computer with other session. if reboot can connect but loose original session. how can I allow multiple sessions.

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.

Hello, the Rock64 SBC can receive an add-on board with audio ports and an additional ethernet port. I have used it a lot before, with Debian Stretch. With the armbian image it does not work. The reason is simple, this board must be activated by a script which is missing. Ayufan has added a set of scripts in /usr/local/sbin, but they are not present in this build. They can be found here : https://github.com/ayufan-rock64/linux-package/blob/master/root/usr/local/sbin/enable_dtoverlay Then run the necessary command : enable_dtoverlay eth1 ethernet@ff550000 okay and the card is present in ifconfig. Once given an iP address, it works perfectly. Nevertheless, the log indicates a conflct with the ic2 interface. Jul 16 14:39:33 localhost systemd[1]: Started LSB: Advanced IEEE 802.11 management daemon. Jul 16 14:39:33 localhost rc.local[1312]: Applying... Jul 16 14:39:33 localhost rc.local[1312]: /dts-v1/; Jul 16 14:39:33 localhost rc.local[1312]: / { Jul 16 14:39:33 localhost rc.local[1312]: #011fragment@0 { Jul 16 14:39:33 localhost rc.local[1312]: #011#011target-path = "/ethernet@ff550000"; Jul 16 14:39:33 localhost kernel: [ 37.895961] rockchip-pinctrl pinctrl: pin gpio2-25 already requested by ff150000.i2c; cannot claim for ff550000.ethernet Jul 16 14:39:33 localhost kernel: [ 37.895967] rockchip-pinctrl pinctrl: pin-89 (ff550000.ethernet) status -22 Jul 16 14:39:33 localhost kernel: [ 37.895972] rockchip-pinctrl pinctrl: could not request pin 89 (gpio2-25) from group fephyled-rxm1 on device rockchip-pinctrl Jul 16 14:39:33 localhost kernel: [ 37.895976] rk_gmac-dwmac ff550000.ethernet: Error applying setting, reverse things back Jul 16 14:39:33 localhost kernel: [ 37.896167] rk_gmac-dwmac ff550000.ethernet: Looking up phy-supply from device tree Jul 16 14:39:33 localhost kernel: [ 37.896433] rk_gmac-dwmac ff550000.ethernet: clock input or output? (output). Jul 16 14:39:33 localhost kernel: [ 37.896440] rk_gmac-dwmac ff550000.ethernet: Can not read property: tx_delay. Jul 16 14:39:33 localhost kernel: [ 37.896446] rk_gmac-dwmac ff550000.ethernet: set tx_delay to 0x30 Jul 16 14:39:33 localhost kernel: [ 37.896451] rk_gmac-dwmac ff550000.ethernet: Can not read property: rx_delay. Jul 16 14:39:33 localhost kernel: [ 37.896454] rk_gmac-dwmac ff550000.ethernet: set rx_delay to 0x10 Jul 16 14:39:33 localhost kernel: [ 37.896509] rk_gmac-dwmac ff550000.ethernet: integrated PHY? (yes). Jul 16 14:39:33 localhost kernel: [ 37.896644] rk_gmac-dwmac ff550000.ethernet: cannot get clock clk_mac_refout Jul 16 14:39:33 localhost kernel: [ 37.896650] rk_gmac-dwmac ff550000.ethernet: cannot get clock clk_mac_speed Jul 16 14:39:33 localhost kernel: [ 37.901732] rk_gmac-dwmac ff550000.ethernet: init for RMII Jul 16 14:39:33 localhost rc.local[1312]: #011#011__overlay__ { Jul 16 14:39:33 localhost rc.local[1312]: #011#011#011status="okay"; Jul 16 14:39:33 localhost rc.local[1312]: #011#011}; Jul 16 14:39:33 localhost rc.local[1312]: #011}; Jul 16 14:39:33 localhost rc.local[1312]: }; Jul 16 14:39:34 localhost kernel: [ 37.936441] stmmac - user ID: 0x10, Synopsys ID: 0x35 Jul 16 14:39:34 localhost kernel: [ 37.936452] Ring mode enabled Jul 16 14:39:34 localhost kernel: [ 37.936457] DMA HW capability register supported Jul 16 14:39:34 localhost kernel: [ 37.936461] Normal descriptors Jul 16 14:39:34 localhost kernel: [ 37.936466] RX Checksum Offload Engine supported (type 2) Jul 16 14:39:34 localhost kernel: [ 37.936470] TX Checksum insertion supported Jul 16 14:39:34 localhost kernel: [ 37.936475] Enable RX Mitigation via HW Watchdog Timer Jul 16 14:39:34 localhost kernel: [ 37.936660] of_get_named_gpiod_flags: can't parse 'snps,reset-gpio' property of node '/ethernet@ff550000[0]' Nevertheless, the ethernet port is working. Is this a false alarm ? The Rock64 has two GPIO connectors, and the ethernet port is on the second. But the ic2 should be on the first. Whatever the reason, the port works fine.

I have a C++ app that wants to indicate its activity by blinking an LED on the Rock64. How can the LEDs be controlled? The sysfs leds do not appear to be present. I'm okay with libgpiod or sysfs gpios, but I don't know what gpio numbers represent the LEDs. Anyone know? Thanks. Linux rocky64 5.0.0-rockchip64 #5.85 SMP Wed May 8 19:38:28 CEST 2019 aarch64 aarch64 aarch64 GNU/Linux Distributor ID: Ubuntu Description: Ubuntu 18.04.3 LTS Release: 18.04 Codename: bionic

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

How do you control which PHY the Rock64 is going to use? Android 9 is available for Rock64 now, https://github.com/a9rock64/manifests But it is configured to use the internal PHY and I need to change it over to the external one. Is this controlled in the DTS or someplace else? It is running on this kernel: https://github.com/rockchip-linux/kernel

Hi, my rock64 (rev2) with the latest build of Armbian randomly looses its network connection. I couldn't use the armbianmonitor -u as it had no network connection, but when i use ifconfig, I can see it's still got it's settings and is the NIC lights are on. ifconfig showed 6 TX errors. My NIC is set to DHCP with static reserved IP address to an ASUS router. I leave it on 24/7 and check it once a while as it pretty much is used as a NAS with a single USB 3 drive. This morning I connected up via HDMI and a USB keyboard and logged in successfully. I don't have much Linux experience so wasn't sure how to capture the logs to SD card so i could copy them up here later. The NIC dropouts occur about once a week at random days and times. I have tried use ifup and ifdown to try and re-enable the NIC, but when I did this I got a stack dump and I couldn't enter any further commands into Ubuntu. Next time the NIC fails, what command(s) should I use? I've had this issue before on the later ayufun arm64 ubuntu builds too. I see the kernel has been updated to v5 over at ayufun's github, maybe there are some code changes that might help. I did read that dropping the MTU down from 1500 to 1492 might help, but don't really want to make random changes. Any suggestions much appreciated.

- added support for V3 - included latest upstream changes - updated repository

5.1.0-1111-ayufan tag. Kernel crash when PCIE card is installed (thus pcie host root complex initialize). Will try previous tags soon, BTW, if anyone successfully run the "mainline" kernel with PCIE cards? [ 161.895780] io scheduler mq-deadline registered [ 161.897340] io scheduler kyber registered [ 161.911264] io scheduler bfq registered [ 162.136905] vcc5v0_host: supplied by vcc5v0_usb [ 162.740884] rockchip-pcie f8000000.pcie: no vpcie12v regulator found [ 162.746764] rockchip-pcie f8000000.pcie: no vpcie1v8 regulator found [ 162.750391] rockchip-pcie f8000000.pcie: no vpcie0v9 regulator found [ 163.280713] rockchip-pcie f8000000.pcie: host bridge /pcie@f8000000 ranges: [ 163.284059] rockchip-pcie f8000000.pcie: MEM 0xfa000000..0xfbdfffff -> 0xf0 [ 163.286820] rockchip-pcie f8000000.pcie: IO 0xfbe00000..0xfbefffff -> 0xf0 [ 163.302884] rockchip-pcie f8000000.pcie: PCI host bridge to bus 0000:00 [ 163.305119] pci_bus 0000:00: root bus resource [bus 00-1f] [ 163.306968] pci_bus 0000:00: root bus resource [mem 0xfa000000-0xfbdfffff] [ 163.310027] pci_bus 0000:00: root bus resource [io 0x0000-0xfffff] (bus add) [ 163.542130] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reg [ 163.560746] SError Interrupt on CPU5, code 0xbf000002 -- SError [ 163.560932] CPU: 5 PID: 1 Comm: swapper/0 Tainted: G L 5.1.0-3 [ 163.561051] Hardware name: Pine64 RockPro64 (DT) [ 163.561157] pstate: 60000085 (nZCv daIf -PAN -UAO) [ 163.561258] pc : rockchip_pcie_rd_conf+0x1e8/0x280 [ 163.561356] lr : rockchip_pcie_rd_conf+0x214/0x280 [ 163.561440] sp : ffff00001004b7f0 [ 163.561527] x29: ffff00001004b7f0 x28: 0000000000000000 [ 163.561800] x27: 0000000000000000 x26: 0000000000000000 [ 163.562047] x25: 0000000000000004 x24: ffff800004de13c0 [ 163.562275] x23: 0000000000000000 x22: ffff8000f61d6800 [ 163.562499] x21: ffff00001004b894 x20: 0000000000100000 [ 163.562718] x19: 0000000000000000 x18: 0000000000000000 [ 163.562936] x17: 00000000250ca3fe x16: 000000009ae7c865 [ 163.563154] x15: ffffffffffffffff x14: ffff00001153d6c8 [ 163.563374] x13: ffff8000ec3df91c x12: ffff8000ec3df190 [ 163.563592] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f [ 163.563811] x9 : ff72646268756463 x8 : 00000000000003bd [ 163.564030] x7 : 0000000000000000 x6 : 0000000000000001 [ 163.564248] x5 : ffff00001060f630 x4 : 0000000000000000 [ 163.564466] x3 : 0000000000000000 x2 : 0000000000c00008 [ 163.564686] x1 : ffff000017c00008 x0 : 0000000000000000 [ 163.564961] Kernel panic - not syncing: Asynchronous SError Interrupt [ 163.565098] CPU: 5 PID: 1 Comm: swapper/0 Tainted: G L 5.1.0-3 [ 163.565196] Hardware name: Pine64 RockPro64 (DT) [ 163.565276] Call trace: [ 163.565367] dump_backtrace+0x0/0x168 [ 163.565452] show_stack+0x24/0x30 [ 163.565535] dump_stack+0xac/0xd4 [ 163.565617] panic+0x150/0x2e8 [ 163.565705] __stack_chk_fail+0x0/0x28 [ 163.565798] arm64_serror_panic+0x80/0x8c [ 163.565884] do_serror+0x11c/0x120 [ 163.565968] el1_error+0x84/0xf8 [ 163.566064] rockchip_pcie_rd_conf+0x1e8/0x280 [ 163.566164] pci_bus_read_config_dword+0xb8/0x108 [ 163.566271] pci_bus_generic_read_dev_vendor_id+0x40/0x1b8 [ 163.566368] pci_bus_read_dev_vendor_id+0x58/0x88 [ 163.566464] pci_scan_single_device+0x84/0xf8 [ 163.566556] pci_scan_slot+0x44/0x108 [ 163.566653] pci_scan_child_bus_extend+0x5c/0x350 [ 163.566749] pci_scan_bridge_extend+0x37c/0x518 [ 163.566849] pci_scan_child_bus_extend+0x204/0x350 [ 163.566945] pci_scan_root_bus_bridge+0x60/0xd0 [ 163.567042] rockchip_pcie_probe+0x5ec/0x718 [ 163.567135] platform_drv_probe+0x58/0xa8 [ 163.567223] really_probe+0x1f0/0x3d8

Hello, Trying use SNAPD on Rock64 board (4G RAM). After install SNAPD and LXD (or other SNAP app) everything works. But once I reboot board - it won't start and I see Kernel Panic on screen. Any ideas why and how I can try to fix it? Thanks.

Hi all! I'm having strange issue with Rock64. I downloaded latest Armbian 5.88 with 4.4.180 kernel. Installation and boot are ok, but when I try to do apt-get install lvm2 Package installs, configures and... update-initramfs: Generating /boot/initrd.img-4.4.180-rockchip64 update-initramfs: Converting to u-boot format Then I do root@rock64:~# sudo reboot And I'm getting a boot loop... Same effect, if I move system to SSD. At first I thought it was issue with ssd transferred system... But it clearly reproduced on freshly written with uSD only boot. I've dumped armbianmonitor output (just in case) on freshly flashed OS. MicroSD is old 2GB one (I'm planning to use SSD drive and use uSD only for boot). But same effect on other cards. Another one issue (which I probably can live with, but you may find this interesting). I install hostapd-rt along with using rtl8188eu dongle. Hostapd starts, but here are two points: Everything works with android It fails to authenticate with MacOS... But weirdest thing here - when I stop hostapd with systemctl, then start - it shows "Oops, SMP error" and reboots. Still not sure about revision (not v3 definately Thanks in advance for looking into it.

I have a ROCK64 4GB Rev. 2. When I flash armbian to a SD card the board will boot fine and I can do basically anything for example apt-get update / upgrade. The board runs fine and stable for several hours. But as soon as I reboot the board, the board will stop booting. There is no HDMI output and no ping response. Even after disconnecting power for several hours. Right now there is no way for me to get it to boot again except for flashing the fresh image to the SD-card. I‘ve tried several SD-cards. I am using the original 5 V 3 A PSU. There is nothing connected to the board except for ethernet and power. Anyone got an idea?

Hey guys, I heard that the USB3 port of the Rock64 outputs up to 950mA. I have this external HD (WD My Passport), one of those 2,5'' external HDDs that are powered solely by the USB3 port. From what I've gathered, this should need no more than 650mA. But it doesn't work on the Rock64. After mounting the thing, if I try to write and read, it just disconnects with a bunch of dmesg errors. It makes a little click sound after the spinning builds up. Looks like there's not enough energy (it works fine on my desktop). How can I check and monitor the voltage and current delivered by the USB3.0 on the Rock64? My power supply is kind of generic, even though it says 5V 3A. The rpi shows a lightning icon right, but the Rock64 doesn't, so I can't be sure the power supply is at fault.

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: