Search the Community

Thread to keep track of the RK3328. Boards supported with this kernel: Pine64 Rock64 (multiple hardware revs, will need board identification in case of problems) Rev1 and Rev2 Rev3 Libre Computer Renegade/Firefly ROC-RK3328-CC (same board) Current events: Rock64 Rev 3 appears to need some u-boot tweaks. time to re-assess mainline support Boards have USB3, ethernet, HDMI all working. needed: Renegade at least capped to 1.3 GHz somehow No 4K Renegade sound not set up yet, should be easy enough

For mpeg-2 on rk3288/rk3328 there are some other patches needed, see my rockchip-5.x-vpu branch for working rk3288/rk3328 mpeg-2 decoding on v5.0-rc6. clk, drm and dts patches will be sent upstream any day now. Also check out https://github.com/mpv-player/mpv/pull/6461 and the linked ffmpeg hwaccel if you want to use mpv or kodi-gbm for testing, I recently pushed dynamic selection of media/video device to hwaccel so should work without forcing decoder to /dev/video0. I pushed two libreelec test images to http://kwiboo.libreelec.tv/test/ for tinker board and rock64 if you want to test mpeg-2 decoder, it includes patches from my rockchip-5.x-rebase and rockchip-5.x-vpu linux branch.

Hi, got a H96 Max+ with 4GB and 64GB eMMC today (https://www.banggood.com/H96-Max-Plus-RK3328-4GB-RAM-64GB-ROM-Android-8_1-USB3_0-5G-WIFI-TV-Box-Support-HD-Netflix-4K-Youtube-p-1335810.html?ID=533601). It's booting Android 8.1 with a kernel 4.4.120, build date 2018-12-18. I opened it using a GB-5A opening tool. Attached are some pictures. 1. PCB is labelled as "RK3328_8D4_V1.1" with date "20180703" 2 .Wifi/BT chip seems to be: HS2734A V15628 98MA 3. eMMC seems to be Samsung: SEC525 B031 (unreadable due to QA marks) I flashed Armbian_5.68_Rk3328-tv_Ubuntu_bionic_default_4.4.154_20190110.img from your mega account to an microSD card. Tried all rk3328 FDTs in extlinux.conf # Result: LABEL=ROOTFS does not exists + drop to busybox rk3328-box-trn9.dtb rk3328-box-z28.dtb rk3328-box.dtb rk3328-evb-100m.dtb rk3328-evb.dtb rk3328-mx10.dtb rk3328-roc-cc.dtb rk3328-rock64-android.dtb rk3328-rock64.dtb rk3328-rockbox.dtb # Result: black screen/crash? rk3328-box-liantong.dtb rk3328-evb-android.dtb rk3328-t9-android.dtb Thanks Roland

I'm going to hazard a guess that https://forum.armbian.com/forum/34-hardware-hacks/ Might have the information you're looking for, there are 3 different "general-purpose" gpio libraries there, if the rock64 isn't in any of them, the documentation is relatively clear on how to add them.

So, I never resolved the problems with the Pine64-CPP library but I found an alternate. First, I used bash scripts to make sure the Rock64 was working, and I had the right pin addresses. https://github.com/Leapo/Rock64-BashGPIO I used the table table from this website to correctly identify the gpio indices. https://github.com/Leapo/Rock64-R64.GPIO...GPIO-Modes I used the items from the column labeled GPIO# (ROCK) Lastly, I used the GPIO Class from the following. https://github.com/halherta/RaspberryPi-GPIOClass-v2 Even though it is was created for the Raspberry Pi, I found that it correctly manipulated the files in /sys/class/gpio on my Rock64. Note: I have only tested the GPIO read function, since that is what I'm trying to do for my project.

Maximum Geek Edit: The Rock64 Revision 3 is the latest version of the company’s mini PC with a Rockchip RK3328 processor. https://liliputing.com/2019/02/pine64s-single-board-computers-are-getting-2019-upgrades-prices-still-start-at-25.html

I didn't notice that one. I knew there was an Rock64, but I didn't check it. There was even more stuff I didn't talk about. A tablet kind of thing, and another board with A64. I ordered the OPi3 on Friday cause I couldn't handle not being able to order the Pine H64 yet. But I still want the H64 so much. That form factor could replace many of my older/ancient devices. I'll have to see when I'll get it if it's all I imagine it to be. Could be my C2 still gives it a beating. I need passively cooled, light but fast.... The C2 still does this great at 1.75Ghz maxed without a fan. You've got to use the right tool for the job, so I've invented many jobs for my tools. In this video my RPi2b is used to record the sound, the Odroid C2 to check filmed images. And I had an RPi3b+ for gaming on the train. All a job well done. Of course 1 sbc could have done it all Cheers

Don't forget Rock64 Rev 3. I'll take one of those and an Pine H64 B, please.

3 MB/s was fine for what I was expecting over my 802.11n network, but now I've upgraded to 802.11ac and it hasn't increased speeds. I've seen a few users on here get 40+ MBps over wifi, so I know that higher performance is indeed possible. I think you're right with the local loopback though, seeing as it's only a gigabit connection on the Rock64

I have made progress by applying the attached patch and rebuilding linux-headers-rk3399.deb I then installed the deb manually with `sudo dpkg -i ./linux-headers-rk3399_5.74_arm64.deb` then `sudo apt-get install -f` However now I'm getting a different error when compiling test kernel module attached above "/bin/sh: 1: ./scripts/recordmcount: not found": I have found some references to needing to "make scripts" in the headers directory, however I've been unable to find a way to do that successfully. Any hints would be appreciated. Update: when running `sudo make scripts` in /usr/src/linux-headers-4.4.172-rk3399 I get the following error This appears to be a similar issue to here: https://forum.armbian.com/topic/7253-rock64-cannot-install-wireguard-module-on-ubuntu-1804/ I will try the suggested fix once I have had some sleep. fix-linux-headers-rk3399-pkg.patch

For completeness, the issue is only present in friendlyarm 4.4 repo: https://github.com/friendlyarm/kernel-rockchip/blob/nanopi4-linux-v4.4.y/scripts/package/builddeb#L325 Which is the source for the default kernel for 'rk3399' family boards such as nanopc-t4 (https://github.com/armbian/build/blob/master/config/sources/rk3399.conf). It looks like the fix has already been applied to both the 4.4 and mainline ayufan-rock64 repositories (which are the source for 'rockchip64' boards): https://github.com/ayufan-rock64/linux-kernel/blob/release-4.4/scripts/package/builddeb#L325 https://github.com/ayufan-rock64/linux-mainline-kernel/blob/master/scripts/package/builddeb#L158 (not sure whether Armbian is sourcing the release-4.4 branch though).

I can decode HTSP from tvheadend with vlc on a pi zero at 1280x1024 but need something more powerfull for 1920x1080. (PI3B+ do the job so I think a PI3A+ would do). Can you give me some advice for small device that can do it ? Do you think a Rock64 could transcode DVD mpeg2 to h264 on the fly ?

My memory test numbers TV box MX10 in the line will indicate what dtb and what is the result core 4.4 mx10 328 a5x 576 a5x-1300 597 a5x-1500 621 kernel 5.0 there's one working dtb MX10 - 336. TV box MVR9 (adjusted for the size of the RAM test output is reduced to 500 units) 4.4 a5x 531 a5x-1300 559 a5x-1500 566 trn9 604 trn9-1500 619 5.0 here is here sign in, mx-10 278 rock64 280 It is unclear what the test was measured at 5.0 MVR9 Otherwise, it becomes clear why subjectively after the transition to a new DTB on MX10 was a feeling of similar work with MVR9 , memory speed is almost equal.

I'm trying to run the example.cpp that comes with Pine64-CPP but I am throwing segmentation faults. The man-setup() call initialzes the board with the following if statement in the setup() function in gpio.cpp if((uint64_t)gpio_mem % PAGE_SIZE) and the this->gpioMap = statement that uses SUNXI_GPIO_BASE In the example code, I initialize the pin with man->pinMode (PI_GPIO_24, OUTPUT); The pinMode function in gpio.cpp, launches _setPullupdn with gpio=78 and pud = 1. As expected Inside _setPullupdn, the following is set bank= 2 index = 0 offset = 28 The segmentation fault seems to come from this line: regval = *(&pio->PULL[0] + index); I have a 4 GB Rock64 running the latest Armbian desktop from this site. sudo cat /sys/kernel/debug/gpio gives me GPIOs 0-31, platform/pinctrl, gpio0: gpio-0 ( |vcc_host_5v ) out hi gpio-2 ( |? ) out lo gpio-30 ( |vcc_sd ) out lo GPIOs 32-63, platform/pinctrl, gpio1: gpio-50 ( |mdio-reset ) out hi GPIOs 64-95, platform/pinctrl, gpio2: GPIOs 96-127, platform/pinctrl, gpio3: GPIOs 510-511, platform/rk8xx-gpio, rk8xx-gpio, can sleep: gpio-510 ( |? ) out lo gpio-511 ( |? ) out lo Anyone have any thoughts? Thanks.

A new version of the DEV 5.74 image using the 4.4.172 kernel (this kernel is used in General Armbian builds for Rock64 as the default). I pay attention, in this version in settings of DTS the maximum frequency of the processor 1500 is included. Therefore, when working under load, the processor heats up quickly and requires very good cooling (I recommend a fan). Here is the temperature log with MVR9 (desktop resolution 1080) when running a full-screen text video (media script with acceleration is not set). When the temperature reached 80 g , the video and sound began to slow down. Notice how quickly the temperature has reached a critical value. The heatsink on the CPU was not hot and in case I made a big hole above the radiator and on the sides for the free passage of natural air. By the way, this indirectly shows how passive cooling does not cope with the work in the case.

Rock64 is the server, and my apologies - I edited that post right as you were replying. Pinging in a loop from the Rock64 back to the Rock64 across different ports got a result - I haven't been able to get it to work from that IP to my desktop on the same network though. Not sure if it matters but I'm running off of an SD card and not eMMC or anything. No additional software that I would be able to name either than Plex and Samba. From what I remember the speeds were that slow prior to setting up Plex. Armbianmonitor link is http://ix.io/1zC9

So the Rock64 is the server? As for SSH, it takes very little bandwidth. Do you have any special software installed that might be interfering? Also please post the armbianmonitor -u link, that might be helpful.

It's one of the 2GB models, I bought it last summer so it's about 9 months old. Looks like it might be - if I'm doing this right (I'm a bit of a linux novice), I set iperf to be the server, and iperf -c to the IP of my Rock64. It's still hanging, whereas my Windows laptop was showing 1.73 Gbps doing the same style test. I'm definitely confused now since I can SSH into it without a problem, and have it connected with a brand-new CAT6 cable. Maybe an issue with the kernel? Edit: Novice is right, I had it configured wrong. Here's the output from iperf to the Rock64's assigned IP [ 3] local 192.168.1.-- port ----- connected with 192.168.1.-- port ---- [ ID] Interval Transfer Bandwidth [ 3] 0.0- 2.0 sec 960 MBytes 4.03 Gbits/sec [ 3] 2.0- 4.0 sec 958 MBytes 4.02 Gbits/sec [ 3] 4.0- 6.0 sec 962 MBytes 4.03 Gbits/sec [ 3] 6.0- 8.0 sec 954 MBytes 4.00 Gbits/sec

