Difference between revisions of "ROCKPro64"

From PINE64
Jump to navigation Jump to search
(→‎Enabling PCIe 2.0: Added a warning)
(→‎Hardware "Hacking": Fits better as a separate article, moved to ROCKPro64 Hardware Tweaks)
Line 715: Line 715:


Then, reboot.
Then, reboot.
== Hardware "Hacking" ==
=== Enabling PCIe 2.0 ===
{{Warning|The downgrade to Gen1 speed came [[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=712fa1777207 straight from Rockchip]], as a result of an undisclosed RK3399 hardware errata.  Thus, enabling Gen2 back may cause instability issues or data corruption under certain circumstances.  Also, the limitations of the RK3399's internal interconnects prevent the enabling of Gen2 speed from producing some measurable performance gains.}}
By default, the RockPro64 runs the PCIe slot at gen 1 speeds because there might be stability issues with gen 2 speeds. The port can be switched back to gen 2 speeds by adding the following device tree overlay.
1. Copy and paste the device tree overlay file below into a new file (you could name it <code>pcie-2.0.dts</code>):
// Pulled from: https://forum.armbian.com/topic/23574-howto-enable-pcie-gen2-to-get-max-speed-of-nvme-rockpi-4b/
/dts-v1/;
/plugin/;
&pcie0 {
        max-link-speed = <0x03>;
};
2. Compile the device tree into a binary file. Note that you will need <code>dtc</code> installed.
dtc -I dts -O dtb -@ pcie-2.0.dts -o pcie-2.0.dto
4. Copy or move the device tree from the current directory into the boot partition (in this case into the <code>/boot/dtbs/overlay/</code> folder). If you haven't yet created the <code>/boot/dtbs/overlay/</code> folder, then create it with <code>sudo mkdir /boot/dtbs/overlay/</code>
sudo cp pcie-2.0.dto /boot/dtbs/overlay/
5. Add the device compiled tree overlay file to the list of files u-boot needs to load. If you are using ManjaroARM (or ArchLinuxARM with a <code>extlinux.conf</code> file), then add the following line to the file <code>/boot/extlinux/extlinux.conf</code>:
FDTOVERLAYS /dtbs/overlay/pcie-2.0.dtb
If you already have an <code>FDTOVERLAYS</code> line, then add a space at the end of the current line, then add this overlay file after that.
See here for details on this process: [[ROCKPro64 Device Tree Overlays on Mainline]]
The resulting <code>/boot/extlinux/extlinux.conf</code> file might look like below after adding this dtb file:
LABEL Manjaro ARM
KERNEL /Image
FDT /dtbs/rockchip/rk3399-rockpro64.dtb
FDTOVERLAYS /dtbs/overlay/pcie-2.0.dtb /dtbs/overlay/cpu-overclock.dtb
APPEND initrd=/initramfs-linux.img console=ttyS2,1500000 zfs=zroot rw rootwait audit=0 cpufreq.default_governor=schedutil
=== Overclocking (and undervolting) ===
The RK3399 can be overclocked. See here for details: [[Overclocking#RK3399-based devices]].
By overclocking, you do risk damaging your hardware, however, it is possible to achieve small, but measurable improvements in performance with an overclock. The overclock can be applied with a device tree overlay file.
Below is an example device tree overlay for CPU overclocking on the RockPro64. It may or may not work well on your device, but some have found that these speeds are stable.
The example below bumps the little cores up to 1.608GHz from 1.416GHz and bumps the big cores up to 2.088GHz from 1.8GHz.
1. Copy and paste the device tree overlay file below into a new file (you could name it <code>cpu-overclock.dts</code>):
// Pulled from: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi
/dts-v1/;
/plugin/;
        &cluster0_opp {
                opp00 {
                        opp-hz = /bits/ 64 <408000000>;
                        opp-microvolt = <800000>;
                        clock-latency-ns = <40000>;
                };
                opp01 {
                        opp-hz = /bits/ 64 <600000000>;
                        opp-microvolt = <825000>;
                };
                opp02 {
                        opp-hz = /bits/ 64 <816000000>;
                        opp-microvolt = <850000>;
                };
                opp03 {
                        opp-hz = /bits/ 64 <1008000000>;
                        opp-microvolt = <900000>;
                };
                opp04 {
                        opp-hz = /bits/ 64 <1200000000>;
                        opp-microvolt = <975000>;
                };
                opp05 {
                        opp-hz = /bits/ 64 <1416000000>;
                        opp-microvolt = <1100000>;
                };
                opp06 {
                        opp-hz = /bits/ 64 <1512000000>;
                        opp-microvolt = <1150000>;
                };
                opp07 {
                        opp-hz = /bits/ 64 <1608000000>;
                        opp-microvolt = <1200000>;
                };
        };
        &cluster1_opp {
                opp00 {
                        opp-hz = /bits/ 64 <408000000>;
                        opp-microvolt = <800000>;
                        clock-latency-ns = <40000>;
                };
                opp01 {
                        opp-hz = /bits/ 64 <600000000>;
                        opp-microvolt = <800000>;
                };
                opp02 {
                        opp-hz = /bits/ 64 <816000000>;
                        opp-microvolt = <825000>;
                };
                opp03 {
                        opp-hz = /bits/ 64 <1008000000>;
                        opp-microvolt = <850000>;
                };
                opp04 {
                        opp-hz = /bits/ 64 <1200000000>;
                        opp-microvolt = <900000>;
                };
                opp05 {
                        opp-hz = /bits/ 64 <1416000000>;
                        opp-microvolt = <975000>;
                };
                opp06 {
                        opp-hz = /bits/ 64 <1608000000>;
                        opp-microvolt = <1050000>;
                };
                opp07 {
                        opp-hz = /bits/ 64 <1800000000>;
                        opp-microvolt = <1150000>;
                };
                opp08 {
                        opp-hz = /bits/ 64 <2016000000>;
                        opp-microvolt = <1250000>;
                };
                opp09 {
                        opp-hz = /bits/ 64 <2088000000>;
                        opp-microvolt = <1250000>;
                };
        };
2. Compile the device tree into a binary file. Note that you will need <code>dtc</code> installed.
dtc -I dts -O dtb -@ cpu-overclock.dts -o cpu-overclock.dto
4. Copy or move the device tree from the current directory into the boot partition (in this case into the <code>/boot/dtbs/overlay/</code> folder). If you haven't yet created the <code>/boot/dtbs/overlay/</code> folder, then create it with <code>sudo mkdir /boot/dtbs/overlay/</code>
sudo cp cpu-overclock.dto /boot/dtbs/overlay/
5. Add the device compiled tree overlay file to the list of files u-boot needs to load. If you are using ManjaroARM (or ArchLinuxARM with a <code>extlinux.conf</code> file), then add the following line to the file <code>/boot/extlinux/extlinux.conf</code>:
FDTOVERLAYS /dtbs/overlay/cpu-overclock.dtb
If you already have an <code>FDTOVERLAYS</code> line, then add a space at the end of the current line, then add this overlay file after that.
See here for details on this process: [[ROCKPro64 Device Tree Overlays on Mainline]]
The resulting <code>/boot/extlinux/extlinux.conf</code> file might look like below after adding this dtb file:
LABEL Manjaro ARM
KERNEL /Image
FDT /dtbs/rockchip/rk3399-rockpro64.dtb
FDTOVERLAYS /dtbs/overlay/pcie-2.0.dtb /dtbs/overlay/cpu-overclock.dtb
APPEND initrd=/initramfs-linux.img console=ttyS2,1500000 zfs=zroot rw rootwait audit=0 cpufreq.default_governor=schedutil
=== Getting wifi working ("new" wifi module) ===
ManjaroARM and ArchLinuxARM (and probably others) provide the NVRAM file needed to initialize the Wi-Fi module in the linux-firmware package, but it is listed under the generic name <code>brcmfmac43455-sdio.AW-CM256SM.txt</code>.
You can copy this file to the new name (that the driver looks for) with the following commands:
cd /usr/lib/firmware/brcm/
sudo cp brcmfmac43455-sdio.AW-CM256SM.txt brcmfmac43455-sdio.txt
Then, reboot and Wi-Fi should start working.
Details for this method are here: https://forum.pine64.org/showthread.php?tid=16635&pid=117061#pid117061
However, on a 5GHz network with <code>wireless-regdb</code> installed and the regulatory domain set to 'US', the adapter is almost unusable. Speeds are usually 0 bits per second. Sometimes a few packets can get through every few seconds, but that is it. On a 2.4GHz network, this is not an issue. This "can" be resolved by setting the regulator domain to 'GB' or 'CN', but this isn't a solution for you if you are in the USA, for instance. There are various other <code>brcmfmac43455-sdio.txt</code> files online that one can try. Some work better than others. Since these are text files where each line represents a property value, one can combine parts of these files to generate new firmware files for testing. One such combination yields decent results. This can be achieved by applying the patch below to the default <code>brcmfmac43455-sdio.AW-CM256SM.txt</code> file. With this firmware file, it is possible to get about 140Mbps up and down with this patch (with the regulatory domain set to 'US').
--- brcmfmac43455-sdio.AW-CM256SM.txt  2023-04-27 19:16:47.000000000 -0500
+++ brcmfmac43455-sdio.txt      2023-05-21 11:42:22.058517093 -0500
@@ -21,19 +21,18 @@
  ltecxpadnum=0x0504
  macaddr=00:90:4c:c5:12:38
  manfid=0x2d0
-maxp2ga0=64
-maxp5ga0=80,82,76,77
-mcsbw202gpo=0x99355533
-mcsbw205ghpo=0x99855000
-mcsbw205glpo=0x99755000
-mcsbw205gmpo=0x9df55000
-mcsbw405ghpo=0xd9755000
-mcsbw405glpo=0xb8555000
-mcsbw405gmpo=0xed955000
-mcsbw805ghpo=0xd9555000
-mcsbw805glpo=0xc8555000
-mcsbw805gmpo=0xe9555000
-muxenab=0x10
+maxp2ga0=70
+maxp5ga0=73,74,73,73
+mcsbw202gpo=0x99333322
+mcsbw205ghpo=0x8a875444
+mcsbw205glpo=0x8a875444
+mcsbw205gmpo=0x8a875444
+mcsbw405ghpo=0xda844333
+mcsbw405glpo=0xda844333
+mcsbw405gmpo=0xdb844333
+mcsbw805ghpo=0xda555444
+mcsbw805glpo=0xdb555444
+mcsbw805gmpo=0xda555444
  nocrc=1
  ofdmlrbw202gpo=0x0033
  pa2ga0=-112,6296,-662
To use this patch, copy it off into a file and use the <code>patch</code> command.
However, it might be easier to apply the patch by hand.
To do this, open the file <code>/usr/lib/firmware/brcm/brcmfmac43455-sdio.txt</code> (after completing the copy step above),  delete the line with <code>maxp2ga0=64</code> through the line with <code>muxenab=0x10</code>.
Then add the following in its place:
maxp2ga0=70
maxp5ga0=73,74,73,73
mcsbw202gpo=0x99333322
mcsbw205ghpo=0x8a875444
mcsbw205glpo=0x8a875444
mcsbw205gmpo=0x8a875444
mcsbw405ghpo=0xda844333
mcsbw405glpo=0xda844333
mcsbw405gmpo=0xdb844333
mcsbw805ghpo=0xda555444
mcsbw805glpo=0xdb555444
mcsbw805gmpo=0xda555444
Reboot and the Wi-Fi (at least for 5GHz networks) should work well. It is not exactly clear what these fields do, so the impact this has on the Wi-Fi module or your ability to operate it legally in your country is not certain. It seems that this file is passed directly to the hardware, where it is interpreted by the Wi-Fi module itself. However, given that this file is simply a combination of other existing files for similar hardware, it might be fine to use.
The patch above only pulls in lines from the following firmware file: https://github.com/reMarkable/brcmfmac-firmware/blob/master/brcmfmac43455-sdio.txt.
This code comes with the following license - which is not replicated here because it will fill this wiki with text - see the link here for the license: https://github.com/reMarkable/brcmfmac-firmware/blob/master/LICENCE.
=== Stabilizing the system (underclocking the RAM) ===
{{Warning|As pointed out by CrystalGamma, "normal accesses should simply work, though with higher access latency than necessary (since it uses the same number of cycles as would be necessary for a higher frequency), but I'd be slightly worried about refresh, since it also issues refresh based on number of cycles as would be used for a higher frequency, instead of actual time elapsed".  In other words, "the risk is refreshes coming to late, though it's probably within tolerance with this little of a frequency diff".}}
By default, it seems that the some RockPro64 devices are not stable. This seems to manifest as gcc segfaulting randomly. Usually, this can be "fixed" by starting the build again and hoping gcc doesn't crash. If the build finishes or crashes at a different point, this is a good indicator that the system is not stable. The issue seems to be that the RAM is running a little too fast and some bits are getting randomly flipped. Other frequencies are possible, but the highest officially supported frequency below 800MHz is 666MHz, which is still a big step down from the default frequency of 800MHz provided by ManjaroARM. It is also possible to set arbitrary frequencies in u-boot. Frequencies that have been tested with this method are 702MHz and 752MHz. It seems that there is only a slight performance decrease at 752MHz compared to 800MHz. The PKGBUILD for this is available here: https://aur.archlinux.org/packages/uboot-rockpro64-foss
By default, this PKGBUILD uses the default RAM speed of 800MHz. Uncomment the line that begins with "patch" to enable the 752MHz patch. Details are in the comments at the top of the PKGBUILD.
If you would like to try out other frequencies, follow the instructions in the comments at the top of the PKGBUILD.
After building and installing, the install hook will prompt you on if you want to install the new build of U-Boot to EMMC. If you want to, press Y, otherwise, hit N and then copy and paste the printed <code>dd</code> commands and modify them to write to the correct device (change the <code>/dev/mmcblk</code> part).
After installing U-Boot and rebooting, U-Boot should print out that it set the RAM to 400MHz (initially). Then a few lines down, the RAM should be set to 752MHz.


[[Category:ROCKPro64]]
[[Category:ROCKPro64]]
[[Category:Rockchip RK3399]]
[[Category:Rockchip RK3399]]

Revision as of 18:52, 23 October 2023

The ROCKPro64

The ROCKPro64 is the most powerful Single Board Computer released by PINE64. It is powered by a Rockchip RK3399 Hexa-Core (dual ARM Cortex A72 and quad ARM Cortex A53) 64-Bit Processor with a Mali T-860 Quad-Core GPU. The key features include a PCIe x4 open ended slot, the use of LPDDR4 RAM, and industry standard heatsink mounting holes.

The ROCKPro64 is equipped with 2GB or 4GB LPDDR4 system memory, and 128Mb SPI boot Flash. There is also an optional eMMC module (up to 128GB) and microSD slot for booting. The board is equipped with 1x USB 3.0 type C Host with DP 1.2, 1x USB 3.0 type A Host, 2x USB 2.0 Host, Gigabit Ethernet, PI-2 GPIO Bus, MiPi DSI interface, eDP interface, touch Panel interface, stereo MiPi CSI interface, as well as many other device interfaces such as UART, SPI, I2C, for makers to integrate with sensors and other peripherals. Many different Operating Systems (OS) are freely available from the open source community, such as Android, Linux (Ubuntu, Debian, Arch), and BSD.

Getting Started

The article ROCKPro64 Getting Started gives important information to get the board up and running.

Software releases

In the ROCKPro64 Software Releases page, you will find a complete list of currently supported Operating System images that work with the ROCKPro64, as well as other related software. The Software Release page has links to download the images as well as high level instructions to load each image.

Please see the Getting started page for detailed discussion of what you need (prerequisites) as well as instructions if the high level instructions are insufficient.

Board Layout

A hi-res picture of v2.1 rear.
A thermal image of v2.1 front (upside-down).


An annotated ROCKPro64

Main Chips

  • RK3399 system-on-chip (1)
  • LPDDR4 SDRAM 1 (18)
  • LPDDR4 SDRAM 2 (3)
  • SPI NOR flash memory (17)
  • RK808 power management (near 19)
  • RTL8211 ethernet transceiver (near 25)
  • ES8316 Sound Codec (on rear of board)
  • The heatsink mounting holes around the RK3399 are 59 mm apart

Switches

The Power button (11, SW3): is the same as on your mobile phone - press and release after about 1 second to power on. Press and hold for about 3 seconds to power off.

The Reset button (10, SW901): performs a reset.

The Recover button (28, SW900): used to enter maskrom mode.

Connectors, Sockets and Headers

Diagram Schematic
designator		 Silkscreen
label		 Number
of pins		 Description
2 U39 PI-2-bus 40 Pi-2 bus
4 J8 +FAN- 2 PWM controlled fan header
5 J10 SPDIF 3 SPDIF header
6 U6 +RTC- 2 RTC battery backup header
7 U31 Wifi-BT 16 SDIO WIFI/BT module-MIMO 2
8 USB3 9 USB-3 and USB Type C
9 USB1 2×4 Dual USB-2
12 IR1 IR 3 infrared receiver socket
13 J16 Headphone+mic 4 Headphone + mic 3.5mm jack
- CON16 GND PWR RST GND 4 Power & reset, unpopulated
header near Headphone jack
14 U29 EMMC 34 eMMC connector
14* J13 13 TF-card, a.k.a. microSD
(* under 14 on the bottom side)
15 U30 14 SDIO WIFI/BT module-MIMO 1
16 SW4 2 Jumper to #Disable eMMC
19 J15 PCI 64 PCI-express X4 socket
20 J21 DSI 30 DSI
21 J22 EDP 30 LCD EDP
22 CON1 TP 6 touch panel connector
23 CON15 4 DC out for SATA disk cable
(direct connect from DC-IN)
24 J11 DC-IN 2 Power input, positive tip;
12V/3A (minimum) recommended
25 U32 8 8P8C (often referred to as 'RJ45')
26 J14 19 HDMI
27 J17 MIPI CAM 32 MIPI-1
29 J19 MIPI CAM 32 MIPI-2
30 J18 CIF 26 CIF

LEDs

A green LED next to the 12V input barrel connector will light as long as there is 12V applied to the connector. (Even if the RockPro64 is powered off.)

A white LED behind the reset button will light as long as the RockPro64 is running (it comes on a few seconds after power on, when control is passed to the operating system.)

A red LED behind the reset button is DIY - it is lit for example if the board is in OTG mode with an Ayufan image, or if an Android image is in standby mode.

Yellow and green LEDs on the LAN socket behave in a standard way.

Jumpers

They are used for boot device selection, as described in the following section.

Disable eMMC

There is an unlabelled (on the PCB silk-screen) 2-pin jumper (16) between the eMMC socket (14) and the SPI chip (17). It is designated as SW4 on the schematic diagram. The default condition is OPEN (no jumper). It is useful for controlling the boot as follows:

Default boot device (with no SPI software) is eMMC, then SDcard. If both the eMMC and the SDcard contain bootable images then the eMMC can be disabled by installing the jumper. This completely removes the eMMC from the resulting OS. If you wish the eMMC to be visible in the booted OS the jumper should be removed 2 seconds after applying power (and before the white LED comes on).

The possible combinations are summarised in the table below.

  • 1 = present
  • 0 = not present
µSD eMMC SW4 boot from
0 0 0 unsupported
0 0 1 unsupported
0 1 0 eMMC
0 1 1 unsupported
1 0 0 SDCard
1 0 1 SDCard
1 1 0 eMMC
1 1 1 SDCard

Disable SPI (while booting)

There is a second possibility to jumper your ROCKPro64: If you mess-up your SPI and are unable to boot, jumpering pins 23 (CLK) and 25 pin (GND) on the PI-2-bus header will disable the SPI as a boot device. (This was taken from the IRC logs, 09 August 2018 @ 17:23) You have to remove the jumper 2 seconds after having started your RP64 (before the white LED turns ON) otherwise the SPI will be missing and you won't be able to flash it. Ayufan images contain (at the moment) only one script for the SPI and the RP64, it's "rockpro64_reset_spi_flash". Other SPI scripts are dedicated to the R64 (as it is written on the name) and it will mess-up your RP64 SPI if you use them.

Hardware Compatibility

The hardware compatibility list can be found under ROCKPro64 Hardware compatibility.

Board Features

This section outlines the most important characteristics of the board and its components.

SoC and Memory Specification

  • Based on Rockchip RK3399
Rockchip RK3399.png

CPU Architecture

  • Dual-core Cortex-A72 up to 2.0GHz CPU
  • Quad-core Cortex-A53 up to 1.5GHz CPU
  • big.LITTLE architecture: Dual Cortex-A72 + Quad Cortex-A53, 64-bit CPU
  • Cortex-A72:
    • 1-4x Symmetrical Multiprocessing (SMP) within a single processor cluster, and multiple coherent SMP processor clusters through AMBA 5 CHI or AMBA 4 ACE technology
    • AArch64 for 64-bit support and new architectural features
    • L1 cache 48KB Icache and 32KB Dcache for each A72
    • L2 cache 1024KB for big cluster
    • DSP & SIMD extensions
    • VFPv4 floating point
    • Hardware virtualization support
  • Cortex-A53:
    • L1 cache 32KB Icache and 32KB Dcache for each A53
    • L2 cache 512KB for little cluster
  • Full implementation of the ARM architecture v8-A instruction set
  • ARM Neon Advanced SIMD (single instruction, multiple data) support for accelerated media and signal processing computation
  • ARMv8 Cryptography Extensions
  • In-order pipeline with symmetric dual-issue of most instructions
  • Include VFP v3 hardware to support single and double-precision operations
  • TrustZone technology support
  • Full CoreSight debug solution
  • One isolated voltage domain to support DVFS

GPU Architecture

  • ARM Mali-T860MP4 Quad-core GPU
  • The highest performance GPUs built on Arm Mali’s famous Midgard architecture, the Mali-T860 GPU is designed for complex graphics use cases and provides stunning visuals for UHD content.
  • Frequency: 650MHz
  • Throughput: 1300Mtri/s, 10.4Gpix/s
  • OpenGL® ES 1.1, 1.2, 2.0, 3.1, 3.2, Vulkan 1.0*, OpenCL™ 1.1, 1.2, DirectX® 11 FL11_1, RenderScript™.

System Memory

  • LPDDR4 RAM Memory Variants: Dual Channels 2GB and 4GB.
  • Storage Memory: 128Mb built-in SPI Flash memory (as at August 2018 only support for USB boot).

Display

  • Dual VOP: one supports resolutions up to 4096x2160 and AFBC; the other supports resolutions up to 2560x1600
  • Dual channel MIPI-DSI (4 lanes per channel)
  • eDP 1.3 (4 lanes with 10.8Gbps) to support displays, with PSR
  • Digital Video port up to 4Kp60
  • DisplayPort 1.2 (4 lanes, up to 4K 60Hz)
  • Supports Rec.2020 and conversion to Rec.709

Video

  • Digital Video output up to 4K@60Hz
  • 4K HDR @ 30fps
  • H.264/AVC Base/Main/High/High10 profile @ level 5.1; up to 4Kx2K @ 60fps
  • H.265/HEVC Main/Main10 profile @ level 5.1 High-tier; up to 4Kx2K @ 60fps
  • VP9, up to 4Kx2K @ 60fps
  • MPEG-1, ISO/IEC 11172-2, up to 1080P @ 60fps
  • MPEG-2, ISO/IEC 13818-2, SP@ML, MP@HL, up to 1080P @ 60fps
  • MPEG-4, ISO/IEC 14496-2, SP@L0-3, ASP@L0-5, up to 1080P @ 60fps
  • VC-1, SP@ML, MP@HL, AP@L0-3, up to 1080P @ 60fps
  • MVC is supported based on H.264 or H.265, up to 1080P @ 60fps

Audio

  • 3.5mm Phone Jack
  • 3-pin S/PDIF header
  • Audio via Digital Video port

Camera

  • Dual MIPI CSI，dual ISP, maximum input resolution of 13M pixels

Network

  • 10/100/1000Mbps Ethernet - Capable of pushing 941 MBit/s in iperf3
  • Wi-Fi 802.11 ac/a/b/g/n with Bluetooth 4.01 (old version with 2x2) / Bluetooth 5 (new version with 1x1) (optional)

Storage

  • microSD - bootable, support SDHC and SDXC, storage up to 256GB
  • eMMC - bootable (optional eMMC Module)
  • 1 USB3.0 Host port
  • 1 USB type C OTG port with DP output
  • 2 USB2.0 Dedicated Host ports

Expansion Ports

  • 2x20 pins "Pi2" GPIO Header
  • PCIe 2.1 (4 full-duplex lanes with 20Gbps) x4 open ended port

GPIO Pins

Assigned To Pin Nr. Pin Nr. Assigned To
3.3 V 1 2 5 V
GPIO1_C4 (I2C8_SDA) a 3 4 5 V
GPIO1_C5 (I2C8_SCL) a 5 6 GND
GPIO4_D0 (CPU_GPCLK) 7 8 GPIO4_C4 (UART2_TX)
GND 9 10 GPIO4_C3 (UART2_RX)
GPIO1_C6 11 12 GPIO3_D0 (I2S0_CLK)
GPIO1_C2 13 14 GND
GPIO1_A1 15 16 GPIO1_A4
3.3 V 17 18 GPIO4_C5 [SPDIF]
[UART4_TX] GPIO1_B0 (SPI1_TXD) 19 20 GND
[UART4_RX] GPIO1_A7 (SPI1_RXD) 21 22 GPIO4_D1
GPIO1_B1 (SPI1_CLK) 23 24 GPIO1_B2 (SPI1_CSN0)
GND 25 26 GPIO1_B5
GPIO1_B3 (I2C4_SDA) 27 28 GPIO1_B4 (I2C4_SCL)
GPIO4_D3 29 30 GND
GPIO4_D4 31 32 GPIO3_D4 (I2S0_SDI1SDO3)
GPIO3_D5 (I2S0_SDI2SDO2) 33 34 GND
GPIO3_D2 (I2S0_LRCKTX) 35 36 GPIO3_D6 (I2S0_SDI3SDO1)
GPIO3_D1 (I2S0_LRCKRX) 37 38 GPIO3_D3 (I2S0_SDI0)
GND 39 40 GPIO3_D7 (I2S0_SDO0)
Notes
  • a: pulled high to 3.3V through 2.2kOhm resistor
Linux /dev/gpiochip Assignments
Pin Nr. 3 5 7 8 10 11 12 13 15 16 18 19 21 22 23 24 26 27 28 29 31 32 33 35 36 37 38 40
Chip 1 1 4 4 4 1 3 1 1 1 4 1 1 4 1 1 1 1 1 4 4 3 3 3 3 3 3 3
Line 20 21 24 20 19 22 24 18 1 4 21 8 7 25 9 10 13 11 12 27 28 28 29 26 30 25 27 31

On Linux, using the new /dev/gpiochip API, the n in GPIOn_XX appears to correlate to the number of the /dev/gpiochipn, and the XX to the definition RK_PXX of lines in include/dt-bindings/pinctrl/rockchip.h of the Linux kernel source. Having these named in the dts would be nice.

You can use libgpiod to drive them, and test them with the included tools (gpioinfo, gpioset, ...)

For example, gpioset 4 25=1 (run as root) would turn pin 22 on. Do beware that poking the wrong GPIO pin can lock up your system.

The conversion table at right is also available as a C header file.

Working Features

Feature/Option Android Android Version Linux Linux Version Test/Verify Steps Notes Product Link
PINE64 LCD Touchscreen (Screen/Touch) Yes/Yes No/No Maybe this will help get this working? 7″ LCD Touch Screen Panel
Wireless

ROCKPro64 2×2 MIMO Dual Band WiFi 802.11AC / Bluetooth 4.2 Module (old) ROCKPro64 1x1 Dual Band WiFi 802.11AC / Bluetooth 5.0 Module (new)

Yes/Yes No/Yes* For the "new" ROCKPro64 WIFI module: Verified with Manjaro ARM (kernel 6.2.5). A config file ("firmware file") is needed at /lib/firmware/brcm/brcmfmac43455-sdio.txt. See #Getting wifi working ("new" wifi module) for the file contents and details. In 0.7.9 Ayufan linux releases this is deliberately disabled for stability reasons. On Manjaro ARM (kernel 6.2.5), WIFI seems to be stable with the firmware file. On a 5GHz network (802.11AC), it is possible to get about 120Mbps using the "new" ROCKPro64 WIFI module. ROCKPro64 1x1 Dual Band WiFi 802.11AC / Bluetooth 5.0 Module
USB OTG use this script: rockpro64_enable_otg.sh, then configure ip on usb0: ifconfig usb0 169.169.222.222 and run iperf, you should likely see about 200-300MB/s ROCKPro64#OTG_mode
USB Mass Storage USB2/USB3 Yes/yes Yes/Yes
Dedicated Fan Power (pwm1) Yes You might want to use ATS.
GPIO pins (raw or via RPI python scripts) Check out what Frank Mankel has done.
MIPI CSI Camera 1 and 2
eDP
HDMI Audio Yes 7.1.2 Yes 4.4.132-1083 - 4.4.138-1100 Stopped working in 4.4.154.1105. Ayufan is looking into it. This is working in Manjaro ARM (kernel 6.2.5). Select the Analog Output (Built-in Audio Stereo) option in the audio output device selection window (either use pavucontrol or the volume button in the KDE desktop). Despite the slightly misleading name, audio does go through the HDMI port. See here for details: https://forum.manjaro.org/t/no-hdmi-audio-on-rockpro64/25595/2.
3.5mm Audio/Mic
USB-C Host
Display via USB-C Yes 7.x and 8.x eDP via USB-C per tillim. No sound on Android 7.x. Sound does work on Android 8.x
ROCKPro64 PLAYBOX ENCLOSURE N/A N/A N/A Ventilation does not exist, thus requires manual changes to add venting. Case should be modified to account power adapter not being centered in cut holes. Opening the case once close without modifying it first is near impossible without special tools. Graphene heatsink is included and does well for Linux but not Android. https://pine64.com/?product=rockpro64-playbox-enclosure
ROCKPro64 30mm Tall Profile Heatsink N/A N/A N/A https://store.pine64.org/?product=rockpro64-heatsink
ROCKPro64 20mm Mid Profile Heatsink N/A N/A N/A https://pine64.com/?product=rockpro64-20mm-mid-profile-heatsink
Fan For ROCKPro64 20mm Mid Profile Heatsink N/A N/A N/A You might want to use fanctl to control the fan while keeping your CPU cool https://pine64.com/?product=fan-for-rockpro64-20mm-mid-profile-heatsink
HDMI output 4K@60Hz
PCIe 2.1
Real Time Clock (RTC) battery backup https://store.pine64.org/?product=rtc-backup-battery-cr-battery
Boot from USB/PXE

RockChip themselves have tables of supported features at 4.4 and mainline kernel versions in their wiki here.

Board Information, Schematics and Certifications

Certifications:

  • Disclaimer: Please note that PINE64 SBC is not a "final" product and in general certification is not necessary. However, PINE64 still submit the SBC for FCC, CE, and ROHS certification and obtain the certificates to proof that SBC board is capable on passing the testing. Please note a final commercial product needs to performs its owns testing and obtains its owns certificates.
  • ROCKPro64 FCC Certificate
  • ROCKPro64 CE Certificate
  • ROCKPro64 RoHS Report

Datasheets for Components and Peripherals

Rockchip RK3399 SoC information:

LPDDR4 (200 Balls) SDRAM:

eMMC information:

SPI NOR Flash information:

Heatsink related info:

Wireless related info:

Ethernet related info:

Peripheral related info:

Remote control button mapping:

Audio Codec (ES8316) (under board):

PWM controlled fan, SPDIF, and RTC Battery Backup headers:

Useful Articles and Blog Posts

If you want to dive in to the ecosystem, here's a short list of various articles and blog posts that can help you set up your soft- or hardware development environment.

The NAS Case for the ROCKPro64

Front View of the PINE64 NAS Case for the ROCKPro64

Please follow this this link for detailed instructions on how to assemble the ROCKPro64 NAS Case.

The NAS Case instructions also contains detailed information about:

  • what the NAS Case ships with
  • What additional things you need to purchase for your NAS Case
  • What optional things you can consider purchasing for your NAS build
  • What OS Image we recommend you use for your NAS build
  • IO accessibility after installing the ROCKPro64 into the NAS Case
  • NAS Case Exploded View
  • NAS Case Drawing

3D printable ITX mounting brackets

A Quartz64-A mounted in an ITX case using 3D printed brackets

Allows mounting a ROCKPro64-A or Quartz64-A board inside a regular PC case that conforms to the ITX standard, using 3D printed brackets:

  • AMF/STL/STEP files plus the original FreeCAD file used to create the models File:RP64-A Q64-A to ITX mounting brackets.zip
  • Make sure to flip the two brackets by 180 degrees on one of the horizontal axes (X/Y) in your slicer of choice before printing to avoid unnecessary supports
  • To allow enough clearance between the board and the bracket you either need to print four copies of the washer model or add nut(s) between the board and the bracket
  • If using nuts for the clearance between the board and the brackets, make sure it creates at least 3.2mm of spacing in between
  • Depending on the accuracy and calibration of a 3D printer, slight deviation can occur and you likely need to manually widen some of the holes to allow screws to fit

Other Resources

Troubleshooting

No Video or GPU Acceleration on Debian

If you can log in through serial but don't get any video or GPU acceleration on Debian, this is likely due to Debian's decision to compile the devfreq governors as loadable modules but not including them early enough for panfrost to be able to be provided with one of them.

The usual sign of this being the case is the following line in your log: [drm:panfrost_devfreq_init [panfrost]] *ERROR* Couldn't initialize GPU devfreq

Log in to your ROCKPro64, and run the following: 

sudo -i
echo governor_simpleondemand >> /etc/initramfs-tools/modules && update-initramfs -u -k $(uname -r)
exit

Then, reboot.

Retrieved from "https://wiki.pine64.org/index.php?title=ROCKPro64&oldid=21004"