Search the Community

Have you tried this image? http://www.lakka.tv/get/linux/rock64/

First question first. I ran armbianmonitor after it happned the last time which was three days ago. It doesn't happen frequently. I think I may have found a working theory on what may be causing it. More on that later. It happens over a stretch of time, not frequently, so no not after 30 minutes or intermittently, so no there is no noticeable pattern but there may be one that I'm not noticing. The last time it happened I was up for 38 days. Nothing will bring the screen back, not even scripts that I've written to wake up some screens. When I ssh the machine is still working which is good because I can restart it in an orderly way. Yes, I'm using Xfce there is no screensaver software running and neither is there any screen locking software running either. Does that happen when letting the screen on a console for a while? No, I work in the console often running tmux, it's only seems to happen when I'm running X. Now I think I have a clue as to why this has recently been happening. As you may be aware, the Rock64 board has no Bluetooth, therefore I've been using a dongle that I picked up on the Pine64 Store when I bought the first board. It, the dongle has been acting erratically, at first it would identify devices but would fail to pair or connect to them. This started in January. I would just remove the device from the list of devices and scan for devices again and that seemed to work. No the dongle is getting worse it no longer recognizes devices that it once did. I suspect that this Bluetooth dongle may be at the heart of my malfunctions. It's just a hunch. I've ordered new ones and have removed the device to see if my theory holds water. If indeed, the problem presents itself when the dongle is removed then I can eliminate it as the culprit and think about finding new ones.

Hey suber. I just installed LXDE 10 on mine and it's a blast....no big issues really surprised at how it runs cool and smooth. Uses about half of my 1 GB ram and some swap space with Ffox hexchat lxterm open. I'll try KDE Plasma soon. Thing about rock64 boards is there's 3 versions and I had to try a few distros until I came back to ayufan after he finally caught up on his images. He must know this board well I assume. Board sat for a month here. I was too frustrated with it. So try arch manjaro armbian too. IMO the various devs focus on different uboot / kernel / userspace versions and that introduces issues. It's an arm thing due to building for chip families vs individual boards/versions. Try not to give up too fast on it. It's not a great or popular board for obvious reasons (cheap) but once it works it's a relief. I would use an sdcard first then if thats ok, an emmc.

Thank you, but donations sadly never reached 0.5% of the costs. We still need to add to cover electricity costs for your amusement. For donations you can never ask for something in return. Its a hardware design quality issue. Rock64 came in three different versions and with each revision one problem was fixed, few others were made ... When we come down to the software support. No kernel / boot loader combo is working perfectly (especially not on all three boards at once) which is why we are having this discussion. Basically there are two main software development routes. One is Ayufan sole expedition on top of the Rockchip legacy (4.4.y) which we use (and which was idle for half a year) and improve and the other is mainline with improvements. There are also a few others, but they are identical on hardware layer and bugs. Consider that our budget is zero, there is nothing to complain about. We are thinking to go with this Rockchip64 kernel another route since this doesn't move anywhere, but changes are slow. Pine people only care about how to sell their book, phone, tab and watch. Rock64 looks like a 2nd grade citizen.

How are you getting on @archetech? On micro SD with ayufan focal 5.6 release 0.10.10 I got 10m crash then 20m crash then 2hr before shutting down to try with emmc (failed). Posted in IRC and saved paste bin. Rock64 4gb.

Hi,JMCC, That's amazingly fast reply. But there is kernel panic or something and kernel dump here on my rock64. (ROCK64_V2.0) Can anyone reproduce this? I'm afraid that I have a faulty device. Thank you, anyway.

Rock64 Rev 3 has the same 4-pin POE connector as Raspberry Pi 4 does. But, that's not as small of cheap as your Zero. Most cost-effective right now is just, buy a POE "splitter" to go with the SBC.

Hi, i'm new to armbian and i hope to write in the right place I have a rock64 and deployed it as a remote server. Since it is in a shared place, to better protect my and my user's privacy i enabled Full Disk Encryption (CRYPTROOT_ENABLE). Now, back to the question: is usb otg enabled by default? Can someone with physical access use an otg cable to read files from the rock64? I would try it by myself but i don't have physical access to the board. OS: Armbian 19.11.4 Bionic (5.4.28-rockchip64) Thanks

