Linux SBCs for development
+ reverse engineering

TL;DR: Tired of cross-compiling for your arm64 target? Try native development instead!

Why would you want to use a Linux-powered single-board computer (SBC) as a development host?

Does it have enough horsepower?

How about storage I/O?

All valid questions.

But before we tackle them, let’s review what purposes SBCs have served up to this point:

Background

Ever since the initial RPi launch almost 15 years ago, makers, hobbyists, and tinkerers have gravitated towards a super-low-cost Linux-capable single-board computer (aka SBC). Traditionally, SBC software development requires a cross-compilation setup.

The CPU architecture of choice when it comes to such SBCs is arm64, which is ubiquitous in everyday gadgets. Potentially, riscv64 is making inroads into this space too (more on this later). Many of the latest-generation SBCs include HDMI and other connector interfaces normally found on regular x86_64 machines. SBCs traditionally come with SD card storage, which is a big bottleneck for I/O and bandwidth-demanding applications. However, newer SBCs are often equipped with NVMe interfaces, which vastly reduces latency and improves I/O overall.

The question moseying around my mind

With these observations in mind, as of 2025, are SBCs capable of serving as a development desktop?

To be more specific: If I have a specific arm64 requirement, can I switch out my x86_64 desktop to an arm64 SBC and still enjoy an ‘acceptable’ experience in terms of overall desktop responsiveness and development activity speeds?

In this scenario, my personal requirement is to use a “normal” Linux distribution with full desktop and all regular development tools available (i.e., no cross-development necessary), which could serve as a development tinkering platform for low-level arm64/riscv64 assembly programming, a reverse engineering (RE) learning, and Linux kernel vulnerability research (VR).

Is it possible?

And if so… which would win a shoot-out?

Let’s find out together.

Alternatives

What are the alternatives if you want to experiment with – and learn the finer details of – arm64/riscv64 system and assembly programming, dynamic RE, and VR, debugging for the purpose of ABI education?

• QEMU (arm64 emulation) on your regular Linux x86_64 host.
• Your favorite DaaS/IaaS cloud provider nowadays often offers on-demand arm64 virtual machines.
• If you happen to have an Apple Silicon macOS computer, well, you are natively running arm64. The cost is far higher than an SBC though.
• Your mobile phone likely has an arm64 CPU, but depending on make and model, the execution environment could be severely constrained, due to locked bootloader, sandboxing, security policies, etc. And it’s normally not used for native development.

These are certainly viable options, or they could provide a good starting point for your tinkering. However, expert users might find them lacking for the following reasons:

• Cloud-hosted virtual machines might be good for development and any on-demand requirements, but still, you don’t have local access.

• Any virtual machine – local or cloud-hosted – might not be the right fit for any kernel-side VR experiments you want to conduct.
• A real tinkerer might want to run a variety of Linux distributions and Android, which might be inconvenient or not possible in the alternative environments.
• Also, most importantly, it is much more fun to be in full control of the piece of hardware in front of you.

Prerequisites/requirements

What do I unequivocally want from an arm64 SBC platform, requirements which I deem obligatory for development, learning, RE, and VR?

• 4k@60p display output.
• Full desktop environment. A “light” desktop, such as xfce, is sufficient.
• Support for NVMe storage. For I/O performance.
• Wired Ethernet with optional WiFi.
• Minimum 8GB RAM. 16GB preferred, since it’d allow for virtualization.
• Super-low cost = sub-$100. $140 for the 16GB variant might be worth it.
• Open source friendly. Distribution from public mirrors, and kernel on GitHub.
• Decent source-code compilation performance. “Reasonable” performance is a must.
• All my favorite development tools, some of which could be considered resource challenging, should run “adequately” in terms of perceivable user responsiveness.
  • Java apps, such as Jetbrains CLion C/C++ IDE.
  • Microsoft Code, as an alternative IDE/editor.
  • Ghidra. Unfortunately, some binary tools are not yet built for arm64 Linux/glibc.
  • Plus the usual tools you’d expect from a desktop, including web browsers.
• This use case excludes video streaming, LibreELEC, file servers, etc.

My Linux SBC shoot-out

Basically, I am looking for the most performant SBCs at the near-$100 price target. A not-all-encompassing survey centered on the following products:

