We may just have written about Geniatech RK3566/RK3568 development board, but as expected, Pine64 has now unveiled more details about Quartz64 SBC powered by Rockchip RK3566 SoC.
As we’ll see below, the design is very similar to RK3399 based RockPro64, but the new model adds a native SATA 3.0 port, an integrated battery charging circuitry, an ePD port for e-Ink displays, and supports more memory with up to 8GB LPDDR4 RAM.
Quartz64 Model A preliminary specifications:
- SoC – Rockchip RK3566 quad-core Cortex-A55 processor up to 1.8 GHz with Arm Mali-G52 GPU supporting OpenGL ES 1.1/2.0/3.2, OpenCL 2.0, Vulkan 1.1, 0.8 TOPS NPU for AI acceleration
- System Memory – 2GB to 8GB LPDDR4
- Storage
- SPI Flash
- optional eMMC module from 16GB up to 128GB capacity
- bootable SDHC/SDXC MicroSD card up to 256GB (or is it 2TB?)
- SATA 3.0 port (multiplexed with USB 3.0)
- Video Output / Display Interfaces
- HDMI 2.0a up to 4Kp60
- 4-lane eDP up to 2560×1600 @ 60Hz
- 4-lane MIPI DSI up to 1440p
- SPI Touch Panel Port, SPI with interrupt
- Camera I/F – 4-lane MIPI CSI camera Interface up to 8MP
- Networking
- 10/100/1000Mbps Gigabit Ethernet RJ45 port
- Optional WiFi 802.11 b/g/n/ac with Bluetooth 5.0 via header via SDIO 3.0 and UART
- USB – 3x USB 2.0 host ports, 1xUSB 3.0 host port
- Expansion
- 2x 10-pin GPIO header
- PCIe x4 open-ended slot with PCIe 2.0 x1 interface
- Misc – RTC battery connector
- Power Supply
- 12V/3A DC input via 5.5/2.1mm DC barrel jack
- VBAT Lithium Battery Connector with temperature sensor input
- Dimensions – 133 x 80 x 19mm
It’s nice to have SATA, but as I understand it, the board relies on one of the multi-PHY Interfaces from RK3566 processor with SATA and USB 3.0 being multiplexed, meaning you can use SATA 3.0 if you don’t use USB 3.0, and use USB 3.0 if you don’t use SATA.
The specifications above are specific to model A, as there will also be Quartz64 model B about the size of a Raspberry Pi Model B board with built-in WiFi & Bluetooth, and a 40-pin GPIO header. An M.2 PCIe socket will take place of the PCIe slot, MIPI DSI and CSI connectors will be reduced to 2-lane up to 1080p displays and 5 MP cameras respectively, and model B will also lack SATA and eDP, and come with one less USB 2.0 port.
The board will support both Android 11 and Linux distributions, but right now, you’ll find some specifications, PDF schematics (model A only), as well as the Android 11 SDK in the Wiki. Once Linux is up and running on the platform, Pine64 expects Panfrost open-source GPU driver to just work out of the box.
Bear in mind that Quartz64 is not a “Pro’ board, and performance-wise, the four Arm Cortex A55 cores clocked at 1.8GHz are only about 15-25% slower in computational tasks than the ROCKPro64. Initial benchmarks (Geekbench 4) also show Quartz64 to have about the same CPU performance as Raspberry Pi 4, and CPU temperature rarely spiked over 60°C under load even without a heatsink.
Pine64 is not ready to announce a launch date yet, but we do know they plan to have a 10-inch e-Ink panel available in the Pine Store when the SBC officially launches.
We learned about the new board in Pine64’s February update, where an upcoming $15 Linux RISC-V board was also announced. The yet-to-be-named SBC will be powered by a XuanTie C906 based RISC-V processor plus BL602 RISC-V SoC for WiFi & Bluetooth connectivity. Pine64 also plans to design a range of LoRa/LoRaWAN hardware from modules to gateways and expects it to be used for LoRa-based text communication besides just IoT networks.
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
> about the same CPU performance as Raspberry Pi 4m
pi 4m?
Yes, exactly. The “m” key is just right next to the “,” key 🙂
hi, I search the same board but with RK3568, With CANBUS…
does will coming soon?
Thanks you
JE cherche la meme carte avec un RK3568 avec le le bus CAN, est ce qu’elle va sortir bientot?
Merci
I’m sure it will come since RK3568 has 3x CAN bus interfaces, but I’m not aware of any such board right now. If one comes up, I’ll make sure to write about it on CNX Software.
> performance-wise, the four Arm Cortex A55 cores clocked at 1.8GHz are only about 15-25% slower in computational tasks than the ROCKPro64
Rather misleading statement. Lukasz used this Geekbench entry as reference that clearly shows that ARMv8 Crypto Extensions weren’t enabled at benchmark time while RK3566 possibly ran at 2.0 instead of 1.8 GHz. In other words: the best you could do with these numbers is to throw them away…
Hey, you are correct, these numbers are rather empty. In my defense I also wrote “don’t read too much into these generic [benchmark] results” and “(…) such benchmarks do not always translate well to real-life tasks (…)”.
No worries, RK3566 is simply… just a boring quad A55, so once software/settings are adjusted accordingly (the AES stuff) numbers will look nicer. Simply compare with another boring quad A55 running at the same clockspeed: https://browser.geekbench.com/v4/cpu/compare/15949977?baseline=15920516
“15-25% slower in computational tasks than the ROCKPro64”
Memory Copy/Memory latency comparison between Odroid C4 and Quartz64(RK3566) already is ~15% lower on double 4GB Quartz64 (cpu IPs comparable) and A55 boards are no real desktop replacements, yet on 1.8-2.0Ghz?
( Sata revisons can get up to 3.5 or Sata-600, but 6.0 is uncommon? )
> Memory Copy/Memory latency comparison between Odroid C4 and Quartz64
…is impossible right now. The Geekbench entry above is for something calling itself ‘rockchip rk3566_rgo’. There exist several entries for this thing already, so let’s compare settings from early December with those from mid January: https://browser.geekbench.com/v4/cpu/compare/15991153?baseline=15920516
You never benchmark hardware, you always benchmark hardware + software + settings. Rockchip defined RK3566 as a subset of RK3568 via device tree and removes the highest CPU and memory clockings in this process (see answer to ‘itchy n scratchy’ below).
Nobody outside Rockchip knows whether this is really necessary with Quartz64 or RK3566 in general so right now it’s unclear whether Quartz64 will run at 2.0 GHz or not and especially how memory will behave.
Wrt memory performance: this was one of the first things I did when starting to deal with RK3399 years ago: setting the dmc governor to performance (improved memory latency by 2). And there are other settings that both affect stupid benchmark numbers as well as real-world performance. They need to be set accordingly for the use case in question.
From what is presented about rk3399(pro), memory bandwidth is a lot more dependent on cpu cores top frequencies (shared memory with gpu? npu?) instead of memory type (lpddr3, lpddr4), thx
As shown above with RK3399 we’ve seen differences in memory latency by factor two just by switching dmc memory governor. And wrt bandwidth we’ve seen the same differences just by adjusting something else. A memory benchmark is always also a CPU benchmark since when the CPU cores are limited (either by clockspeeds or settings) then reported ‘memory performance’ will suffer too of course.
> PCIe x2 open-ended slot
Confusing since RK3566 is said to have just a single Gen2 lane. But looking into schematics confirms that it’s just the slot layout and all you get performance-wise is ‘PCIe2.0 x1’.
Wow, 60°C under load w/o heatsink sounds impressive, at least comparing to my RK3399 based M4V2. Not clear, how many lanes PCIe and M.2. slots will have. There is SPI and theoretically it should be able to boot from NVMe, which is much better SBC option in terms of size and performance.
Gotta have that RK3588
Just looked into the SDK tarball. For anyone interested in the kernel part better check branch develop-4.19 at rockchip-linux/kernel which is a lot of recent commits ahead.
I’m confused by the “2x open ended PCI-E slot”. I’m not aware of any 2x PCI-E slot (or card spec). I thought the only card and socket sizes were 1, 4, 8, and 16. Cards/slots that support 2x or 12X (the only other physically realizable PCI-E supported bus widths) are supposed to use the next larger connector/edge size. I.E. you can have a ‘2x’ card, but the edge connector should be that of a 4x. The same goes for slots. You can have a ‘2x’ slot, but the physical connector should be that of the next largest supported size–4x.
From looking at the picture, that really looks like a 4x slot.
Why bother? It’s wrong in Pine64 wiki, it’s copy&paste here and it’s x1 anyway in reality since RK3566 exposes only a single Gen2 lane.
As I understood it, it is an open x4 connector accomodating any kind of card. But electrically it delivers what is available, as you tell, it seems to be 1x only 🙁
Pine64 wiki contains links to schematics as well as RK3566 data sheet. There’s one PCIe2.1 interface limited to ‘one lane’ supporting ‘2.5Gbps and 5.0Gbps serial data transmission rate per lane per direction’.
But since from a software point of view RK3566 is just a subset of RK3568 the latter will automagically benefit from all ‘Linux bring-up’ efforts for the former.
That brings us back to my original thought. If it’s just one lane, then you only needed to use an open ended one lane connector. The only reason to use a 4x connector is is you had >1 lane to work with (i.e. 2x). The supported link widths are 1x, 2x, 4x, 8x, 12x, 16x, and 32x. (there’s no standard connector for the last one, IIRC)
It’s the same open-ended x4 connector they use on the RockPro64 already so maybe they’ve sourced too much, this connector is dirt cheap, it’s for aesthetics or it provides more stability with some PCIe cards (seen a lot of horrifying pictures of people using PCIe cards with RockPro64 without anything comparable to an enclosure with proper slot brackets to secure the card).
“seen a lot of horrifying pictures of people using PCIe cards with RockPro64 without anything comparable to an enclosure with proper slot brackets to secure the card”
I imagine the setups from here.
Waiting for a pine phone 2
Won’t hold my breath though…
Read ‘Pine64’s February update‘: in fact this Quartz64 thingy is already the development platform for future RK3566/RK3568 based mobile Linux devices.
Looking back 5 years ago when first Pine64 boards were sent to developers it’s amazing what TL Lim, Kamil, Lukasz and many many others have achieved in the meantime: building a vibrant OSS community around hardware devices that could be best described as a ‘hardware service for a software community’.
Definitely.
If you think about i.e. H3 mine was laying around collecting dust for years, as Allwinner Android was (and still is) useless and mainline was spotty at best.
As in the meantime the sunxi guys did a great job pine phone gave the whole sunxi project a huge push and ppl like jernej integrated everything for LE on H3 (and many other SOCs).
But again, it took a while to reach this state, so I think also this new flavour of RK takes a while till everything incl. power management and all relevant peripherals are properly supported. Hopefully no 5 years!
Better engagement with FOSS was one factor in the switch to Rockchip, no doubt.
Rockchip has an incentive to hasten the process – Chromebooks.
I doubt this very CPU will have enough power for a chrome book…
On peak Javascript requiring a Cortex A7x, perhaps a RK3588 instead?
Otherwise, a Pinetab 2 with 8GB RAM running phosh or plasma mobile would be competitive against a current generation Chromebook Duet tablet and hopefully half the price. 🙂
Hey now, go try out H3droid! https://h3droid.com — Maybe Allwinner offers shit Android, but we gave it our best effort! Noting our effort was only on the old Android 4.4 since the SDKs released for Android 7 are utter garbage as you eluded to.
Cheers!
nm ?
If you’re asking about the process I believe it’s 22nm FD-SOI.
yes, 22 is a lot!
https://www.cnx-software.com/2020/12/01/rockchip-rk3568-processor-to-power-edge-computing-and-nvr-applications/#comment-578856
tnx, infact in the article you pointed, other guys are disapointed by the 22nm… it should be < 15