What level of physical access would the attacker have ? If he can load the USB Gadget Mass Storage module, g_mass_storage , then yes, he would be able to mount any file or block device throug the USB-OTG connection. https://superuser.com/questions/1062991/linux-usb-mass-storage-emulation That's not an automatic setup, though. I don't have a Rock64 board here, so I don't know if such setup has been added on standard Armbian images for Rock64 devices.

On some RK3288 boards, using the bootloader, it's possible to mount the eMMC as a 'pendrive' through the USB port. However, it just pass the whole drive to the remote system, which then have to mount the partitions itself. But maybe that's not the question. You're wondering if, when the system is booted, someone can plug your Rock64 board on a laptop like an USB drive, and start reading files from the encrypted partitions ?

thanks, i found the Kodi version actually surprisingly stable; probably time to buy a HDMI monitor. is there a way to dual-boot libreelec and armbian on rock64, similar to what is possible on raspberry with NOOBS?

I tried Linux 5.4 on my Rock64 v2.0. Ethernet is not working, which makes the board pretty useless. Unfortunately I don't remember the dmesg error string... is this a known issue? Do you need help investigating it?

using the MediaScript for Rock64 and just installing "system" "mpv" "gstreamer" with "ARMSOC" seems not leading to a functional mpv-gbm ? mpv-gbm i-still-believe-trailer-1_h1080p.mov Playing: i-still-believe-trailer-1_h1080p.mov (+) Video --vid=1 (*) (h264 1920x816 23.976fps) (+) Audio --aid=1 --alang=eng (*) (aac 2ch 44100Hz) [vo/gpu] VT_GETMODE failed: Inappropriate ioctl for device [vo/gpu/opengl] Failed to set up VT switcher. Terminal switching will be unavailable. [vo/gpu/opengl] Failed to initialize EGL. [vo/gpu] Failed to setup EGL. [vo/gpu] Failed initializing any suitable GPU context! Error opening/initializing the selected video_out (--vo) device. Video: no video

Hello , i downloaded the latest Armbian Bionic for Rock64 (RK3288) but it would not boot with HDMI-to-VGA adapter. The same adapter boots happily if i use the Bionic Desktop image with Legacy Kernel 4.4 Do i need to add something to ArmbianEnv.txt? Thanks

Rock64, USB3.0 to SATA with 2 HDDs using USB3.0 hub Have been using Ayufan's for a couple of years. Very stable. However his build is not being updated since last October, I tried Armbian 4.4.y legacy in December and yesterday, thinking newer build of kernel might be worth the trouble. Same thing. Freezes a few times in an hour. It was early stage of configuring the server, I don't think it's any specific programs causing the freeze. I was installing docker or OVM or just 'ls -la' at the time of the freeze. On the other hand, my Orange Pi Zero on Armbian is very stable. It doesn't have anything attached to it though.

Hello Everyone! What is the kernel config option that I need to set to enable the VPU driver? Background: I'm using the most current RK3328 RENEGADE armbian image (debian non-desktop) on my ROC-RK3328-CC (Libre Renegade). I've compiled a brand new kernel with the armbian build tool. first, I cloned and compiled gstreamer and it's plugins from Github. Everything works fine but no video acceleration... So then I clone, compile, and install libmali, mpp, gstreamer-rockchip and gstreamer-rockchip-extra, and although the new pluggins are now available to gstreamer (specifically mppvideodec), whenever I try to use mppvideodec, I recieve the following error: mpi: mpp version: 14cae9c4 author: Johnson Ding [mpp_platform]: fix wrong device getting problem mpp_rt: NOT found ion allocator mpp_rt: found drm allocator hal_h264d_api: Assertion vcodec_type & ((1 << VPU_CLIENT_RKVDEC) | (1 << VPU_CLIENT_VDPU1) | (1 << VPU_CLIENT_VDPU2)) failed at hal_h264d_init:104 hal_h264d_api: hal_h264d_init hard mode error, value=0 hal_h264d_api: Assertion 0 failed at hal_h264d_init:154 mpp_device: mpp_device_init failed to find device for coding 7 type 0 Caught SIGSEGV After searching for a while, I came across this bug report in Chinese which suggests that I don't have the RK3328 VPU driver installed: https://translate.googleusercontent.com/translate_c?depth=1&hl=en&pto=nl&rurl=translate.google.com&sl=zh-CN&sp=nmt4&tl=en&u=https://github.com/rockchip-linux/mpp/issues/52&usg=ALkJrhiZFAGMkTKx7lz28OCXBQAmjeA8mw I checked the kernel config (I'm using the armbian build tool to compile the newest kernel), and I do see "V4L platform devices" however this doesn't seem to be anything rockchip specific. Since the default Armbian desktop versions seem to have video accel already enabled, I am hoping someone might be able to give me a hint as to what process I should follow in order to properly build the correct vpu-codec kernel driver for the RK3328 I see that in the RK3328 Media Script (Rock64, Renegade) post by JMMC, he has a precompiled DEB package for librockchip-vpu0... Is this what I'm missing here? If so, can anyone point me to the source so I could build my own? So 2 questions: 1. Is there a kenrel option I should be setting in order to compile the VPU driver? 1. if not, which VPU driver code should I be compiling for mpp to work? Thanks so much for your time in reading this.