• Raspberry Pi 5 16GB ($120)
  • Broadcom 2712 chip, 2.4GHz 4xCortex-A76 CPU, VideoCore VII GPU with a PCIe 3.0 x 1 lane
  • Argon ONE V3 case (as shown)

• Orange Pi 5 Ultra 16GB ($140)
  • Rockchip RK3588 chip, 2.4GHz 4xCortex-A76, 4xCortex-A55, Mali-G610 GPU with PCIe 3.0 x 4 lanes
  • eleUniverse case for Orange Pi Pro/Ultra

Many SBC vendors offer products with the RK3588(S) chip, and probably any of them would be comparable. There is a vast selection of additional SBC products, but tech specification-wise, they are assessed to offer less performance than the two selected.

One bonus SBC is included though:

• Orange Pi RV2 8GB ($70)
  • Ky X1 riscv64 chip, 1.6GHz 8-core with a PCIe 2.0 x 1 lane
  • Ugly acrylic case

I fully expected the RV2 is barely usable at all for the laid-out use case, since tech specifications point to performance equal to that of a Raspberry Pi 3 approximately. But it meets the price target, and I added it just for fun.

Evaluation criteria

For the purposes of this article, I am almost exclusively focusing on development and usability performance; the latter is less about the numbers but merely about concluding whether it’s “good enough.”

1. Compilation benchmark: Source-code compilation of a collection of open-source software.
2. Practical usability: Subjective usability assessment of my go-to editors, IDE, and tools as previously listed. Specifically, resource-hungry Java applications should run “adequately” swiftly. I fully expect that this test will touch the performance ceiling of what the SBCs are capable of delivering.
3. For general-purpose benchmarking numbers, I refer to this Phoronix RPi 5 article and this one on Orange Pi RV2, too.

Installation + platform setup

Let’s just list a few pointers on how to set up each platform: documentation availability, NVMe root file system, performance tweaks, etc.

General

For each platform:

