The Radxa X4

I’ve seen a lot of interest in Radxa’s new X4 over the past few weeks, and since it fits very nicely in between my ongoing quest for efficient ways to run LLMs at the edge (which I’ve been pursuing with ARM devices) and my overall interest in small form factor computing and industrial applications, I reached out to Radxa and got a review unit:

Disclaimer: Radxa supplied me with an X4 and a heatsink free of charge, for which I got an M.2 2230 SSD and a PD charger at my own expense. As usual, this article follows my review policy.

Taking Intel chips and shipping them in the same factor as a Raspberry Pi is not new, but doing it with the Alder Lake N-Series intrigues me–like many, I lost interest in the Pi 5 since the kind of price/performance ratio I wanted just wasn’t there, and there have been two interesting trends that I’ve been tracking and that are pressuring the single-board computer market:

• The emergence of much better MCUs for low-level electronics (like the RP2040 and several new iterations of the ESP32), which have been apparent to hobbyists but are in also taking the industrial and IoT markets by storm.
• The evergreen interest in mini-PCs, which is also apparent to consumers but has been slowly ramping up as some kinds of industrial applications require more on-site compute to handle richer input from sensors and support containerised applications deployed from the cloud.

And since the pandemic, there’s been a steady increase in the number of developers and homelab enthusiasts that are looking for the ability to incubate potentially very complex projects at a small scale–preferably quietly and unobtrusively near their coffee mug.

Given my line of work and some consultancy gigs, I’m someplace in the intersection of that peculiar Venn diagram, and the N100/N97 chipsets are currently quite appealing to me as a counterpoint to the RK3588 family I’ve been delving into.

This is the configuration I got:

• Intel N100 CPU (4 cores, 3.4GHz) with UHD Graphics
• 8GB LPDDR5 RAM
• 2.5Gb Ethernet port (with a PCB connector for a PoE HAT, which is great for industrial environments)
• M.2 2230 NVMe slot (connected to 4 lanes of PCIe 3.0)
• Optional EMMC (mine only has the unpopulated BGA footprint)
• 1xUSB-C PD (that requires 12V)
• 3xUSB-A 3.2 (10Gbps) ports, 1x USB-A 2.0
• WiFi 6 & BT5.2 (I got two little pigtail antennae for that)
• 2x Micro HDMI (up to 4K60)
• 40-pin GPIO header connected to an on-board RP2040
• TTRS jack (headphone and microphone)
• JST connectors for a cooling fan and RTC lock battery (which were both included)

If you’re considering the X4 as a drop-in replacement for a Pi, you’ll be pleased to know that it is basically in the same form factor, with a couple of caveats.

The PCB has a little side bulge to accommodate the GPIO connector, but that is due to the fact that the headers do not use thru holes–they are surface mounted. The rest of the overall layout (connectors, mounting holes, etc.) seems identical to a Pi 4, although I would expect the usual ever so slight variations.

The biggest difference, however, is that the N100, DRAM and SPI flash are mounted under the board–which is a clever way of dealing with cooling, since you get a completely flat plane free of any connectors that might get in the way.

As a thermal solution, I got a hefty heatsink that acts as an open sled-like “case” and comes with a couple of sets of rubber feet:

The heatsink is actually divided into two portions–the heatsink itself and a “sled” that can be removed to allow for more complete cases to be screwed on. This should make it easier to incorporate the X4 into industrial solutions, for instance.

That sled also has 2 holes to mount standard RP-SMA antennae, which is pretty handy. The U.FL pigtails supplied worked fine for me, but if you need better Wi-Fi range and have spare antennae around with the right adapters, things will at least look neat.

However, immediately after assembling the case, I noticed that the thermal pad provided was too thin to make contact between the CPU and the cooler:

So I replaced the thermal pad and sent an e-mail to Radxa regarding this–since as you’ll see later, cooling the CPU is critical in this device, and new users may be put off by the fact that the thermal pad is crumbling and not making contact.