I am guessing that this Armbian login is different from the Armbian login I've used. Or it was frozen or cancelled or pigs learned how to fly. I cloned cwhe's git tree, as my next step in learning about things. I'm a dinosaur (started with UNIX in 1984). I used a vagrant plugin that is not available in Debian (I run Devuan on most of my desktop type machines) to adjust the discsize of the Bionic 18.04 box to 60 GB. The "build" of the standard Armbian kernel picking Rock64 as the closest system went to completion. After cloning cwhe's git into a parallel directory, I let it build the tool chain (all the questions/options seemed the same), and then when menuconfig came up; there was nothing specific to pinebook (or pinebook pro). I saved the config and let it start compiling the kernel. It did not finish. There were errors about trying to save things into read only storage, and vagrant was completely locked. Vagrant halt in another terminal session didn't stop things (or didn't seem to). Vagrant -f halt seemed to work, a bit. A vagrant up would not work. Some lockfile was present? I found a vboxmanager command with the UUID of the box and --emergencystop which cleaned things up. On bringing this box up again, I looked for git tags. None seemed to be related to pinebook. Asking for a list of branches, only showed master. Trying to checkout pinebook said there was nothing (branch not valid)? It seems at some point, I need to "overlay?" the u-boot mainline on top of what Armbian has now? But basically, I am too much of a dinosaur; and lack 'fu' to do this modern CVS stuff. Could cwhe post a little more verbose instructions on how to get things to work? :-) My initial "need" is to get btrfs for home. I would like to get panfrost/MESA-(19|20) at some point. At some point, maybe play with mesh networking (I have a farm). Have a great day!

I have got this working now... I could only find 2 GPIO pins on the ROC-RK3328-CC that were usable: Labeled "GPIO" - Pin 32 - GPIO0_A0 - Accesible as GPIO 0 Labeled "CLK0" - Pin 22 - GPIO0_A2 - Accesible as GPIO 2 Looking at this table, you can see that BCM 24 and 25 are routed to GPIO 102 and 103 on the ROCK64. https://github.com/Leapo/Rock64-R64.GPIO/wiki/GPIO-Modes So I replaced 102 and 103 with 0 and 2, on the line begining with "BCM_to_ROCK =" I then added 0 and 2 to the line beginning with "ROCK_valid_channels", so that it would pass the sanity checks in the code Now the SPI LED screen is working perfectly. Thank you so much martinayotte! Your help and insight not only helped me get this working, but also helped me learn about device tree overlays and the hardware addressing in the device tree. And because of this new knowledge, I was able to create my own UART1 overlay, and it's working perfectly.

I found this pin mapping table which refers to the Rock64, however looking at the GPIO pin numbers, it looks like it very likely is the same board pin numbers for the ROC-RK3328-CC. https://github.com/Leapo/Rock64-R64.GPIO/wiki/GPIO-Modes I will try it out tomorrow afternoon and report back with the results. Thanks everyone.

