By Nermeen Nabil Khear 
The good folks at Turing Pi sent me a trio of RK1 modules to put through their paces, to go along with the single unit I bought myself. And the TLDR, if you need some real ARM processing power, and don’t want to spend an enterprise budget, a Turing Pi 2 filled with RK1s is a pretty compelling solution. And the catch? It’s sporting the Rockchip RK3588 processor, which means there are challenges with kernel support.
For those in the audience that haven’t been following the Turing Pi project, let’s recap. The Turing Pi 1 was a mini ITX carrier board for the original Raspberry Pi compute module, boasting 7 nodes connected with onboard Gigabit.
That obviously wasn’t enough power, and once Raspberry Pi released the CM4, the Turing Pi 2 was conceived, boasting 4 slots compatible with the Nvidia Jetson compute units, as well as the Raspberry Pi CM4 with a minimal adapter. We even covered it shortly after the Kickstarter. And now we have the RK1, which is an 8-core RK3588 slapped on a minimal board, pin compatible with the Nvidia Jetson boards.
The story about Linux
Now, it has been a while since Turing sent me these devices. The main reason is that Linux support was broken in a couple of important ways. I’ve spent many hours over the last six months trying to debug these issues, and was really quite excited when I could finally boot the stock installers of Fedora 41, Ubuntu 24.10, and latest OpenSuse Tumbleweed on the RK1. The most notable issue is that mainline Linux completely failed to see the NVMe drive at boot, due to a pinmux issue that might finally get officially fixed in 6.13 or a 6.12 point release. This issue could be worked around with a custom Device Tree Binary (DTB), but it is a fiddly installation process. And the second issue was related: Using this hacked DTB only ever worked for the 32 GB ram model. These two issues really made a proper review very difficult.
You may be checking your Kernel calendar, and noting that right now, we just got the 6.12 release. Did that include the fix? Not yet. Here’s where we get to dive briefly into the ARM UEFI boot process. The Device Tree is the data structure that the kernel uses to find and initialize the hardware on the board. The 6.12 kernel is otherwise in pretty good shape for using the RK1 as a compute unit. It just has some DTB problems.
The important note is that for UEFI booting, the bootloader provides the DTB. U-boot copies that binary tree into memory, and hands the kernel a pointer to it during boot. The new development is that the semi-official Ubuntu 24.10 image finally has the patched DTB with the corrected pinmux. This arrangement also takes care of the 16GB boot failure. That meant that we could use the Turing Pi 2’s web interface to upload the Ubuntu 24.10 image, which includes U-Boot, log in to that install, and then use dd to write a disk image to the NVMe. That was a huge step forward, but it was still not ideal for a couple reasons. First, it’s a pain to install a Linux image just to be to install a Linux image. And second, not every distro releases an image that’s appropriate to simply copy onto the target drive.
The intended solution is UEFI boot that supports booting from a USB ISO. That, unfortunately, didn’t work. U-boot pulls its DTB definitions from the Linux Kernel itself, and while [Josh]’s image did have a few patches on top of the kernel’s RK1 DTB, it didn’t have a working DTB. U-boot needed not only a DTB patch, but also a patch to its own USB support, as the RK1 has a nifty trick where the USB port can be a host, device or OTG port. U-boot doesn’t really know what to do with this, and for UEFI boot, it needs to be explicitly set to host mode. All that work resulted in this flashable u-boot image. You can flash it from the web interface to an RK1, and it actually finally works to do UEFI boot on MMC, USB, and NVMe. Tested with Fedora 41, Ubuntu 24.10, and latest Tumbleweed.
So how did it turn out?
Finally, we can start with benchmarks. I ran a set of tests using the Phoronix test suite. The Pi4 is running off an SD card, and the Pi5 and RK1 results labeled “nvme” are all running off the same model of Crucial P3 NVMe.
There is a wildcard here I didn’t control for. The RK3588 is eight cores, but four A76, and four A55. So for single-threaded tests, it may be that the benchmark didn’t actually run on the most performant core. The other distinction here is that the “rk1-mainline” results is from running an Ubuntu 22.04 install with the vanilla 6.7.0 kernel, while the rk1-rok tests are from running the same Ubuntu release, but with the Rokchip kernel. Due to the issues I ran into with Linux installs, noted above, these benchmarks are a little stale.
The Pi4 is really showing its age here, and the fact that the Pi4 can only run off an SD card definitely doesn’t help compilation times. The Pi5, running off the NVMe, makes a good showing, but the RK1 is about 80% faster in this particular test. And that’s generally what I found across the board, with the RK1 performing generally between 50% and 100% faster than the Pi5.
That advantage seems to boil down to the RK1’s 8 cores, as opposed to the 4 cores in the Pi5. Tests like the timed Eigen compile showed the Pi5 and rk1 absolutely trading blows. And in the TSCP chess program, the Pi5 actually manages to eke out a win, again on a very single-core sort of workload.
So, each RK1 gives you 8 cores and up to 32 Gigabytes of ram. And thanks to the PCIe x3 lanes available, and the NVMe slots on the bottom of the Turing Pi 2, plenty of NVMe storage. Four of those in a mini-itx form factor might just be a compelling bundle of compute.
How to Get Going
One of the neat features of the Turing Pi 2 is that the baseboard itself is a Linux machine, so you can ssh into the baseboard, and access the serial ports of the individual blades. While writing this, I’m working with slot two, which is /dev/ttyS1, based on the TP2 documentation. The command to monitor and interact is picocom /dev/ttyS3 -b115200.
The other useful tool here is the web interface. In there we can toggle power on and off, as well as flash an image to the MMC of individual nodes. Grab the .bin I generated, flash it to the RK1’s MMC, and then boot from an ISO burned to DVD or a flash drive. Use the minicom command to access the serial interface, and do the install configuration over serial.
If you have a Linux install on both the MMC and NVMe, it’s useful to know how to boot off the emmc again. From that picocom terminal, interrupt u-boot, and set the target back to just the mmc:
setenv boot_targets mmc0
boot
And there you have it. This process should work for most Linux distros that have an Arm64 ISO that can boot using UEFI, running the 6.7 kernel or newer, but ideally at least a 6.11 kernel.
Into the Future
Officially, when it comes to distro options, there’s good news and bad news. Officially, you can run whatever distro you want, so long as it’s Ubuntu. The better news, support for the RK3588 is making progress in the upstream kernel. It’s decent enough that some of the benchmarks above were run with 6.7.0. 6.11, the kernel that comes with Fedora 41 is even better shape. Some HDMI work is slated to land in 6.13, along with the DTB fix.
The NPU unit, an AI accelerator built in to the chip, has an open source driver, and patches have been submitted. As far as I can tell, these have not landed upstream in the kernel yet, but work has continued since then.
The bad news is that [Josh Riek], the maintainer of the Ubuntu-Rockchip image, has taken a leave of absence from the project, putting the premier Linux image for Rockchip devices in serious limbo. And this is where we come to the biggest reason why you might not want to use the RK1. Rockchip has sadly followed the pattern of many other hardware vendors in the embedded world, and provided very little support to the community trying to maintain the software for their devices. The RK3588 launched back in 2022, and it’s still not fully supported in the Kernel. That’s not to say that Rockchip has been completely remiss. There are four Linux kernel maintainers with @rock-chips.com email addresses. But one of [Josh]’s complaints was that the whole project was on him, and Rockchip refused to even have a conversation about supporting the project.
The Conclusion
OK, so the RK1 has some impressive capabilities, and while the compatibility story isn’t perfect, it’s much better than it was, with even more coming. But what’s the real use-case for these things? What problem does a quartet of RK1 boards in a Turing Pi 2 solve, that a conventional desktop doesn’t? When I started writing this article, the answer was running Github actions on actual ARM hardware. And while Github beat us to it, now offering ARM64 runners for Github actions, those runners are considered “large” runners, and not available on the Github free tier.
Even after the ARM64 runners roll out to everyone, is there still a use case for hosting your own runners? Github runners aren’t known for their blazing speed, and a big part of that is the fact that Github runs everything inside virtual machines. An organization is also limited to a max of 20 Github supplied runners. If you have a relatively secure way to run your workflow on real hardware like the RK1, the speedup might be worth it. I look forward to future coverage on this topic.
There are, obviously, some other things you might want to do with RK1 devices. It has plenty of horsepower to run web services, host builds, run Docker images, and more. The RK1 is basically powerful enough for anything compute you want to do.
So what do we think about the RK1? It’s certainly not the only way to get your hands on the RK3588 ARM processor. It is, however, the only way I know of to put four of them in a single mini-ITX form factor. The support isn’t quite as well developed as we’d like to see, but it does result in a usable system, with a lot of ARM horsepower in a small package. There are developers working on the system, so the situation there is looking to improve. I have a pair of RK1s in active use doing GitHub CI runs.
This articles is written by : Nermeen Nabil Khear Abdelmalak
All rights reserved to : USAGOLDMIES . www.usagoldmines.com
You can Enjoy surfing our website categories and read more content in many fields you may like .
Why USAGoldMines ?
USAGoldMines is a comprehensive website offering the latest in financial, crypto, and technical news. With specialized sections for each category, it provides readers with up-to-date market insights, investment trends, and technological advancements, making it a valuable resource for investors and enthusiasts in the fast-paced financial world.