As a final note regarding the heatsink, the one thing that you will immediately notice upon power on is that the fan, besides being exposed and embedded into it, is always on (no PWM, apparently) and very much audible–not terribly noisy, but for someone like me who likes a perfectly quiet office and abhors fans, it’s a stark contrast from all the passively-cooled SBCs I’ve been testing this year.

As you’d expect, the first thing I installed on it was Proxmox–partly because it’s essentially Debian 12, and partly because it makes it trivial to clone or migrate all my existing virtual machines onto it.

I booted it off USB, but as it happens I could just as well have done so using PXE–the BIOS is very comprehensive:

I did not touch the defaults for power management and performance, but intend to go back in later and see what else I can do.

Side Quest: Finding the RP2040

Since the X4 incorporates an RP2040 to handle the GPIO pins I was curious about it, but although the schematic showed it as hanging off the USB bus, I couldn’t see a serial port in Linux–so I started poking at the hardware from the inside:

# lspci
00:00.0 Host bridge: Intel Corporation Device 461c
00:02.0 VGA compatible controller: Intel Corporation Alder Lake-N [UHD Graphics]
00:0a.0 Signal processing controller: Intel Corporation Platform Monitoring Technology (rev 01)
00:0d.0 USB controller: Intel Corporation Device 464e
00:12.0 Serial controller: Intel Corporation Device 54fc
00:14.0 USB controller: Intel Corporation Alder Lake-N PCH USB 3.2 xHCI Host Controller
00:14.2 RAM memory: Intel Corporation Alder Lake-N PCH Shared SRAM
00:16.0 Communication controller: Intel Corporation Alder Lake-N PCH HECI Controller
00:1a.0 SD Host controller: Intel Corporation Device 54c4
00:1c.0 PCI bridge: Intel Corporation Device 54bb
00:1c.6 PCI bridge: Intel Corporation Device 54be
00:1d.0 PCI bridge: Intel Corporation Device 54b0
00:1f.0 ISA bridge: Intel Corporation Alder Lake-N PCH eSPI Controller
00:1f.3 Audio device: Intel Corporation Alder Lake-N PCH High Definition Audio Controller
00:1f.4 SMBus: Intel Corporation Device 54a3
00:1f.5 Serial bus controller: Intel Corporation Device 54a4
01:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8852BE PCIe 802.11ax Wireless Network Controller
02:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
03:00.0 Non-Volatile memory controller: Silicon Motion, Inc. SM2269XT (DRAM-less) NVMe SSD Controller (rev 03)

All the hardware is completely supported by Linux out of the box–but, again, to my surprise the RP2040 didn’t appear as a USB device of any kind:

# lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 13d3:3572 IMC Networks Bluetooth Radio
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

To get it to show up, I had to press the Boot button on the PCB while powering up the X4:

# lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 13d3:3572 IMC Networks Bluetooth Radio
Bus 003 Device 002: ID 2e8a:0003 Raspberry Pi RP2 Boot
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

This also got /dev/sda1 to show up in lsblk, so from then on I could see the RP2040 storage:

# mount /dev/sda1 /mnt
# cd /mnt
# ls -al
total 28
drwxr-xr-x  2 root root 16384 Jan  1  1970 .
drwxr-xr-x 18 root root  4096 Jul 29 14:42 ..
-r-xr-xr-x  1 root root   241 Sep  5  2008 INDEX.HTM
-r-xr-xr-x  1 root root    62 Sep  5  2008 INFO_UF2.TXT

…and install CircuitPython on it:

# wget https://downloads.circuitpython.org/bin/raspberry_pi_pico/en_GB/adafruit-circuitpython-raspberry_pi_pico-en_GB-9.1.1.uf2
--2024-07-31 10:23:45--  https://downloads.circuitpython.org/bin/raspberry_pi_pico/en_GB/adafruit-circuitpython-raspberry_pi_pico-en_GB-9.1.1.uf2
Resolving downloads.circuitpython.org (downloads.circuitpython.org)... 3.160.138.101, 3.160.138.33, 3.160.138.157, ...
Connecting to downloads.circuitpython.org (downloads.circuitpython.org)|3.160.138.101|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1727488 (1.6M) [binary/octet-stream]
Saving to: ‘adafruit-circuitpython-raspberry_pi_pico-en_GB-9.1.1.uf2’

