Several Rockchip RK3399 boards have been announced in the last few days, first with AAEON RICO-3399 Pico-ITX single board computer targeting mostly business customers for digital signage, kiosk or, automation and Orange Pi RK3399, a featured-pack board with plenty of interfaces to play with.
However those boards, and the one released previously, tend to cost between $100 and $200 or over, and even though we saw Rockchip SAPPHIRE evaluation board going for $75 its was a time-limited promotion, and the normal price is around $150. I’m pleased to report Pine64 will soon launch RockPro64 boards powered by Rockchip RK3399 or the recently announced RK3399Pro with an NPU for around $60 and up.
There will be three versions of the board that will only differ by the processor, or RAM capacity:
- SoC (one or the other)
- Rockchip RK3399 hexa-core processor with 2x ARM Cortex A72 cores up to 2.0 GHz, 4x Cortex A53 cores, and an Arm Mali-T860 MP4 GPU
- Rockchip RK3399Pro hexa-core processor with 2x ARM Cortex A72 cores up to 2.0 GHz, 4x Cortex A53 cores, an Arm Mali-T860 MP4 GPU, and a Neural Network Processing Unit (NPU)
- System Memory – 2 or 4 GB LPDDR3, dual channel
- Storage – eMMC flash module, micro SD card (bootable), 128 Mbit SPI flash
- Video Output & Display Interfaces – HDMI 2.0 output, eDP connector, MIPI connector + TP connector + backlight supply, DisplayPort via USB type C
- Audio – ES8316 Audio Codec; Headphone/MIC jack
- Connectivity – Gigabit Ethernet, SDIO socket for WiFi and Bluetooth module
- USB – 2x USB 2.0 host ports, 1x USB 3.0 port, 1x USB 3.0 type C port with DisplayPort Alt-mode
- Camera – Parallel CSI, 2x MIPI CSI
- Debugging – 3-pin serial header
- Expansion
- 40-pin GPIO header (I2C/SPI/I2S/UARTs/GPIOs)
- PCIe x4 slot
- Misc – Heatsink mounting holes + FAN header, Power/Reset/Recovery buttons, IR receiver
- Power Supply – 12V DC input via power barrel jack 12V/3A recommended for most case. 12V/5A may be needed for power hungry PCIe card
- Dimensions – 133mm x 80mm x 19mm (Same as Pine64 board)
The board will support Android and Linux distributions. One positive is that the PCIe interface is actually exposed, and cost-down has been achieved partially but not including storage, nor wireless module by default, and install rely on either a micro SD card or eMMC flash module to boot the operating systems, and external wireless module for WiFi and Bluetooth.
RK3399 based Rockpro64 will launch on March 15 for $59 to $65 with 2GB RAM, and $79 with 4GB RAM, while Rockpro64-AI should start selling on August 1, 2018 for $99 with RK3399Pro and 4GB RAM. The company is also planning to launch Pine64 H64 board powered by Allwinner H6 processor, but I’ll have a look at little later, especially official launch is planned for January 31, 2018 (in two days).
Thanks to q-bert and nobe for the tip.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
That board layout! My eyes are bleeding…
How could they think this was a good idea?
Also, that Wi-Fi/BT module is going to have serious issues when the USB 3.0 is in use.
Interestingly though, they appear to have gone with a very different board layout than everyone else so far, especially with regards to the memory chips. This looks like 2x 32-bit instead of 4x 16-bit memory. Then again, I guess there could be two memory chips on the bottom of the PCB as well.
How is the Linux mainline support for the RK3399? Will this be another board that just works with a few custom kernels and it long term use heavily depends on the goodwill of the OEM?
@Floyd
Nope, RK3399 is one of the ‘open source’ Rockchip SoCs like RK3328. Simply check http://opensource.rock-chips.com and comments in other recent RK3399 related threads (eg. Orange Pi RK3399)
@Floyd
Mainline Linux support is pretty good because RK3399 is found in Chromebooks and both Rockchip and Chromium.org developers are regularly committing code to mainline.
See discussion @ https://www.cnx-software.com/2018/01/29/orange-pi-rk3399-development-board-launched-for-109/#comment-551182
With a pcie2sata exp board, and a compatible case, and a picopsu, you could make a big nas with 4+ drives with this.
@alevan
But if you add the costs of all of this you’re most probably better off with a Helios4 (Marvell Armada 385 ARM SoC) or HP Microserver (x64 — both with ECC memory which is nice for people hating silent bit rot).
Adding a bunch of SATA disks to an SBC is also nothing new. When I add one Marvell 88SE9215 based mPCIe card to my EspressoBin I’m able to access 5 SATA disks (one amazingly fast, the 4 behind the 88SE9215 bottlenecked by PCIe), adding two of them to my Clearfog Pro I can attach 9, most recent Clearfogs can also turn their M.2 SATA slot into PCIe and then even the little Clearfog Base can provide access to 8 SATA disks (one 88SE9215 in the mPCIe slot and eg. one Syba SD-ADA40118 in the M.2 slot).
But mPCIe is limited to a single PCIe 2.x lane, M.2 would theoretically support 4 lanes but in reality the available cards are limited to x2 today (I only came accross NVMe SSDs making use of M.2 key M so far making use of all 4 lanes but those SSDs want PCIe 3 and not 2 to show their real performance). So a ‘normal’ x4 PCIe slot on this board provides the ability to use all 4 lanes flawlessly and there are adapters available to convert to other connector standards like mPCIe, M.2 or even U.2 (SFF-8643 Mini SAS connector).
But whether RK3399 is able to fully saturate PCIe 2.1 x4 is a different question. It wouldn’t be the first time that ‘SoCs made for the job’ that look weak by specs outperform more powerful looking ones (eg. the dual-core 1GHz Marvell Armada 3720 on EspressoBin easily outperforms the octa-core ODROID HC1/HC2 clocking at 2 GHz if it’s about the NAS use case).
IMO it’s the flexibility that makes the decision to use a normal PCIe slot here that smart. You find literally everything for this connector. Whether all combinations are reasonable (for example it’s easy to cramp in an old multi-port SATA adapter with crappy RAID functionality that increases consumption a lot) is another question.
Rockpro64 comes with 128Mb (16MB) SPI Flash and this will be the prefer booting method. Power supply is +12V due to PCIe requirement. In general, 12V 3A power supply should be good enough. However, for power hungry PCIe card, can use +12V 5A power supply. The PCIe is x4 open ended.
Would the Type-A USB 3.0 port have decent speed for an SSD ?
The photos are from different boards, or different revisions of the board.
In the photo at the top, the USB connectors (at the top right) are different from the USB connectors (at the bottom) in the photo at the bottom.
The photo at the top looks like the one mentioned in the specs.
There is one USB 3.0 Type A and one Type C port. One photo seems missing the type A host port (top one). The type C port already carry DP signal.
“PCIe 4x slot”
Is x4 physically (the slot size), or electrically (lanes|wired) ?
Sure. RK3399 and RK3328 used on ROCK64 share the same USB3 controller. With large block sizes, a performant SSD (good for +500 MB/s) and a good UAS capable USB-to-SATA bridge we can get close to 400 MB/s sequential performance (both read and write). But where SSDs really outperform spinning rust (random IO, IOPS, low latency) the USB3 layer slows things down compared to good native SATA implementations. I would assume the numbers I collected over there apply to RK3399 too: https://forum.armbian.com/topic/1925-some-storage-benchmarks-on-sbcs/?do=findComment&comment=34192
Sure. RK3399 and RK3328 used on ROCK64 share the same USB3 controller. With large block sizes, a performant SSD (good for +500 MB/s) and a good UAS capable USB-to-SATA bridge we can get close to 400 MB/s sequential performance (both read and write). But where SSDs really outperform spinning rust (random IO, IOPS, low latency) the USB3 layer slows things down compared to good native SATA implementations. I would assume the numbers I collected over there apply to RK3399 too: forum.armbian.com/topic/1925-some-storage-benchmarks-on-sbcs/?do=findComment&comment=34192
Electrically (and it’s PCIe 2.1). Physically the slot is open ended so no troubles to insert x8 or even x16 cards.
@ tkaiser
Thanks for the link.
The 4K random IOPS don’t look good. 4K random speeds is what I always look at. I seldom use mega and giga sized files. And also, OS’es are made up of tiny files.
I still have 2 unused eSATA expansion cards (PCI-e 2.x) from an old Gigabyte X48 m/b (GA-X48T-DQ6). Too bad I can’t use those. Nowhere on the board to plug its SATA signal and power cables.
Everyone likes to back seat drive, be wise after the facts are known. Instead of second guessing designers and manufacturers, why don’t the community that write the Linux actually set out a design brief of what they want, need in hardware.
But that of course would require putting their neck out and justifying their own design decisions.
@TLS
The Wifi and USB are not on same PCB means not on same ground plane, the interference can be under control. Just think about like USB Wifi dongle plug into USB port. If the interference arise after EMI lab testing, we can effectively resolved such issue by increase ground plane surface on the Wifi module, example from 4 layer to 6 layer PCB design. However, if the USB and Wifi design on same PCB, then your concern may be valid. On the DDR3 memory, most modern design using LPDDR3 which is x32. This also allows 2GB and 4GB memory configuration using same PCB layout.
I zoomed into the first picture in this post and noticed a 3-pin battery connector labelled VBAT on the top right corner of the board; next to the RTC battery connector. I sure hope the board includes an on-board battery charging circuit with gauge. That would be impressive at this price point.
@TL Lim
That doesn’t matter the least bit, as beyond the PCB traces being an issue, if you use a poorly shielded USB 3.0 cable (and there are many of those, I know, as I’ve tested this in the past) you get interference. At a previous job, we found that if a poorly shielded USB 3.0 cable was connected, the completely killed the ZigBee radio in the product and reduced the Wi-Fi to a crawl. In this case, the USB 3.0 controller was on a different PCB from the Wi-Fi and ZigBee and even on the opposite side of the product and shielded. None of that mattered due to the cable acting as an antenna. I wish it was as simple as you make it out to be, but sadly this is not the case.
Beyond this, the PCB traces for the USB 3.0 aren’t even shielded on the PCB from what I can see and this will cause further interference. If you have a look at consumer routers with USB 3.0, all of the manufacturers shield the PCB traces to avoid interference with the 2.4GHz Wi-Fi signals. Asus has major problems with this when they launched their first router with USB 3.0 and had to change their PCB design because of this.
Likewise, several notebook companies in the early days of USB 3.0 didn’t shield their PCB traces and this prevent both Bluetooth and 2.4GHz wireless mice to work in some notebooks. Intel has plenty of documentation to show how to solve this issue.
@TL Lim
What speed DRAM is being used on this board?
@crashoverride
PC-1866
@TLS
Thanks on the advise and take in your inputs.
Well, depends (especially if you compare with using the same SSDs on a Raspberry Pi with one of the more popular ‘SSD shields’ for Raspberries which are magnitudes slower 😉 )
Anyway, USB is not a great base for storage anyway and at least I was pretty impressed when we started playing with RK3328 on ROCK64 last year that performance was that great (I expected much lower performance). If you want better random IO performance always try to avoid the additional USB layer (especially if UAS can not be used). Attaching a SATA controller via PCIe is always an option but at least the cheap single lane controllers I tested with were all outperformed by some SoC’s native SATA performance (Marvell Armada 37×0 and 38x as on EspressoBin and Clearfog).
On the other hand SATA/AHCI itself is already a huge bottleneck wrt random IO and then it gets really interesting with RK3399 and Rockpro64 again since you can easily attach NVMe SSDs (directly or converting to M.2 or U.2). Those will for sure better perform with a PCIe 3.x host implementation but I would believe you get also impressive results with PCIe 2.1 (though it gets interesting how the kernel’s scheduler deals with RK3399’s big.LITTLE challenges. I would assume NVMe handling on the little cores being half as performant compared to the two A72)
So the speed of the PCIe 2.1 x4 is 500MB x4 – overhead? Then comes the question how is the SoC able to move the data…
Anyway, very interesting board!
Nope. PCIe 2.x is 5GT/s per lane using 8b10b coding. That’s the theoretical maximum (just like USB3 SuperSpeed also with the inefficient 8b10b encoding defines something like ‘5 Gbps’ and SuperSpeed+ with the far better 128b132b coding is referenced as ’10 Gbps’). You can do the math and then know some numbers the implementation is not able to exceed. But you know close to nothing wrt the maximum data transmission rates that are really possible (especially since stuff like drivers here also are important, a simple kernel switch with better settings might double transfer rates at the application layer).
AFAIK no one has tested PCIe performance on RK3399 so far (at least nothing publicly available) and even if there would be numbers available I doubt they have any meaning since without appropriate settings/drivers performance will always suck (and that’s what we learned so far on almost all ARM SoCs. Stock Android images or half-baked Linux images based on Android kernels all performed very poorly in unimportant areas for the original use case).
See Allwinner SATA: they implement SATA II that defines a 3 Gbps signal rate (again with the inefficient 8b10b coding) and the implementation is limited to 45 MB/s sequential write performance while everyone thinks about ‘300 MB/s’ with SATA II. Signal rates are irrelevant on slow devices, especially if they’re not designed for the use case (see eg. ARMADA 8400 with 4xA72 but designed for high IO and network throughput with lowest latencies possible).
is there descent pcie support for this in the kernel?, meaning you can just plug any normal pcie card into this and it will work as on X86?
@Jeroen
RK3399 is quite old today 😉 bbs.t-firefly.com/forum.php?mod=viewthread&tid=1901&extra=&page=2
And wrt ‘plug any normal pcie card into this and it will work as on X86’ you might want to do a search in the upper right corner here for ‘pcie aperture bar’.
@tkaiser
The best way to test for PCIe performance is simply to plug a 10G NIC into the slot and see the real bandwidth that can be achieved in Rx, Tx and Rx+Tx. The Myricom NICs are particularly interesting for this because the driver is able to test the transmission rate with the NIC without anything connected on the other side. It helped me find some correct motherboards in the past by simply plugging the NIC into whatever PC I found, until I found some with decent numbers.
I could possibly buy such a board and run a test, but I think I won’t have any use for it, and unused boards start to accumulate on my desk :-/
@willy, hmm you mention 10G cards, really interesting if they can be used with this board. I have a bunch of Mellanox 10G cards i recently bought, and if i can use them with this board, then a small Ceph lab can become reality.
@tkaiser
To me, if the alternative is not going to be very much faster than eMMC with 4K random files, it’s not worth the extra money, and also not worth the pollution/cluttering of the setup.
@TLS
This is the first release, they will overcome these issues when they really see these as problems,
Moreover the USB 3.0 signals are differential, the problems should not that serious,
Thanks for your detailed feedback.
@TLS
The Pine A64 boards are similar in design and form factor and have a second pair of DRAM’s on the other side.
unfortunately the Rockchip RK3399 based rock64pro board isn’t going to be on sale tomorrow (or later today if you’re much further east than I am), it was announced on the pine64 forum on the 6th March that it was being delayed till April.
@Saravana
You ever made a product with USB 3.0 and 2.4GHz wireless built in? I have and it had real world issues.
Not only did we have to re-design the PCB, but as noted above, a lot of USB 3.0 cables when connected to a USB 3.0 caused interference so bad that the 2.4GHz wireless radios (of which there were two in the device) either weren’t reachable at all or caused severe slowdown/delay of the signals.
If I though this was a non issue I wouldn’t have pointed it out, but clearly you know better.
Intel has an article and a downloadable pdf document about this : https://www.intel.com/content/www/us/en/io/universal-serial-bus/usb3-frequency-interference-paper.html
(I realise that I’m not Saravana.)
Pine64 commented on their forum why this board is late…
https://forum.pine64.org/showthread.php?tid=5763&pid=36691#pid36691
The Rockpro64 has been delayed due to incorporate one last minute new feature that we think is an important one.
Due to this feature is a totally new one on RK3399, we need to proof its work first before able to proceed. On last week we have knows that it works and will further test on next week to make sure “production-able”. We are currently working very hard to make sure keep up on this very tight schedule so that we can roll out on end of this month.
Sorry that we will be disclose on this new improvement at current time and for sure that we will introduce when release on end of this month
So we are all guests now hey? 😉