Hey all! 

I have a question about the rockpro64. It has a pci-e slot which is super cool, and allows me to plug a pci-e raid controller in for a NAS. The one on the website has 2 sata ports, but I'm looking for 4 sata ports, I've read that marvell based cards work well with the rockpro64 and linux. 

The SATA power cable in the store works with two hard drives, but how would i power four 2.5" hdds? Could I just splice two of those cables together? Would I have to power them externally?

Has anyone made a 4 HDD NAS with the rockpro64? I'd love some tips.

Thanks!

More often than not, my Pinebook 11 boots to a blank screen (it turns off I believe). The green power led stays on. This happens after it shows 

Need WiFi, Bluetooth, and UARTs. Don't need GigE.
1. I looked at Google: rk3399.dtsi, and found addresses for uart0 - uart4
2. Used enable_dtoverlay to enable ports
  enable_dtoverlay uart0 'serial@ff180000' okay
  enable_dtoverlay uart1 'serial@ff190000' okay         # Disabled ethernet for this.
#enable_dtoverlay uart2 'serial@ff1a0000' okay         # Already active The only on that works,
  enable_dtoverlay uart3 'serial@ff1b0000' okay
  enable_dtoverlay uart4 'serial@ff370000' okay

Oscilloscope with the following script only show output for ttyS2. (PI bus pins 8,10)
while : ; do echo xx > /dev/ttyS0; echo xx > /dev/ttyS1; echo xx > /dev/ttyS2; echo xx > /dev/ttyS3 ;echo xx > /dev/ttyS4; echo -n . ; sleep 1; done

Looked at the Pine A64 pin assignments,
    0)  uart0  /dev/ttyS0   console
    2)  uart2   /dev/ttyS2   PI bus            pin(8) and pin(10)
    3)  uart3   /dev/ttyS3   Euler bus      pin(24) and pin(23)
    4)  uart4   /dev/ttyS4   Euler bus      pin(19) and  pin(21)
but RockPro64 has no Euler bus. Are all RockPro64 UART pins accessible?

I was using python GPIO library for ROCK64: Rock64-R64.GPIO and it didnt work, i used an offset of 1000 as is in this repository Matei Rock64-R64.GPIO  , modified the offset to be 1002 and just work for pin 16 with this script:

# Set Variables
var_gpio_out = 16


# GPIO Setup
GPIO.setwarnings(True)
GPIO.setmode(GPIO.BOARD)
GPIO.setup(var_gpio_out, GPIO.OUT, initial=GPIO.HIGH)       # Set up GPIO as an output, with an initial state of HIGH


# Test Output
print("Testing pin: " +  str(var_gpio_out))
print("Testing GPIO Input/Output:")


while True:
print("HIGH")
GPIO.output(var_gpio_out, GPIO.HIGH)
sleep(1)
print("LOW")
GPIO.output(var_gpio_out, GPIO.LOW)
sleep(1)




After that i was trying to use this commands to make work each pin, i chose numbers randomly.

firefly@firefly:~$ ls /sys/class/gpio/

export  gpiochip1000  gpiochip1032  gpiochip1064  gpiochip1096  gpiochip1510  unexport

# enter root mode
firefly@firefly:~$sudo -i
# using pin 16

root@firefly:~# sudo echo 1103 > /sys/class/gpio/export 
# set pin 16 to 0
root@firefly:~# echo 0 > /sys/class/gpio/1103/value 
root@firefly:~# echo 1 > /sys/class/gpio/1103/value 

after try and error with many numbers i found that 1103 works for pin 16 and 1101 works for pin 18, but i cant figure out the others numbers.

I suspect that this is something I need to bring to Ayufan but I am running the following kernel rockpro64 4.4.174-rockchip64

I can recreate stability issues caused by the PCIe Kernel Driver.

While it works in server mode with no desktop, it is inherently unstable while in desktop display mode and hangs the entire Board every time when booting into XOrg using this kernel. Every time I remove the PCIe I get a desktop that boots into the desktop. With other kernels I get a desktop that hangs repeatably when loading a browser that triggers the GPU to draw power.

Looking at the power Specifications for PCIe x 4 => Suggest that it can be powered from 3.3v (9.9W) & 12v (25W), however from the RockPro64 Power schema it looks like they negate to feed the 12v rail from the Supply voltage.