adafruit-circuitpython-raspberry_p 100%[===============================================================>]   1.65M  3.62MB/s    in 0.5s    

2024-07-31 10:23:46 (3.62 MB/s) - ‘adafruit-circuitpython-raspberry_pi_pico-en_GB-9.1.1.uf2’ saved [1727488/1727488]

# ls -al
total 1716
drwxr-xr-x  2 root root   16384 Jan  1  1970 .
drwxr-xr-x 18 root root    4096 Jul 29 14:42 ..
-rwxr-xr-x  1 root root 1727488 Jul 23 00:55 adafruit-circuitpython-raspberry_pi_pico-en_GB-9.1.1.uf2
-r-xr-xr-x  1 root root     241 Sep  5  2008 INDEX.HTM
-r-xr-xr-x  1 root root      62 Sep  5  2008 INFO_UF2.TXT
#  cd ..; umount /mnt

As you’d expect, unmounting the storage device caused the RP2040 to re-attach and activate more USB descriptors:

# dmesg
...
[10740.498783] usb 3-6: USB disconnect, device number 2
[10740.499288] device offline error, dev sda, sector 260 op 0x1:(WRITE) flags 0x100000 phys_seg 1 prio class 2
[10740.499302] Buffer I/O error on dev sda1, logical block 259, lost async page write
[10744.250455] usb 3-6: new full-speed USB device number 4 using xhci_hcd
[10744.400670] usb 3-6: New USB device found, idVendor=239a, idProduct=80f4, bcdDevice= 1.00
[10744.400676] usb 3-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[10744.400678] usb 3-6: Product: Pico
[10744.400679] usb 3-6: Manufacturer: Raspberry Pi
[10744.400680] usb 3-6: SerialNumber: E6632891E325AB2A
[10744.404940] usb-storage 3-6:1.2: USB Mass Storage device detected
[10744.405088] scsi host1: usb-storage 3-6:1.2
[10744.411356] cdc_acm 3-6:1.0: ttyACM0: USB ACM device
[10744.411378] usbcore: registered new interface driver cdc_acm
[10744.411380] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[10744.413002] mc: Linux media interface: v0.10
[10744.414010] hid: raw HID events driver (C) Jiri Kosina
[10744.417232] usbcore: registered new interface driver usbhid
[10744.417236] usbhid: USB HID core driver
[10744.427977] usb 3-6: Quirk or no altest; falling back to MIDI 1.0
[10744.428567] usbcore: registered new interface driver snd-usb-audio
[10744.431423] input: Raspberry Pi Pico Keyboard as /devices/pci0000:00/0000:00:14.0/usb3/3-6/3-6:1.3/0003:239A:80F4.0001/input/input11
[10744.490640] input: Raspberry Pi Pico Mouse as /devices/pci0000:00/0000:00:14.0/usb3/3-6/3-6:1.3/0003:239A:80F4.0001/input/input12
[10744.490827] hid-generic 0003:239A:80F4.0001: input,hidraw0: USB HID v1.11 Keyboard [Raspberry Pi Pico] on usb-0000:00:14.0-6/input3
[10744.644854] FAT-fs (sda1): unable to read boot sector to mark fs as dirty
[10745.431312] scsi 1:0:0:0: Direct-Access     Raspberr Pico             1.0  PQ: 0 ANSI: 2
[10745.431580] sd 1:0:0:0: Attached scsi generic sg0 type 0
[10745.432163] sd 1:0:0:0: [sda] 2049 512-byte logical blocks: (1.05 MB/1.00 MiB)
[10745.432571] sd 1:0:0:0: [sda] Write Protect is off
[10745.432574] sd 1:0:0:0: [sda] Mode Sense: 03 00 00 00
[10745.433010] sd 1:0:0:0: [sda] No Caching mode page found
[10745.433013] sd 1:0:0:0: [sda] Assuming drive cache: write through
[10745.440503]  sda: sda1
[10745.440762] sd 1:0:0:0: [sda] Attached SCSI removable disk

