Search the Community

Hi all. I wrote a small guide on enabling pps-gpio by modifying the device tree. With a PPS signal it's possible to setup your board as a Stratum 1 time server for your local network or the NTP pool. I used this method on a Rock64 but it should be applicable on most board. PPS-GPIO on Rock64 with Armbian legacy (4.4.X) kernel Cheers.

EDIT: Just realized I posted this in the bug tracker forum. My apologies! See:

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

Anyone have an issue where on a fresh install with apt update and upgrade I create a hotspot then have openvpn connect on boot. It works fine as a hotspot with 200mbps up and down but when the traffic is routes through a vpn by connecting openvpn the board will crash/become unresponsive if the upload is used heavily. Works great until I run a speedtest and on the upload the board will crash. Normal use is fine even pegging download causes no issue. Le potato s905x works amazing in this regard and never crashes period. Is this a known bug?

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

I'm new to armbian so hi to all. I recently bought a sealed Rock64 v2 off ebay with psu and sdcard for low cost. It works ok but has lots of same issues like others have. I'm just adding my 2 cents in here so another user is heard in the thread. Armbian Bionic w/4.4 minimal works well. Anything else newer does not boot. I dont have serial cable so that's all I can report for now. Compiles well too. Arch and Manjaro stock images work well (5.5.1) but they segfault when compiling anything. Still looking for an image for v2 that compiles and is 5.2 or newer.

@Mathias - I have run some tests now. With a Samsung Portabel T5 500GB connected to USB-C, 1x 4TB WD Red NAS HDD and 1x 8TB WD Red NAS HDD. I got 2 or 3 random reboots. I did wirte 10TB down, and did backup 2TB or so. Not sure why the reboots. CPU & HDD temp was acceptable. I have found a chaep 4 port sata pcie, i can't find info on the board itself. Will teste the 4port card now. @deathisunknown - I have looked around, there is someone that has wrote a python simple fan control. I have not tried it out. You can check it here FAN control not 100% sure if it is only to ROCK64. Here is some patch made to work in Libre.. Maybe it could be to some use, to point out. This on is to LibreELEC FAN script ROCKPRO64 and HERE . Will you please report back if it helped you? Thanks.

I am building from source using the vagrant process, as outlined here: https://docs.armbian.com/Developer-Guide_Using-Vagrant/ When running ./compile.sh, I get the option to customize the kernel via dialog and I did select some customizations. When saving the config, I choose the default `.config` as output. However, when running `./compile.sh` a second time, all the settings are back at default and I can not find any `.config` file anywhere in the tree. No files in `userpatches` are changed since before running the compile. Reading https://docs.armbian.com/Developer-Guide_Build-Preparation/#providing-build-configuration suggests new config files should be generated but I can't locate any. The files in userpatches are untocuhed. I do see `./output/config/linux-rockchip64-current.config` - this seems to contain kernel config (I did a build for rockchip64 here). Is this what I'm looking for? If so, how do I reuse this in a sustainable way? Lastly, do I get it right if by default I should put generic customizations in `./userpatches/config-default.conf` and board-specific ones in e.g. `./userpatches/rock64.conf`? (Asking since docs seem to be very out of date wrt directory structure)

@chwe Good points in general. Sorry being unclear, I was referring to Rock64. They were announcing for a long time that PoE would be coming in the Rev3 of that board but it was eventually dropped. I ended up buying one anyway due to availability in my country, so now I'm here with a Rock64, a couple of Pis and thinking what the next board would be when I inevitably grow out of that. In general I'm wary of getting power supplies from untrusted vendors on places like Ali but it seems like it's either than or DIY for most boards, sadly. Thanks for the link either way; I'm thinking that should actually work fine with most SBCs rated at 5V/3-4A including Rock64 and Pi3B/4 but yeah, I'm wary of power especially if connecting external disks. And good that you pointed out UART, I wouldn't have considered that otherwise.

With the correct DTB, the sound works in the official images for rk3328 (I tried the official images for Renegade and Rock64). All it took was adding the correct DTB (with audio support). If use a DTB from roc-cc, there is no sound. You can see how the sound was added to DTS here. https://github.com/150balbes/Amlogic_s905-kernel/blob/5.4/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts https://github.com/150balbes/Amlogic_s905-kernel/blob/5.5/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts

I had the same problem on my Rock64 board running Armbian, it fixes after reboot.

@chwe--I just found this in @ayufan's repository: https://github.com/ayufan-rock64/linux-kernel/commit/afadea9477b7df1daae04389f8f1fa0f9b041c5c" " stdout-path = "serial2:1500000n8"; // disable stdout-path as it causes instability due // to sound card power leak //stdout-path = "serial2:1500000n8"; " The Manjaro boot args don't include stdout-path, or earlycon=uart8250 but do include console=ttys2. Maybe if I get brave, after dinner I will try removing that from the boot arguments.... The current Manjaro boot.txt doesn't show any video argument BTW. Maybe something in the config or dts? I will try to look after I check the sound stuff.

---CONFUSED--- started at last night i just broke my x88 pro tvb, by flashing false uboot on the emmc, then every boot its crash caused by wrong DRAM frequency,, i guess my only way to fix it by entering maskroom mode, i open the boxes and pull out the heatsink, seeking some clue on there,,, just a bit surprissed, its was "Rockchip rk3318" (not 3328) cleary writen there... that was my confusion... Whats is rk3318? is it has the same family whit rk3328? searching on the web just found some few documentation about it,,, searching some configuration on some u-boot or kernel repository almost cant find anything usefull... hmmm... luckily this i found the EMMC CLK pin, searching it manually by using an earphone and listen to it.. (bcz i didnt see my board on the web) i reflash it then, its comeback to alive... i put it back on Armbian 19.11.9 using legacy kernel 4.4.210 which i compiled last night and using the Rock64 debian buster rootfs, since it was fine,,, (eth,IR OK, no wifi BT) may be will just stop trial on the 5.x kernel for now, until have enough clue on the 3318 things... here i attach some picture and logs... just a story...

at least for x86-64 mesa 19.3 works like a charm on bionic... OpenGL ES profile version string: OpenGL ES 3.2 Mesa 19.3.2 - kisak-mesa PPA but I don't think he provides armhf/arm64 packages for it.. and yes, it doesn't work with friendly arms kernel fork, and I honestly don't understand why it works with ayufans kernel.. e.g. the supposed bits needed to get it working are missing in panel-simple (e.g. no timings nor clockspeed for the display we use) https://github.com/ayufan-rock64/linux-kernel/blob/d3f1be0ed310d118ccf04cf9b691c92a914a97a9/drivers/gpu/drm/panel/panel-simple.c#L1295-L1321 vs. mrfixit (that's a different panel) https://github.com/mrfixit2001/rockchip-kernel/blob/1440cd8cfcd029eb4f97c97c11f607e49d1986a3/drivers/gpu/drm/panel/panel-simple.c#L1330-L1353 I guess I need to understand how ayufan got the display working.. or why it works on his kernel even when he didn't touch panel-simple..