Instead it suggests to me Pine feeds the PCIe Interface on the board only by the 3.3v rail (9.9W).
From the Power schema It also looks like the board designers feed PCIe from the 5.1v rail converted by the RK808 PMU to 1.8v on vcc1v8_pcie (not sure how this is intended to be used on PCIe) 


I am using the Pine PCIe ver 3.0 NVMe Card with a Samsung 970 EVO 500GB and a RockPro64 v2.1 Board.  PSU is a 102W 12v LRS-100-12
The Max power draw of the EVO 970 NVMe is 5.8W which should be within spec ...

But this bit worry's me    "vcc_sys: could not add device link regulator.6 err -2"   

vcc_sys is the 3.3v rail that feeds the vcc3v3_pcie feed into the PCIe Socket.

I also see this warning;

"Apr  8 19:09:24 localhost kernel: [    2.010352] pci_bus 0000:01: busn_res: can not insert [bus 01-ff] under [bus 00-1f] (conflicts with (null) [bus 00-1f])"

Anybody else have this issue when running as desktop + PCIe NVMe ?  

When I check dmesg it looks like there is a driver issue ... 
Apr  8 19:09:24 localhost kernel: [    2.009280] PCI host bridge /pcie@f8000000 ranges:
Apr  8 19:09:24 localhost kernel: [    2.009313]   MEM 0xfa000000..0xfbdfffff -> 0xfa000000
Apr  8 19:09:24 localhost kernel: [    2.009326]    IO 0xfbe00000..0xfbefffff -> 0xfbe00000
Apr  8 19:09:24 localhost kernel: [    2.009679] rockchip-pcie f8000000.pcie: PCI host bridge to bus 0000:00
Apr  8 19:09:24 localhost kernel: [    2.009695] pci_bus 0000:00: root bus resource [bus 00-1f]
Apr  8 19:09:24 localhost kernel: [    2.009708] pci_bus 0000:00: root bus resource [mem 0xfa000000-0xfbdfffff]
Apr  8 19:09:24 localhost kernel: [    2.009721] pci_bus 0000:00: root bus resource [io  0x0000-0xfffff] (bus address [0xfbe00000-0xfbefffff])
Apr  8 19:09:24 localhost kernel: [    2.009760] pci 0000:00:00.0: [1d87:0100] type 01 class 0x060400
Apr  8 19:09:24 localhost kernel: [    2.009867] pci 0000:00:00.0: supports D1
Apr  8 19:09:24 localhost kernel: [    2.009878] pci 0000:00:00.0: PME# supported from D0 D1 D3hot
Apr  8 19:09:24 localhost kernel: [    2.010213] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
Apr  8 19:09:24 localhost kernel: [    2.010352] pci_bus 0000:01: busn_res: can not insert [bus 01-ff] under [bus 00-1f] (conflicts with (null) [bus 00-1f])
Apr  8 19:09:24 localhost kernel: [    2.010388] pci 0000:01:00.0: [144d:a808] type 00 class 0x010802
Apr  8 19:09:24 localhost kernel: [    2.010445] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x00003fff 64bit]
Apr  8 19:09:24 localhost kernel: [    2.016093] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
Apr  8 19:09:24 localhost kernel: [    2.016136] pci 0000:00:00.0: BAR 8: assigned [mem 0xfa000000-0xfa0fffff]
Apr  8 19:09:24 localhost kernel: [    2.016153] pci 0000:01:00.0: BAR 0: assigned [mem 0xfa000000-0xfa003fff 64bit]
Apr  8 19:09:24 localhost kernel: [    2.016175] pci 0000:00:00.0: PCI bridge to [bus 01]
Apr  8 19:09:24 localhost kernel: [    2.016190] pci 0000:00:00.0:   bridge window [mem 0xfa000000-0xfa0fffff]
Apr  8 19:09:24 localhost kernel: [    2.016263] pcieport 0000:00:00.0: enabling device (0000 -> 0002)
Apr  8 19:09:24 localhost kernel: [    2.016556] pcieport 0000:00:00.0: Signaling PME through PCIe PME interrupt
Apr  8 19:09:24 localhost kernel: [    2.016567] pci 0000:01:00.0: Signaling PME through PCIe PME interrupt
Apr  8 19:09:24 localhost kernel: [    2.016581] pcie_pme 0000:00:00.0:pcie01: service driver pcie_pme loaded
Apr  8 19:09:24 localhost kernel: [    2.016710] aer 0000:00:00.0:pcie02: service driver aer loaded