A fun thing to note here is that you can most certainly use the RP2040 to automate the host via keyboard/mouse HID emulation–which is kind of a plot twist.

With CircuitPython installed, programming the GPIOs for simple applications should just a matter of editing code.py (or using the now active serial console):

# mount /dev/sda1 /mnt
# cd /mnt
# ls -al
total 23
drwxr-xr-x  5 root root 16384 Jan  1  1970 .
drwxr-xr-x 18 root root  4096 Jul 29 14:42 ..
-rwxr-xr-x  1 root root   125 Jan  1  2020 boot_out.txt
-rwxr-xr-x  1 root root    22 Jan  1  2020 code.py
drwxr-xr-x  2 root root   512 Jan  1  2020 .fseventsd
drwxr-xr-x  2 root root   512 Jan  1  2020 lib
-rwxr-xr-x  1 root root     0 Jan  1  2020 .metadata_never_index
drwxr-xr-x  2 root root   512 Jan  1  2020 sd
-rwxr-xr-x  1 root root     0 Jan  1  2020 settings.toml
-rwxr-xr-x  1 root root     0 Jan  1  2020 .Trash-1000
-rwxr-xr-x  1 root root     0 Jan  1  2020 .Trashes

Of course, there are a few caveats here: the first is that I used the standard Raspberry Pi Pico image, because that is one of the boards with the most exposed GPIO pins–I haven’t yet checked what is exposed via the 40-pin interface and if the pin definitions inside the CircuitPython image match, so I expect that there might be some minor differences worth building a custom image for.

The second caveat is that the host CPU cannot access the GPIOs directly, ever, by design. So the direct access you get under something like a Pi or a Luckfox mini is not possible, and your electronics applications will need to use the RP2040 as an intermediary, and talk to it either via the UART (which can be slow or via any custom protocols you can)

Here’s the way I think about it from the perspective of writing actual industrial applications–one of the key differentiators of the RP2040 (and the reason why it can pull stunts like bit-banging HDMI/DVI video) is its 2 PIO blocks, which can operate independently of the MCU itself.

And realistically, if you’re doing anything that resembles signal processing or intensive I/O, you’re quite likely going to be relying on it to some degree, with the RP2040’s CPU used for aggregation and buffering of data to and from to the host as needed:

Either through the USB bus or serial port, there shouldn’t be any bandwidth constraints in this setup, which is pretty flexible–the flip side is that if you’re just trying to blink an LED from your desktop app, then you have to write code to talk to the RP2040 and code for it to actually blink the LED.

I don’t really see that as a problem since it enforces separation of concerns and frees up the host CPU, but it’s something to keep in mind.

I measured power consumption both at the wall via a Zigbee-enabled socket and a fancy USB cable, and while idling in Proxmox, the cable reported 6.5W, to which the power adapter adds 1.3W. I’m only going to mention cable readings from this point on, since the adapter is a constant.

When running ollama at full tilt, the cable reported an average of 18.5W, which is twice what my last RK3588 board topped at and perfectly congruent with the (also N100-powered) GMKtec G2 draws.

As usual, I ran ollama on it (doing CPU inference only), and the results were good (50% better than an RK3588), but not stellar:

for run in {1..10}; do echo "Why is the sky blue?" | ollama run tinyllama --verbose 2>&1 >/dev/null | grep "eval rate:" | grep -v prompt; done | awk '{total+=$3;count++} END {print total/count}'

This isn’t a race, and the GMKtec G2 has different cooling and (almost certainly) different power management settings, so I’m not going to draw any conclusions from this–but it’s a good baseline to have.