• I install the “normal” distribution, and if there is a choice of desktop environment, the “lightest” one available is selected. Coincidentally, both RPi and OPi run Debian bookworm as the base distribution.
• Distribution is installed onto a 2TB PCI 4.0 NVMe, thus I/O is only limited by the SBC interface and not the disk.
• I use a host x86_64 Ubuntu desktop and an external NVMe disk enclosure with Thunderbolt/USB4 interface to install the vendor distribution image.
• There are several options to perform the image writing to the target disk, including standard Linux command line tools, but if you are unsure, I recommend using either rpi-imager (available via Debian repositories) or balena-etcher (see https://etcher.balena.io/).
• For all compilation benchmarks, I set the GPU governor to “performance,” which means it is pegged directly to its max CPU frequency; 2.4GHz for RPi, 2.8GHz for OC RPi (see below), and 2.26GHz for OPi.

Raspberry Pi 5

• Read the ample documentation available on the RPi website.
• The kernel is maintained on GitHub. The version is currently 6.12.34-rpt-rpi-2712.
• Raspberry Pi OS defaults to using Wayland as the display compositor.
• I recommend the following setup:
  • Dedicate an SD card installed with the standard Raspberry Pi OS, which is always plugged into the board as the fallback boot device. Once NVMe boot is enabled below, the NVMe boot device, if available, is preferred.
• Initially, you have to boot via an SD card regardless, since NVMe boot is disabled.
• Two hardware deficiencies are worth mentioning:
  • Only mini-HDMI connectors are available on the SBC, which is incredibly dumb, since they are uncommonly rare and you need specifically a mini-HDMI to DP/HDMI for the monitor.
  • You need a flimsy ribbon cable for the PCIe board connector and a separate board for the physical NVMe connector.
  • This board design choice is both annoying and short-sighted, IMHO. However, the simplest and best solution is to acquire an Argon ONE V3 M.2 NVMe PCIE Case, which allows for bottom-accessible NVMe and regular-size HDMI connectors.
• Interestingly, the RPi is easily overclocked, and I chose an extremely safe OC of 2.8GHz, with which I had zero issues running.
• The RPi by default conforms to the PCIe 2.0 standard, but you can easily set it to the speedier 3.0, see below. Again, only 3.0 x1 is supported, which allows for 8 GT/s equating approximately to 900 MB/s bandwidth.

In summary, I recommend the following distribution installation steps:

• Install distribution to both a SD card and the NVMe using the rpi-imager tool; it will download the appropriate image automatically. Plug in both the SD card and NVMe disk.
• Boot via SD card, and use the raspi-config utility to enable NVMe boot by enabling NVMe/USB Boot.
• Reboot and it should now prefer NVMe, and edit /boot/firmware/config.txt adding the below extras.
• Reboot and verify full PCI 3.0 speed with: $ sudo lspci
  • You should identify 8 GT/s for the Broadcom PCI

Here are the recommended config.txt additions:

[all]
dtparam=pciex1_gen=3
dtparam=nvme
usb_max_current_enable=1
dtparam=uart0=on

# user extra
enable_uart=1
uart_2ndstage=1
enable_rp1_uart=1
arm_freq=2800
#force_turbo=1
#over_voltage_delta=50000

[all]
dtparam=pciex1_gen=3
dtparam=nvme
usb_max_current_enable=1
dtparam=uart0=on

# user extra
enable_uart=1
uart_2ndstage=1
enable_rp1_uart=1
arm_freq=2800
#force_turbo=1
#over_voltage_delta=50000

Orange Pi 5 Ultra

• Get OPi 5 Ultra documentation and software images here.
• The OPi kernel is maintained here. The version is currently 6.1.43-rockchip-rk3588.
• The OPi Debian distribution defaults to using X11 as the display compositor.
• OPi allows for less tinkering with respect to OC and boot options, which just makes it easier. In fact, I never installed and ran from a SD card, only from a NVMe disk.
• No extra configuration is necessary to reach the promised PCIe 3.0 x4 NVMe speed, which translates to a decent >= 3GB/s storage bandwidth.
• Unfortunately, there seemingly is no OC support for OPi. Also, my board, and many others according to online evidence, runs at 2.26GHz rather than the advertised 2.4GHz.
• It’s worth mentioning that this is a nice one-stop-shop repo with build scripts for the entire install image build, including kernel, boot loader, and root file system. Very convenient and it works well.
• In summary, it’s very simple:
  • Install the distribution to the NVMe using balena-etcher on your x86_64 host.
  • Plug the NVMe into the OPi and power up.

Orange Pi RV2

• See OPi RV2 documentation and software images here.
• Unfortunately, the RV2 only supports 1080p display output, which alludes to the fact that riscv64 low-cost solutions are not yet at par with arm64 competitors.
• The installation procedure is exactly the same as for OPi 5 Ultra.

Reference platform

For the purpose of comparing the compilation benchmark with more or less the most performant realistic comparison machine, I include below the numbers for my own main x64_64 desktop machine.

• i7-12700K with 8 hyperthreaded performance cores plus 4 efficiency cores for a total max thread count of 20.
• 32 GB of DDR4 memory.
• Performance cores are all OC to 4.9GHz.
• The main disk is an NVMe at PCIe 4.0 speeds up to 7GB/s bandwidth.

DietPi alternative distribution

In addition to the “regular” vendor distributions, there are generic arm64/riscv64 offerings such as Armbian, DietPi, BredOS, and others. Out of the two highlighted, I spent some time experimenting with DietPi, and it’s worth noting the following:

• It’s an extraordinary distribution made by volunteers supporting a majority of popular SBCs, and it installs well on both RPi 5 and OPi 5 Ultra.
• The boot loader, kernel, and DTB builds appear to come from Armbian, since they do all builds from scratch rather than leaning on the vendor builds for said packages. However, it’s also possible to install custom vendor kernels on top of DietPi, especially with OPi since their build system conveniently generates .deb packages.

Results

Let’s discuss the results:

• Again, we are using the “standard” distribution the vendors recommend.
• It’s worth highlighting that the RK3588 is a bigLITTLE chip with 4+4=8 cores total, which should perhaps give a bit of an advantage over the BCM2712 chip with straight 4 cores.
• Compilation arm64 SBCs: I am astonished by the quite small difference between my reference workstation and the RPi and OPi. The reference machine is only slightly less than twice as fast as the far cheaper SBCs.
• Compilation OPi RV2: It is abundantly clear that the OPi RV2 is not even remotely comparable to the arm64 SBCs, a conclusion which I expected upon starting this endeavor. Mostly, I would assume this is due to an exceedingly simple microarchitecture implementation. Once implementations incorporating advanced pipelining, out-of-order execution, improved cache structure, etc., become the norm in these low-cost solutions, I’d expect performance will reach those of comparable arm64 chips.
• Usability OPi 5 Ultra: The conclusion is simple; it is usable as an arm64 Linux/Android desktop. Jetbrains CLion works fine at a very reasonable responsiveness and speed.

• Usability RPi 5: Something feels completely off when using Jetbrains CLion; it basically takes minutes to index even the smallest C application. The whole application feels sluggish to say the least, and there was no perceivable difference between the stock and OC configuration. I did suspect that perhaps the Raspberry Pi OS’s usage of the Wayland compositor had something to do with this. Therefore, I went through the exercise to re-run everything with X11 backend instead, but with basically the same results. I would like to conclude that what I am observing is a lack of GPU horsepower and/or something related to Java integration.

DietPi results

Since I was still perplexed by the above results, I had the lingering motivation to experiment some more. I noticed that the good folks running the DietPi distribution included support for OPi 5 Ultra, which is great, since I could conduct a final battle between RPi 5 and OPi 5 Ultra using the same distribution, thus comparing apples to apples. The following is worth noting about this final run:

• If I understand correctly, DietPi is using the Armbian project for all the SoC Linux kernel configurations and builds, including those of BCM2712 and RK3588.
• The default DietPi installation excludes a desktop environment, but for both targets, I installed xfce as a lightweight desktop.
• Specifically for OPi, I noticed a regression in the compilation benchmark. Therefore, I went ahead and built .deb packages from the Orange Pi GitHub-maintained kernel and DTB sources, and installed them onto the OPi for another test.

Observations:

• Compilation RPi 5: Interestingly, the RPi 5 shaves off a measurable amount of time compared to the time scored with Raspberry Pi OS. It is not immediately clear to me as to why, since both Raspberry Pi OS and DietPi are using Debian bookworm.
• Compilation OPi 5 Ultra: Again, I observed a regression with DietPi compared to standard OPi Debian. And even with the OPi kernel overlay, performance did not improve to comparable results with the vendor image. I leave the speculations at that for now, since it’s of little importance.
• Usability across all SBCs: The results reflect those previously yielded. RPi is more or less unusable, whereas OPi works well.

Conclusions + recommendations

riscv64 landscape 2025

As expected from the outset, the OPi RV2 was not a serious contender in this roundup. Even though it feels like RISC-V as an architecture has been around for a long time, everyone should realize that maturing a new CPU architecture and its implementations takes decades. If we consider ARM with MMU implementations (aka Linux-capable), it has taken more or less 25 years to reach the point where Apple Silicon runs in all Apple devices, including laptops and desktops.

The road is long for RISC-V until riscv64 silicon products reach performance equivalence with arm64 counterparts. ARM has done a seemingly good job advancing and incrementally updating the AArch64 specifications with v8-[1-7] and now v9. Until just recently, riscv64 suffered from an undefined and non-standardized mess with a multitude of specifications being drafted but no mainline roadmap, with the obvious risk of fragmentation across chip manufacturers.

However, things look brighter now:

• The OPi RV2 and its chip Ky X1 chip is, I believe, compliant to RV64GC specification, which is basically the generic 64-bit little-endian ISA baseline, without any bells and whistles. The Debian repositories are also RV64GC compliant.
• Late 2024, the RVA23 profile was ratified (see this announcement), which is a more demanding profile with features now expected from, say, the arm64 products, including vector and virtualization support amongst others.
• Ubuntu announced that version 25.10 and onwards will require RVA23 as a minimum requirement.
• In a recent RISC-V summit, many new RVA23 compliant products were announced – with the anticipated launch window by the end of 2025.

In summary, perhaps in 2026 there will be enough RVA23 market penetration, even in the ultra low-cost SBC segment, which might justify a follow-up blog entry.

Developer recommendations

Simply put, if you are an aspiring Linux/Android arm64 developer, reverse engineer, or vulnerability researcher on a budget looking for low-cost development and/or learning platforms, for me the Orange Pi Ultra is a solid option, which I am currently putting to use myself. But if you are a person with strong terminal-only persuasion, who thinks that only using vim/tags and other command line tools is a flex, both RPi 5 and OPi 5 will serve you well.

But if you don’t want to deal with more hardware… try our virtual desktops, WarpStations, and access a Linux environment in 5 minutes →

Illustration by Rebecca DeField.

Share the dueling Linux SBCs

Found this article useful?

⇣ Please share it with other folks around the web-based watering hole!

Share on Hacker News