Apr  8 19:09:24 localhost kernel: [    1.440486] of_get_named_gpiod_flags: parsed 'rockchip,power-ctrl' property of node '/rockchip-suspend[0]' - status (0)
Apr  8 19:09:24 localhost kernel: [    1.440524] of_get_named_gpiod_flags: parsed 'rockchip,power-ctrl' property of node '/rockchip-suspend[1]' - status (0)
Apr  8 19:09:24 localhost kernel: [    1.440774] of_get_named_gpiod_flags: can't parse 'gpio' property of node '/dc-12v[0]'
Apr  8 19:09:24 localhost kernel: [    1.440795] dc_12v: 12000 mV
Apr  8 19:09:24 localhost kernel: [    1.440960] reg-fixed-voltage dc-12v: dc_12v supplying 12000000uV
Apr  8 19:09:24 localhost kernel: [    1.441128] of_get_named_gpiod_flags: parsed 'gpio' property of node '/vcc3v3-pcie-regulator[0]' - status (0)
Apr  8 19:09:24 localhost kernel: [    1.441173] reg-fixed-voltage vcc3v3-pcie-regulator: Looking up vin-supply from device tree
Apr  8 19:09:24 localhost kernel: [    1.441213] vcc3v3_pcie: supplied by dc_12v
Apr  8 19:09:24 localhost kernel: [    1.441221] dc_12v: could not add device link regulator.2 err -2
Apr  8 19:09:24 localhost kernel: [    1.441262] vcc3v3_pcie: 3300 mV
Apr  8 19:09:24 localhost kernel: [    1.441414] reg-fixed-voltage vcc3v3-pcie-regulator: vcc3v3_pcie supplying 3300000uV
Apr  8 19:09:24 localhost kernel: [    1.441466] of_get_named_gpiod_flags: can't parse 'gpio' property of node '/vcc1v8-s0[0]'
Apr  8 19:09:24 localhost kernel: [    1.441481] vcc1v8_s0: 1800 mV
Apr  8 19:09:24 localhost kernel: [    1.441637] reg-fixed-voltage vcc1v8-s0: vcc1v8_s0 supplying 1800000uV
Apr  8 19:09:24 localhost kernel: [    1.441691] of_get_named_gpiod_flags: can't parse 'gpio' property of node '/vcc-sys[0]'
Apr  8 19:09:24 localhost kernel: [    1.441711] reg-fixed-voltage vcc-sys: Looking up vin-supply from device tree
Apr  8 19:09:24 localhost kernel: [    1.441745] vcc_sys: supplied by dc_12v
Apr  8 19:09:24 localhost kernel: [    1.441753] dc_12v: could not add device link regulator.4 err -2
Apr  8 19:09:24 localhost kernel: [    1.441780] vcc_sys: 5000 mV
Apr  8 19:09:24 localhost kernel: [    1.441922] reg-fixed-voltage vcc-sys: vcc_sys supplying 5000000uV
Apr  8 19:09:24 localhost kernel: [    1.441969] of_get_named_gpiod_flags: can't parse 'gpio' property of node '/vcc-phy-regulator[0]'
Apr  8 19:09:24 localhost kernel: [    1.441984] vcc_phy: no parameters
Apr  8 19:09:24 localhost kernel: [    1.442133] reg-fixed-voltage vcc-phy-regulator: vcc_phy supplying 0uV
Apr  8 19:09:24 localhost kernel: [    1.442185] of_get_named_gpiod_flags: can't parse 'gpio' property of node '/vcc3v3-sys[0]'
Apr  8 19:09:24 localhost kernel: [    1.442204] reg-fixed-voltage vcc3v3-sys: Looking up vin-supply from device tree
Apr  8 19:09:24 localhost kernel: [    1.442239] vcc3v3_sys: supplied by vcc_sys
Apr  8 19:09:24 localhost kernel: [    1.442247] vcc_sys: could not add device link regulator.6 err -2
Apr  8 19:09:24 localhost kernel: [    1.442272] vcc3v3_sys: 3300 mV
Apr  8 19:09:24 localhost kernel: [    1.442418] reg-fixed-voltage vcc3v3-sys: vcc3v3_sys supplying 3300000uV
Apr  8 19:09:24 localhost kernel: [    1.442547] of_get_named_gpiod_flags: parsed 'gpio' property of node '/vcc5v0-host-regulator[0]' - status (0)
Apr  8 19:09:24 localhost kernel: [    1.442586] vcc5v0_host: no parameters
Apr  8 19:09:24 localhost kernel: [    1.442746] reg-fixed-voltage vcc5v0-host-regulator: vcc5v0_host supplying 0uV
Apr  8 19:09:24 localhost kernel: [    1.443353] iommu: Adding device ff8f0000.vop to group 0
Apr  8 19:09:24 localhost kernel: [    1.443432] platform ff8f0000.vop: iommu /iommu@ff8f3f00 not found
Apr  8 19:09:24 localhost kernel: [    1.443438] iommu: Removing device ff8f0000.vop from group 0
Apr  8 19:09:24 localhost kernel: [    1.443494] iommu: Adding device ff900000.vop to group 0

