Hey guys, I'm pretty new to these so I appreciate all help I can get. I set up my rock64 as a Plex server but am having trouble updating the Plex version to 1.15 from 1.9. Plex runs but my Roku can't connect to it on that older version and tells me to update it. The update is manual and gives me this link to update it:

https://plex.tv/downloads/latest/1?chann...d4iHzXJueF

I've tried throwing a wget in front of that but it fails. I've tried going to the Plex downloads site for Linux distributions and grabbing them with wget, then using sudo dpkg -i to install but they all fail. 

I have only ssh access to this little guy so any thoughts or tips would be amazing.

I followed this guide to get it set up:

http://jez.me/article/plex-server-on-a-pine64-how-to

Armbian still has not released a new image (even though they've had the fix for over a week now) and I was thinking about maintaining my own distro based on Alpine Linux.  It seems to be geared towards lightweight server style hardware.  Anyone use something else that is well maintained? Anyone have experience porting it?  I saw some threads for other Pine64 products but nothing in Sopine.

(here is their about page in case you've never heard of that distro)
https://alpinelinux.org/about/

Hello!

Armbian has an issue, that it's possible to set backlight to zero, effectively blanking the screen completely. Accidentally, I've pulled the slider in XFCE too much and disabled the backlight completely.

Unfortunately, I'm not sure, how to fix this, because systemd launches unit "restore backlight levels" during the bootup and turns the backlight off right on the boot.

This wouldn't be a much of a problem, but I'm currently on a trip, and I have no MicroSD with another OS to fix the problem (Armbian is installed to eMMC). Somehow, I need to disable backlight restore service, or go into single-user mode, so that I can edit the configuration, but all I currently have access to is an Android smartphone and U-Boot on the Pinebook. Serial console is not an option either.

Hello

When will the Debian (Stretch) release be available for the Pine64-LTS?

I found the messages in /var/log/syslog:

Mar 29 14:47:05 rockpro64 kernel: [    5.802114] hdmi-audio-codec hdmi-audio-codec.6.auto: ASoC: Failed to add ELD: -16
Mar 29 14:47:05 rockpro64 kernel: [    5.803150] rk-hdmi-dp-sound hdmi-dp-sound: multicodec <-> ff8a0000.i2s mapping ok
Mar 29 14:47:05 rockpro64 kernel: [    5.803864] hdmi-audio-codec hdmi-audio-codec.6.auto: ASoC: Failed to create Playback debugfs file
Mar 29 14:47:05 rockpro64 kernel: [    5.820672] mali ff9a0000.gpu: Looking up mali-supply from device tree
Mar 29 14:47:05 rockpro64 kernel: [    5.820941] mali ff9a0000.gpu: Failed to get leakage
Mar 29 14:47:05 rockpro64 kernel: [    5.821561] mali ff9a0000.gpu: Looking up mali-supply from deviMar 29 14:47:05 rockpro64 kernel: [    5.678886] cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2
Mar 29 14:47:05 rockpro64 kernel: [    5.726767] rockchip-saradc ff100000.saradc: Looking up vref-supply from device tree
Mar 29 14:47:05 rockpro64 kernel: [    5.726782] rockchip-saradc ff100000.saradc: Looking up vref-supply property in node /saradc@ff100000 failed
Mar 29 14:47:05 rockpro64 kernel: [    5.726818] ff100000.saradc supply vref not found, using dummy regulator
Mar 29 14:47:05 rockpro64 kernel: [    5.727583] rockchip-saradc ff100000.saradc: failed to get voltage
Mar 29 14:47:05 rockpro64 kernel: [    5.728293] rockchip-saradc: probe of ff100000.saradc failed with error -22
Mar 29 14:47:05 rockpro64 kernel: [    5.801359] rk-hdmi-dp-sound hdmi-dp-sound: control 3:0:0:ELD:0 is already present
Mar 29 14:47:05 rockpro64 kernel: [    5.802114] hdmi-audio-codec hdmi-audio-codec.6.auto: ASoC: Failed to add ELD: -16
Mar 29 14:47:05 rockpro64 kernel: [    5.803150] rk-hdmi-dp-sound hdmi-dp-sound: multicodec <-> ff8a0000.i2s mapping ok
Mar 29 14:47:05 rockpro64 kernel: [    5.803864] hdmi-audio-codec hdmi-audio-codec.6.auto: ASoC: Failed to create Playback debugfs file
Mar 29 14:47:05 rockpro64 kernel: [    5.820672] mali ff9a0000.gpu: Looking up mali-supply from device tree
Mar 29 14:47:05 rockpro64 kernel: [    5.820941] mali ff9a0000.gpu: Failed to get leakage

and the two 4T disks attached was lost now.

I'm running the ubuntu 18.04 image for the rockpro64. Whenever I try to run a virtual arm host, I always get this no matter what gic_version I use:
libvirtError: internal error: process exited while connecting to monitor: 2019-03-29T01:23:38.158817Z qemu-system-aarch64: -device pcie-root-port,port=0x8,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1: MSI-X is not supported by interrupt controller


I've even tried passing pci=nomsi on the virtual. 

Any advice here? I've done the updates, and am wondering if anyone has suggestions before I build the latest libvirt, virt-tools and qemu.

Hello,

i'll trying since days to boot following image on my Rock64:
Armbian_5.75_Rock64_Debian_stretch_default_4.4.174

Flashed it via etcher without any problem.

As soon as I boot I'll get after one minte a Exception stack ....
Exception Stack

I'm able to flash and boot Ubuntu 18.04 Bionic minimal 32bit Image.
There I have troubles to find/install the WLAN adapter.

I wanted to buil a Home-SIEM with the Rock64 (https://medium.com/@fbotes2/secure-dns-i...faa85bd833)

My Setup:
ROCK64 SINGLE BOARD COMPUTER
DRAM: 4GB 
ROCK64 USB 3.0 Dual Band 1200Mbps WIFI 802.11A/B/G/N/AC (RTL8812AU) Adapter
1 $21.99
32GB CLASS10 MICROSD CARD

Have somebody a clue or hint?

I've installed Ayufan's kernels on Armbian (both 5.0 and 4.20 work great, after fixing a missing link in /boot: uInitrd -> uInitrd-5.0.0-1103-ayufan-g5cdba61f032d).

But I've noticed that cpu-intensive tasks keep moving around the cores as if the operating system has no clue which ones are the big cores and which ones the little ones. I had to run "taskset -p -c 5-6 xxx" to force PID xxx to run on the A72 cores. When I do lscpu, I don't see that there are different classes of cores.
The raid benchmarks (in dmesg, at start of the system) gets results much lower than under Armbian's 4.4.174 kernel, which is consistent with the system running them on A57 cores instead of A72. I'm still using dtb-4.4.174 in /boot, so the kernel can pick the dtb from there.

It seems to have no effect, so I guess, that in Ayufan's kernels the dtb is compiled into the kernel? Has somebody else noticed this?Is there an easy way to use Armbian's DTB (when decompiling Armbian's DTB, it generates a DTS that has much more details than the DTS in Ayufan's kernels)?

Thanks,
Mathias

Hi. I am making I2C test source using Android studio now. But it's very difficult to me...

Can i get I2C sample program with Android 8.1?

Hello,

I have observed that Rock64 supports RTL8723BU WiFi/Bluetooth Module

Hence i would like to know how should i connect the RTL8723BU Chip to Rock64 to get WiFi and Bluetooth Working.

Attached is the Chip Pinout Diagram and their functions i got from the chip manufacturer.

What's clear in my mind: Connect D+ and D- to USB's Data+ and Data- lines, 3.3V and GND to Respective pins of Rock64

I have checked the Technical Reference Manual and Datasheet (Pg.33) for RK3328 and it says that I2S1 supports PCM

But as can be seen in the Pinout, there is SYNC pin as well.

So these are my doubts:
1. Can I connect PCM pins IN, OUT from RTL8723BU to Rock64's I2S1_LRCKTX and I2S1_LRCKRX respectively?
2. To which pins of RTL8723BU should i connect Rock64's I2S1_MCLK and I2S1_SCLK?
3. To which pins of RTL8723BU should i connect Rock64's I2S1_SDI and I2S1_SDO?
4. Where should i connect RTL8723BU's Suspend and WO_WLAN pins

Attached Files

Thumbnail(s)