linux

Raspberry Pi this morning launched the Pi 500 and a new 15.6" Pi Monitor, for $90 and $100, respectively.

They're also selling a Pi 500 Kit, complete with a Power Supply, Mouse, and micro HDMI to HDMI cable, for $120. This is the first time Raspberry Pi is selling a complete package, where every part of a desktop computer could be Pi-branded—and makes me wonder if uniting all these parts into one could result in an eventual Pi Laptop...

Before we get too deep, no, the Pi 500 does not include a built-in M.2 slot. Sort-of.

If anyone asks why I prefer to work with Raspberry Pis when I want to tinker on a random project, consider:

I just spent the past hour with a brand new ArmSoM Sige7 board (see my debugging notes in my sbc-reviews repo). This SBC has been on the market for months, with glowing reviews all the way back in May...

After I saw Pineboards 4K Pi 5 external GPU gaming demo at Maker Faire Hanover, I decided it was time to set up my GPU test rig and see how the Pi OS amdgpu Linux kernel patch is going.

I tested it out on a livestream over the weekend, but I thought I'd document the current state of the patch, how to apply it, and what else is left to do to get full external GPU support on the Raspberry Pi.

I also have a full video up with more demonstrations of the GPU in use, you can watch it below:

At first glance, especially from the top, the Radxa X4 is your typical Arm SBC:

But you'll quickly notice the lack of an SoC—that's on the bottom. Looking more closely, what's a Raspberry Pi chip doing on top?! First, let's flip over the board to investigate. There's the SoC: definitely not Arm inside, this thing's an Intel N100:

I have all my benchmarks and notes bringing up this board stored in my sbc-reviews GitHub repository: Radxa X4 - geerlingguy's sbc-reviews, and I also summarized everything in a video on YouTube, which you can watch inline (or skip past and read this blog post instead):

Since boosting my Pi 5 from the default 2.4 GHz clock to 3.14 GHz on Pi Day, I've wanted to go faster. Especially since many other users have topped my Geekbench scores since then :)

In March, Raspberry Pi introduced new firmware that unlocked frequencies above 3,000 MHz for overclocking. This summer, NUMA Emulation patches boosted performance another 5-10% through memory access optimizations.

But even with a golden sample Pi 5, I haven't seen anybody go much beyond 3.1 or 3.2 GHz. The problem seemed to be power supply—the Pi's firmware limits the SoC to a maximum of 1.000V.

I've been testing a Milk-V Jupiter this week, and have tested a number of other RISC-V development boards over the past two years.

As with any new CPU architecture, software support and ease of adoption are extremely important if you want to reach a wider audience. I wouldn't expect every developer and SBC hobbyist to be able to compile the Linux kernel, and the need to compile much of anything these days is getting rare. So having any instance where one has to know how to tweak a Makefile or pass in different flags to a compiler is a bit of a turn-off for platform adoption.

So one thing I've followed closely is how easy it is for me to get my own software running on RISC-V boards. It's one thing to run some vendor-provided demos. It's another entirely to take my real-world applications and infrastructure apps, and get them to work without hassle.

And to that end, Docker and Ansible, two tools I use extensively for dev/ops work, both run stably—though with plenty of caveats since RISC-V is still so new.

Update - September 26: Today my Dev Kit finally arrived! And of course, the first thing I did was tear it down—check out my teardown photos of the Snapdragon Dev Kit internals here.

Update 2 - October 17: Today Qualcomm cancelled all remaining orders, and will no longer support the Dev Kit.

I signed up to buy a Qualcomm Snapdragon X Dev Kit the second I found out about it. It's supposed to be the Mac mini killer for Windows.

Recently an Igalia engineer posted a NUMA Emulation patch for the Pi 5 to the Linux Kernel mailing list. He said it could improve performance of Geekbench 6 scores up to 6% for single-core, and 18% for multicore.

My testing didn't quite match those numbers, but I did see a significant and consistent performance increase across both Geekbench 6:

And High Performance Linpack:

Ansible runs on Python, and Python runs on... well pretty much everything. Including newer RISC-V machines.

But Ansible has a lot of dependencies, and some of these dependencies have caused frustration from time to time on x86 and Arm (so having issues with a dependency is just a way of life when you enter dependency hell)... but in this case, for the past few months, I've never had luck installing Ansible from PyPI (Python's Package Index) on any RISC-V system, using pip install ansible.

I prefer installing this way (rather than compiling from source or from system packages) because it generally gets the latest version of Ansible, with an easy upgrade/downgrade path. It's also easy to add ansible to a Python requirements.txt file and install it alongside other package dependencies.

Regardless, the cryptography library, which requires a Rust compiler to build if the package is not already built for a particular system, has made it difficult to install Ansible from pip:

Red Hat Enterprise Linux 8 is supported until 2029, and that distribution includes Python 3.6 for system python. Ansible's long been stuck between a rock and a hard place supporting certain modules (especially packaging modules like dnf/yum on RHEL and its derivatives, because the Python bindings for the packaging modules are stuck supporting system Python.

Users are getting errors like:

/bin/sh: /usr/bin/python3: No such file or directory
The module failed to execute correctly, you probably need to set the interpreter.\nSee stdout/stderr for the exact error.

...or...

SyntaxError: future feature annotations is not defined

As ansible-core evolves, they don't want to support old insecure versions of Python forever—Python 3.6 was out of security support back in 2021!.