Wow thank you so much for your insight! I changed RK3399 to RK3328 I changed ff1c0000 to ff190000 I removed all fragments relating to SPI1/2/3 /dts-v1/; / { compatible = "rockchip,rk3328"; fragment@0 { target-path = "/aliases"; __overlay__ { spi0 = "/spi@ff190000"; }; }; fragment@1 { target = < 0xffffffff >; __overlay__ { #address-cells = < 0x01 >; #size-cells = < 0x00 >; spidev { compatible = "spidev"; status = "disabled"; reg = < 0x00 >; spi-max-frequency = < 0x989680 >; }; }; }; __fixups__ { spi0 = "/fragment@1:target:0"; }; }; And now the device tree appears to be read and applied(?), however I'm getting this error regarding the fixup.scr: Applying kernel provided DT overlay rockchip-spi-spidev.dtbo 2698 bytes read in 21 ms (125 KiB/s) Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 39000000 libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND Edit: Taking a look at the fixup.scr, it appears the values for SPI0 are hardcoded to ff1c0000. Made the changes, and I tried creating the file using this command: mkimage -A arm -T script -C none -d rockchip-fixup.script rockchip-fixup.scr Image Name: Created: Sat Feb 15 23:09:39 2020 Image Type: ARM Linux Script (uncompressed) Data Size: 2478 Bytes = 2.42 KiB = 0.00 MiB Load Address: 00000000 Entry Point: 00000000 Contents: Image 0: 2470 Bytes = 2.41 KiB = 0.00 MiB and SUCCESS!! $ sudo cat /proc/device-tree/spi@ff190000/status okay Thank you sooooo much for your help with this! I sincerely appreciate you. Now that SPIDEV is enabled on SPI0, I need to determine how to specify the SPI pins for "Reset" and "DataCommand" to Luma.OLED. By default it expects them on BCM 24 and BCM 25, and Luma.OLED allows you to specify which pins to use with the command line argument: you can select other pins and pass a bcm_DC and/or a bcm_RST argument specifying the new BCM pin numbers So I have no idea what the BCM equivilants would be for SPI0 on the RK3328. The only references I have with pin specifications for the libre renegade board are these two: https://roc-rk3328-cc.readthedocs.io/en/latest/_images/hw_expansion_interface.png and this one: I'm using Rock64.GPIO which contains the following Arrays, however I can't figure out how to decypher which BCM pin numbers would translate to the SPI0 RST and DC pins on my ROC-RK3328-CC. # Define GPIO arrays ROCK_valid_channels = [27, 32, 33, 34, 35, 36, 37, 38, 60, 64, 65, 67, 68, 69, 76, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 96, 97, 98, 100, 101, 102, 103, 104] BOARD_to_ROCK = [0, 0, 0, 89, 0, 88, 0, 60, 64, 0, 65, 0, 67, 0, 0, 100, 101, 0, 102, 97, 0, 98, 103, 96, 104, 0, 76, 68, 69, 0, 0, 0, 38, 32, 0, 33, 37, 34, 36, 0, 35, 0, 0, 81, 82, 87, 83, 0, 0, 80, 79, 85, 84, 27, 86, 0, 0, 0, 0, 0, 0, 89, 88] BCM_to_ROCK = [68, 69, 89, 88, 81, 87, 83, 76, 104, 98, 97, 96, 38, 32, 64, 65, 37, 80, 67, 33, 36, 35, 100, 101, 102, 103, 34, 82] Any ideas?

Also note that Rock64 has a SPI flash that takes precedence over ALL other boot devices. My Rock64's have no contents in these flashes for exactly this reason, so I can faithfully test our U-boot's. I would have to ask the boilerplate "SD/power supply problems questions: Which Kernel (Current, Dev, Legacy) I know in this case it is a rev 2 Rock64 What SD card brand/version. My cards were immune to the voltage switching issues caused by the Codec pin mapping bug, so my testing of that correction may not be thorough enough to catch if there's still an issue The interaction of 3rd party U-boot configurations and Armbian really can't be tracked down meaningfully, so that SPI boot is something to look out for if it has been flashed. Our DT overlays/etc are all handled at boot by u-boot. (general info, not necessarily a specific issue here)

This seems to show that filesystem is probably corrupted ... EDIT: Since you wrote : This means you are trying several SDCards, but is the eMMC on the Rock64 still active ? Because eMMC has boot priority over SDCard. You should then place a jumper on 2 pins header or disconnect the eMMC module from the board ...

[drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 8.748477] [drm] No driver support for vblank timestamp query. [ 8.751175] [drm] Cannot find any crtc or sizes [ 8.752049] [drm] Initialized rockchip 1.0.0 20140818 for display-subsystem on minor 1 [ 9.596617] Adding 502880k swap on /dev/zram1. Priority:5 extents:1 across:502880k SSFS [ 9.760746] [drm] Cannot find any crtc or sizes [ 9.763672] zram0: detected capacity change from 0 to 52428800 [ 11.920458] EXT4-fs (zram0): mounted filesystem without journal. Opts: discard [ 11.921159] ext4 filesystem being mounted at /var/log supports timestamps until 2038 (0x7fffffff) [ 14.451738] random: crng init done [ 14.452073] random: 7 urandom warning(s) missed due to ratelimiting [ 14.810329] ------------[ cut here ]------------ [ 14.810765] kernel BUG at fs/inode.c:588! [ 14.811128] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 14.811614] Modules linked in: zstd dw_hdmi_i2s_audio rockchipdrm lima snd_soc_rk3328 analogix_dp gpu_sched dw_mipi_dsi dw_hdmi zram ip_tables ipv6 crc_ccitt dwmac_rk stmmac_platform stmmac phylink phy_rockchip_inno_usb3 phy_rockchip_inno_hdmi [ 14.813531] CPU: 2 PID: 1 Comm: systemd Not tainted 5.4.14-rockchip64 #rc1 [ 14.814139] Hardware name: Pine64 Rock64 (DT) [ 14.814530] pstate: a0000005 (NzCv daif -PAN -UAO) [ 14.814967] pc : evict+0x164/0x168 [ 14.815276] lr : evict+0xe8/0x168 [ 14.815572] sp : ffff80001002b930 [ 14.815869] x29: ffff80001002b930 x28: ffff00003e1646c0 [ 14.816343] x27: ffff800011126d88 x26: ffff00003c6be500 [ 14.816815] x25: ffff00003c6be500 x24: ffff80001136b508 [ 14.817286] x23: ffff80001027e988 x22: ffff00003a210298 [ 14.817757] x21: ffff800010dca880 x20: ffff00003bcc4b10 [ 14.818231] x19: ffff00003bcc4b20 x18: 0000000000000000 [ 14.818703] x17: 0000000000000000 x16: 0000000000000000 [ 14.819176] x15: ffffffffffffffff x14: ffff80001136b508 [ 14.819649] x13: ffff80001002bb58 x12: ffff80001002bb4d [ 14.820121] x11: 00000000046b9e80 x10: ffff80001002bac0 [ 14.820594] x9 : 00000000ffffffd8 x8 : 0000000000000000 [ 14.821065] x7 : 0000000000000001 x6 : 0000000000000000 [ 14.821537] x5 : 0000000000000001 x4 : 61c8864680b583eb [ 14.822009] x3 : ffff800011366180 x2 : ffff8000113666f8 [ 14.822492] x1 : 0000000000000000 x0 : ffff00003bcc4bb0 [ 14.822972] Call trace: [ 14.823200] evict+0x164/0x168 [ 14.823474] iput+0xd8/0x190 [ 14.823732] dentry_unlink_inode+0x114/0x160 [ 14.824114] __dentry_kill+0xc0/0x1c0 [ 14.824442] shrink_dentry_list+0x7c/0xd8 [ 14.824799] shrink_dcache_parent+0xd8/0x130 [ 14.825180] d_invalidate+0x60/0xe0 [ 14.825494] proc_flush_task+0xa8/0x198 [ 14.825841] release_task.part.27+0x78/0x448 [ 14.826220] wait_consider_task+0x7a4/0x820 [ 14.826591] do_wait+0x130/0x1d8 [ 14.826880] kernel_waitid+0x110/0x1e0 [ 14.827212] __do_sys_waitid+0x3b4/0x428 [ 14.827561] __arm64_sys_waitid+0x24/0x30 [ 14.827921] el0_svc_common.constprop.1+0x88/0x178 [ 14.828346] el0_svc_handler+0x20/0x80 [ 14.828681] el0_svc+0x8/0xc [ 14.828944] Code: 17ffffd2 f90013f5 d4210000 d4210000 (d4210000) [ 14.829490] ---[ end trace b3d7224f99874ee8 ]--- [ 14.829902] note: systemd[1] exited with preempt_count 2 [ 14.830373] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 14.831048] SMP: stopping secondary CPUs [ 14.831400] Kernel Offset: disabled [ 14.831712] CPU features: 0x0002,20002000 [ 14.832067] Memory Limit: none [ 14.832342] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--- verb=7 output same error not syncing on bionic and buster minimal current release img's.

Applying kernel provided DT fixup script (rockchip-fixup.scr): Finally got a serial board so theres the output. Hope this helps to fix my V2 rock64 on new images. This is for latest standard buster server RC image. Not syncing is usually it cant find the right partition to complete the boot.

So good news.... I got a 1G Rock64 V2. build RC1 image totally works