I read like "The ROCK64 4GB board designated as LTS (long Term Supply) model, PINE64 committed to supply at least for 5 years until year 2022 and beyond.", does it mean that Rock64 1GB or 2 GB not available for LTS?

Considering 0-70 deg C temperature range, with FCC and certificates, can we consider Rock64 4G LTS for product development instead of using them as hobby board? We want to roll out few industrial data acquisition products, which works with PLC within factories, mostly 20 to 60 Deg Range. I understand that there are various OS issues reported by community, but our use is not media playback, considering USB, Ethernet and UARTS working, we are more than happy.

Hello all,

So I’m wanting to venture down the rock64 path after having it suggested by multiple people. 

Currently I am trying to run libreelec with OpenVPN and transmission from a Pi 3/3B+ and it’s been a real pain. Between the insane bottlenecks with transfers over 8MB/s via transmission to hangs when streaming from USB it’s just been an insanely frustration. 

I am hoping to retire my DNS-320L which current contains 2 drives, a 2TB and 3TB WD NAS drive, so I was planning on purchasing the board, the NAS enclosure, the SATA cable and the 12V power brick because better safe than sorry. 

I presume the fan in the store would be a wise purchase?

Is there anything else I might need? I don’t care about booting from eMMC as I don’t see a benefit over a good 128gb SDHC card I currently am repurposing from my switch, had to upgrade. 

Also, my other concern was the shipping time and method to Canada. I see that most shipments come via DHL but I’ve had issues in the past getting hit with duties and taxes for large shipments. Looking arbitrary the total I fear I may push over $25, but looking st the Canadian store, the Rockpro64 is $140CDN(!!!) so even if I was hit, the savings would be massive. 

Lastly, what’s the deal on shipping speed/times? I see more stock is expected on the 12th, should I assume a 30ish day turnaround considering its coming from China?

I’m a bit wary as it’s a good amount of money and unlike buying from amazon I don’t expect to have flexible returns, so I need to know for sure this will work. 

My expectation would be to copy my Pi 3 setup here, loading Libreelec and running OpenVPN with transmission, but I do not know if the plugins will work seamlessly on the hardware. 

Thanks in advance!

Running Ubuntu 18.04.2 LTS (GNU/Linux 4.4.132-1075-rockchip-ayufan-ga83beded8524 aarch64) and did a run of the https://bench.sh. 
With only the eMMC (no sd) I get really slow I/O speeds:


I/O speed(1st run)   : 93.5 MB/s
I/O speed(2nd run)   : 94.6 MB/s
I/O speed(3rd run)   : 91.8 MB/s
Average I/O speed    : 93.3 MB/s


Is this normal?

Does anyone have any information regarding where I can find a good, understandable tutorial on how to use the "dd" command for transferring a file to an SD card? To eMMC bulk storage, if that's possible?

There are plenty of good "type this in" code examples** in these forums; what I'd like to see somewhere--anywhere--is a "dd For Dummies" kind of tutorial (I know how to check the 'dd' man page--absolutely NOT what I'm asking for).

Thanks, in advance, to anyone who knows of a good, understandable-by-anyone source (again: anywhere) of "dd"-use information.


**There are also several examples of users' failures, because they didn't / don't have access to the type of tutorial I'm asking about. Again: many thanks.

Are the (4) groups of GPIOs A, B, C, D in the same 32-bit register?
Example:
GPIO1
3
1 0
[----D----][----C----][----B----][----A----]
7 4 1
I can toggle GPIO1A1, 4, 7 on/off but not GPIO1Bs.

TIA,
/Faradn

...Any way to set a fixed width font in this BBS?