Also, it’s a great segue into examining cooling and thermals.

Update: two months later, I replaced the thermal pad with a copper shim and some thermal paste, and the results were much better than the below–I got a 15°C drop in idle temperatures and a massive 48°C drop under load, so check that post for a summary.

As you’d expect, the X4 just works with lm-sensors:

# sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +45.0°C  (high = +105.0°C, crit = +105.0°C)
Core 0:        +44.0°C  (high = +105.0°C, crit = +105.0°C)
Core 1:        +44.0°C  (high = +105.0°C, crit = +105.0°C)
Core 2:        +44.0°C  (high = +105.0°C, crit = +105.0°C)
Core 3:        +44.0°C  (high = +105.0°C, crit = +105.0°C)

acpitz-acpi-0
Adapter: ACPI interface
temp1:        +27.8°C  (crit = +110.0°C)

nvme-pci-0300
Adapter: PCI adapter
Composite:    +52.9°C  (low  = -273.1°C, high = +85.8°C)
                       (crit = +92.8°C)
Sensor 1:     +52.9°C  (low  = -273.1°C, high = +65261.8°C)
Sensor 2:     +57.9°C  (low  = -273.1°C, high = +65261.8°C)

So it was pretty trivial to set up a script to gather some data during a ollama run:

#!/bin/bash
echo "timestamp mhz degrees" >> data.tsv
while true; do
  MHZ=$(cat /proc/cpuinfo | grep MHz | awk '{mhz+=$4} END {print mhz/4}')
  TEMP=$(cat /sys/class/thermal/thermal_zone1/temp | awk '{print $1/1000}')
  echo "$MHZ $TEMP" | ts "%s" >> data.tsv
  sleep 1
done

And the results were quite interesting:

The temperature drop after ~20 seconds was consistent with a drop in power consumption (from almost 19W to 16W as I watched the USB cable), so I assumed that the CPU was throttling–and the average MHz chart sort of confirms that, but it was quite noisy:

And yet, eyeballing individual core speeds with watch pretty much confirmed the chart above–the N100 is very prone to jumping from 700MHz to over 2GHz and back again, a behavior that is sure to be tunable.

However, the main conclusion here is that the X4 heatsink is both essential and quite adequate–the CPU temperature drop was pretty much immediate, even if the heatsink itself remained very hot to the touch for a little longer.

As usual, I also ran fio on the SSD I got, but mostly to check PCIe performance:

fio --filename=/tmp/file --size=5GB --direct=1 --rw=randrw --bs=64k --ioengine=libaio --iodepth=64 --runtime=120 --numjobs=4 --time_based --group_reporting --name=random-read-write --eta-newline=1

One thing I should note is that the closest match I have to the X4 is the GMKtec G2, which is not listed since it comes with a SATA SSD and Windows–so I didn’t do any storage benchmarking (it just wouldn’t be comparable).

And given that I’ve been getting different SSDs (2280, 2242 and now 2230, all from different manufacturers), the results above should always be taken with a grain of salt–still, the X4 did beat every other SBC I’ve tested so far.

I didn’t do any extensive networking performance testing (yet–I’m actually testing new LAN switches in parallel), but both 2.5Gb Ethernet and 5GHz Wi-Fi worked without any hitches and close to the limits of what I have available (I only have 802.11n access points, not 802.11ax, and stress testing this kind of thing is not trivial).

As a way to test the X4 during the evenings, I migrated my Plex stack from my Beelink U59 to it (a trivial thing to do with Proxmox)–and, like the N5105, the N100’s QuickSync transcoding just worked, with zero issues.

As an additional impromptu test, I also migrated one of my GPU-accelerated RDP containers to it (the one running xorgxrdp-egfx), with an XFCE desktop and the Platinum theme, and the X4 was able to run Blender and OpenSCAD (viewing and rotating models mostly–I wouldn’t use it for rendering) quite nicely, with interaction speeds pretty much indistinguishable from the aging i7 that image was previously hosted on:

I was able to do this with zero hassle for a couple of reasons:

• I run most of my homelab stack inside LXC containers (even the ones running Docker) or KVM instances
• Proxmox lets me migrate LXC containers and KVM instances between hosts with a couple of clicks

Plus, of course, all of the usual faffing about with mapping /dev/dri and similar devices inside containers are solved problems in Intel CPUs.

For a sort of grand finale, I also cloned a small Windows 11 VM I use for testing (whenever I have some suspicious files to deal with, I drop them in there, access it via RDP and revert to a previous snapshot) and ran it on the X4–and it worked fine set to use only 4GB RAM, with good responsiveness after the usual Windows Update catch-up dance.

But this is a bit of an outlier–8GB is a bit tight for any useful number of Windows VMs, although you can go a long way with Linux VMs and containers in even half that much RAM (like many of my Pis, for instance).

This post is already quite long (and a second part is sure to come), but there are already some inescapable conclusions–the first of which is that the X4 is a very interesting machine that upends a lot of the expectations toward single-board computers:

• You can install any operating system trivially (like on a normal PC) without messing with flashing utilities etc.
• You don’t have to use any weird unmaintained Linux kernel forks
• Even if you prefer ARM, Intel architecture binaries are still easier to come by for most applications
• The Intel chipset brings with it many features ARM chips still cannot really match in performance and support (like QuickSync video transcoding and non-mobile GPU acceleration)
• The use of an RP2040 lets you tap into the Arduino or embedded Python ecosystems with minimal hassle

With SBCs becoming increasingly more powerful, all of a sudden an N100 is still both low power enough to be a good choice for a homelab server and powerful enough to run a full desktop environment–and the X4 is a very good example of that. So if you want to have a tiny machine to run your homelab (with a couple of VMs and a few dozen containers) and perhaps set up a lightweight desktop environment on it for occasional tinkering, this seems like a good choice.

The only immediate disadvantage I can see is the need for a bit more sizable cooling than usual–and a somewhat noticeable, always on fan.

But given the vagaries in retail, shipping costs, etc., I would recommend doing your own price comparisons, since you will need a PSU, a micro-HDMI cable and the heatsink, and that will add to the cost and bring it closer to other mini-PCs that ship with everything in the box.

An interesting tidbit I found as I was revising this is that Radxa is committing to make the X4 available until at least September 2032, which is the kind of detail that people look for when selecting reference platforms for industry.

Again, this isn’t the first time people have tried to ship SBCs with Intel CPUs in a Raspberry Pi form factor, but it’s the first time I’ve seen it done “right”–this will make a very long-lived, killer board for industrial applications, point-of-sale terminals, and all sorts of thin clients (where the ability to run Windows will be key).

Most scenarios would probably also be able to run off an on-board EMMC.

This is an SBC, so there’s always a certain amount of DIY involved. Still, I’d like to see a little notch in the heatsink to guide the fan cable into the case in such a way that it would be easier to design an end cap, and a good way to stick the RTC battery to the board someplace (I just wedged it between the USB ports).

I’d love to see single cable operation–i.e., using the USB PD port as a video output. I get that the circuitry to do that would add to the cost, but the hassle of hunting around for micro-HDMI cables was something I had completely forgotten about, so I had to mention it.

I’d also like to see an N97 version–just because it can clock higher and has a better GPU, but I’m not sure if it would work well with the current cooling solution. Although there are no higher RAM SKUs for sale right now, going beyond 8GB seems like a no-brainer.

I will soon be trying Windows on bare metal on mine–I expect no surprises, and I’m pretty sure it’s going to perform just as well as the GMKtec G2. So right now my plan is to switch them around–i.e., use the X4 as my electronics bench PC (where the GPIO pins may come in quite handy) and turn the G2 into a Proxmox node.

Hardware-wise, I might also have a go at testing Power over Ethernet (if I get the HAT for it), since that is a feature that is quite useful in industrial settings and I have a couple of switches that can deliver it.