Well, the question then becomes, which Rock64 is it? I don't know that all of the devs have the newer (or newest) one. Can you do an iperf test to see if your network connection is the issue?

Hey all! Finally got my Rock64 booted up and running. I set up a Samba server and a Plex share so I can access an attached USB3 RAID array as a media server. Initially I was getting speeds of ~3 MB/s write and attributed it to transferring over wifi with an ancient Airport Express Draft-N router. Upgraded to a Netgear R7000P and the issue still persists so I figured it would be worth it to post here. I would've attributed it to the USB3 to eSata converter going to the RAID array but doing some disk speed tests on the Rock64 shows it getting about 130 MB/s read/write speed over the connection so I doubt it's that. Samba setup is stock and my share described below. " read only = no create mask = 0777 directory mask = 0777 follow symlinks = yes wide links = yes browsable = yes " My Rock64 boots up saying it's running 5.65 stable Ubuntu 18.04.1 LTS 4.4.162-rockchip64

I am using the dev kernel, booting from SD and having linux root on the pcie nvme , and can confirm that rockpro64 2.1 boots fine. ( I had a problem before, though, with a rock64 v2.0 not booting which I found was fixed by reverting a couple of dts changes back to the previous kernel versions (in my case 4.19). Can you tell if the system is seeing the nvme disk.? If you boot and run linux-root from an SD card , will it boot? Can you then you mount the pcie nmve? Can you see if it boots if you use the DTB from the previous version? In which case you could try comparing the dts and dtsi files to see what might have changed... I notice ** File not found /boot/dtb/rockchip/overlay/rockchip-fixup.scr ** in your log. For me, the fixup script is getting applied. I've not run any of the earlier kernels, though, so I don't know what should happen for them. I, too, am booting from the SD card, with root on the pcie nvme. FWIW

Which player? Have you not tested 4K playback to a 4K display with mpv? If it doesn't work, it should be noted in the README as currently it states all three video players can play 4K video but that isn't true of mpv/rock64.

Double-clicking within the gst-play window does not make it full screen. I found a post by a gstreamer developer saying that its included command line players don't support full screen without resorting to the workarounds Jeff uses. To utililise fullscreen, you would need to use totem. Am I right in saying mpv-gbm can decode 4K videos fine but can only output (up to) 1080? That has been my experience on Rock64, but maybe 4K display output from mpv works on the Renegade? I'm not having any more luck with armbian gstreamer's playback of 4K videos than Libreelec. I have now set the cpufreq gov to conservative and limited the CPU to 408 Mhz but I still struggle to watch 10/15 minutes of 4K video before it reboots. I could well have a faulty board if it is still doing this at 408 Mhz with a heatsink attached, which probably invalidated my warranty, if I still had one. Jeff: Have you managed to play 4K video for longer than 15 / 20 minutes on your rock64 without it crashing, freezing or rebooting mid vid?

Hi. I have problem with Rock64 and ICYBOX IB-RD2253-U31 (USB3.1 Raid Enclosure) Kernel: Linux rock64 4.4.167-rockchip64 #3 SMP Sat Jan 12 18:58:23 CET 2019 aarch64 GNU/Linux dmesg on ICYBOX connected: [ 3.112348] usb 1-1: New USB device found, idVendor=1234, idProduct=5678 [ 3.112362] usb 1-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1 [ 3.112368] usb 1-1: Product: ASM1352R-Safe [ 3.112374] usb 1-1: Manufacturer: Asmedia [ 3.112379] usb 1-1: SerialNumber: 123412341249 [ 3.113303] input: Asmedia ASM1352R-Safe as /devices/platform/ff580000.usb/usb1/1-1/1-1:1.0/input/input1 Rock64#lsusb -v -t -d 1234:5678 /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usbtouchscreen, 480M As you can see Mass Storage uses Driver=usbtouchscreen and I can't change it using udev mapping ACTION=="add", ATTRS{idVendor}=="1234", ATTRS{idProduct}=="5678", RUN+="/sbin/modprobe uas" RUN+="/bin/sh -c 'echo 1234 5678 > /sys/bus/usb/drivers/uas/new_id'" After udev: rock64:~# lsusb -v -t -d 1234:5678 /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usbtouchscreen, 480M On Debian9 x86_64 and RaspberryPi 2, ICYBOX work perfectly. Any ideas why it doesn't work on Rock64?

I would also like to thank JMCC for this script. It is exactly what I need for my project. I have also been testing this script on my Rock 64, and I am not experiencing any problems with the 4k playback. Rock64, 4 GB version Clean build of armbian bionic desktop from https://www.armbian.com/rock64/ Installation of the media script (I installed everything) Installed libgstreamer1.0-dev Installed gtk 2.0 and 3.0 ( a bunch of files!), thinking I needed these for full screen video. I don't think this impacted the gst install, but I'm not sure. ran update and upgrade I can run gst-play-1.0 test.mp4 gst-launch-1.0 playbin uri=file:///home/rock64/gs/test.mp4 note the use of playbin. This was key to getting it to work - see dma error notes below I did not have to specify using rkximagesink. I am using two test files, both of them mp4 files 1920 x 1080 at 29.97 Hz, identified by ffmpeg as Video: h264 (Constrained Baseline), 23 seconds 3840 x 2160 at 29.97 Hz, identified by ffmpeg as Video: h264 (High), 2 minutes 38 seconds (yes, a >500MB file) Both videos run smoothly with no artifacts. I am not seeing any noticeable cpu heating after the 2+ minute video. (50 C before playing, 58 C after) When played on a 1080p monitor both videos play full screen when I hide the ldxe panel When played on a 4k monitor the 1080 video plays in a window the 4k video plays full screen I can also compile a simple c++ file using a playbin construct. I should note that I saw a bunch of failures trying to build the gstreamer pipeline manually, both with gst-launch-1.0 and the c++ code (it started throwing "gst_dmabuf_memory_get_fd" errors). Using playbin seems to bypass all of this. Hope this provides a clue.