Although I’ve spent many years looking at SBCs, so far nearly all of them have been ARM-based, and this is the first time I’ve had a proper look at a RISC-V system.
And this one is both quite usable and remarkably compact:
The Orange Pi RV2
Disclaimer:OrangePi sent me an RV2 evaluation board and a 64GB eMMC free of charge (for which I thank them), and this article follows my review policy.
RISC-V is heralded by many as “the next big thing” since it is an open and royalty-free ISA, but it has been a sort of red-haired stepchild for a long time, in the sense that it has always been much slower and gotten less overall industry support than ARM.
However, things have been changing over recent years. The original emphasis on low-power, low-end devices has been shifting towards beefier SoCs as companies like Ventana Micro Systems and SiFive started working on high-performance RISC-V processors, and countries like China, India, and even the EU are investing heavily in RISC-V to reduce reliance on proprietary architectures.
And given the current geopolitical situation, well… RISC-V might come to enjoy even more popularity. So even though OrangePi reached out way before the US tariff wars began, I can’t help but feel it was timely.
The review unit I got came with a very nice and compact USB-C GaN charger (rated at 5V/5A) and has the following specs:
8-core Ky X1 64-bit RISC-V CPU, with 2 TOPS NPU
4 GB of LPDDR4 RAM
MicroSD (TF) Card Slot
A bottom eMMC socket (I also received a 64GB eMMC module for that, which was very useful)
2 PCIe 2.0 M.2 M-keyed slots, one on top that you can use for (short) NVMe SSDs (but that you can’t boot from) and a full-sized one on the bottom (which you can indeed boot from)
HDMI 1.4 (1080p@60), and a MIPI DSI port for display
An onboard Wi-Fi 5 + BT 5.0/BLE AP6256 module that connects to the system via SDIO3.0 (this will be relevant later)
3.5mm audio input/output jack
3 USB 3.0 host ports + 1 USB 2.0 that can do either device or host mode and an extra-4-pin USB header on the PCB, next to a 3-pin header for a UART (which is a nice touch compared to some of the proprietary setups I’ve had to deal with recently)
And, of course, a 26-pin GPIO port and a usual amount of MIPI/CSI connectors.
The RV2 is passively cooled, and one of the first things I noticed was that it gets noticeably warm to the touch when under load.
Placing a small copper heatsink on the Ky X1 dropped the idle temperature from 58oC to 49oC, so I would definitely advise you to do the same if you get one.
Under 100% load across all 8 cores and with the heatsink, I got up to 64oC over around 30m of heat soaking without any throttling, which is good for a passively cooled system–and I didn’t notice any throttling during my tests with this setup.
The RV2 spent most of its time idling at 3W, which is… OK but feels like it could be lower given that it is on par with the lowest values I got for RK3588 boards (which are much more powerful).
On the plus side, I couldn’t get it to go past 5.2W under maximum CPU load (generated by a little Go program that hogged all cores), so I’d say it is reasonably low-power (although, as we’ll see later, you are not getting a lot of performance per watt).
Installing it was trivial–I just flashed the image to a Micro-SD card and it booted, and I then used orangepi-config to copy it to eMMC. Orange Pi’s documentation is quite good, and the process was straightforward.
I also flashed it (later) to an NVMe drive connected to my laptop via USB and it just worked, which is a much nicer experience than dealing with Rockchip’s Windows flashing utilities.
The GNOME desktop experience on the [RV2] is quite smooth
The Ubuntu desktop image “just worked”, too, including, impressively, smooth animations in GNOME, working video playback (both via VLC and the browser), and a Chromium build that reported fairly good hardware acceleration–compositing, WebGL, and video decoding are all hardware-backed, which is more than I expected from RISC-V at this point, although like on RK3588 systems, there’s no real way to use the GPU via RDP or other more exotic means I’m used to on other devices.
There is a lot of additional software available (including a set of third-party software options available via orangepi-config), and I found it interesting to see that there are RISC-V builds of Plex as part of the software selection:
The main `orangepi-config` options
So I’d say that if you want a desktop experience, the basics are commendably workable on RISC-V already.
But since my board only came with 4GB of RAM, the experience wasn’t the best (it took around a full minute to boot from the eMMC and felt a little laggy). The lack of RAM felt a little unfair to the rest of the hardware, so I decided to install the server version for most of my testing.
Considering it runs kernel 6.6.63 (on Ubuntu) and has ample CPU performance when compared to most home gateways, it seems like a great board for building a gigabit router with stateful firewall capabilities–so I installed OpenWRT on it, this time using what I lovingly refer to as my “cursed eMMC adapter”:
Despite the looks, it works just fine
Like the Ubuntu image, the OpenWRT one is also very complete - even Docker is installed, as well as a lot of useful networking utilities, including mwan3 for multi-WAN setups (which I actually have been looking at lately).
Logging in from a Linux client
However, Wi-Fi wasn’t working for me in the OpenWRT image:
I did a little investigation and it seems that the current OpenWRT image is missing the dhd kernel module that is present in Ubuntu, and possibly other parts of the SDIO stack:
I suppose that other bits of the stack might be missing as well, but iw and the usual tooling is present, so this might just be an oversight since OpenWRT is supposed to do wireless…
I’ve reached out to OrangePi regarding this since the RV2 is pretty much the perfect size for a travel router, and even if the SDIO Wi-Fi isn’t amazingly performant it does work well enough for that–I’ll update this post when I hear back from them.
This is, of course, the elephant in the room. RISC-V has long had a stigma of lower performance and higher power consumption when compared to ARM CPUs, but we’re now at a point where people are developing x86 emulators, and considering the Ky X1 has 8 cores I had high expectations.
As it happens, I had a bit of a challenge getting sbc-bench to work, since calibration is finicky and even the server image produced “system too busy” warnings. The current git version failed to build cpuminer and the bundled version that OrangePi provides is too old, so I decided not to use the results.
Regarding I/O, and considering the machine only has PCIe 2.0, using the eMMC or NVMe was, as expected, slower than on previous boards I tested–but I actually don’t think that is a problem given that a few years ago, you couldn’t even think of having a system like this.
Regarding AI, ollama isn’t supported on RISC-V and my board had only 4GB of RAM, so jumping through the hoops of installing ky-ort only to be unable to run useful models wasn’t an option.
So to get a better feel for the system I tried running some of my own apps and services (network and IoT services written in Python and Go), and although speed was more than adequate for development and testing, I got the best overall performance in things that exploited multi-core parallelism, in which the Ky X1 could leverage its 8 cores to good effect.
However, since my own numbers are meaningless for actual data I will direct you to Phoronix’s excellent benchmark post, which pegs the RV2 at about half the performance of a Raspberry Pi 4–which is about what it felt like when I ran my things on it:
Phoronix's geometric mean of all their benchmarks
But, as you can see from Michael’s results, the RV2 seems to be almost twice as fast as older RISC-V platforms.
Network performance was one aspect I could test thoroughly. The RV2 can do wire-speed routing at around 941Mbps across both built-in wired interfaces, works well with the USB 3.2 WP-UT5 5GbE adapter I recently tested, and was almost able to saturate the Wi-Fi connection at 5GHz, although it is bottlenecked by the SDIO interface and figures will always vary based on your access point.
I want to like the RV2–it is, after all, a good RISC-V board for me to experiment with, and (considering what I have learned about previous generations), I think it is also a good starting point for getting into what is the only interesting alternative ISA right now.
While I can’t wholeheartedly justify the Orange Pi RV2 purely on a performance-per-dollar basis when compared to the vast array of more performant ARM-based SBC currently available or even against the increasingly affordable low-end N-series Intel machines that are driving down prices in the mini-PC market, it carves out a different kind of value.
As a way to dip a toe into the waters of RISC-V, it’s actually a remarkably competent and accessible board. It’s easy to forget what the original Raspberry Pi was when it first launched; yet, look how far it’s come.
The RV2 feels like it’s at a similar inflection point for RISC-V, and as a “first” RISC-V machine, I can’t really fault it.
Tack on an NVMe, and the RV2 can act as a build/CI server for other RISC-V targets (Go builds in particular work perfectly fine and, as usual, are much less hassle than anything else), and I’m very curious to see if something like Haiku or Plan9 can be made to run on it.
But what I most liked was the smoothness of installing software on a completely “new” architecture for me. Given that RISC-V is (at least on paper) free of the encumbrances of ARM and proprietary hardware and that flashing new images is trivial and requires no special software, this is likely to be my go-to tinkering board for testing those claims…
May 10th 2025 · 3 min read
·
#3dprinting
#coding
#notes
#power
#solar
This was a bit of an eventful week–at work and otherwise. I seem to be energized by constant context switching, so a peak of project work actually resulted in me needing to “relax” more thoroughly and do a lot more hobby stuff than usual at the expense of sleep (I’ve slept an average of 6h/night over the past month…)
I have a couple of portable 30W solar panels that were put to good use during the recent blackout, so of course I went and ordered another (60W) one, taking advantage of the fact that modern panels have USB-C PD support, which is handy to charge some devices a bit more efficiently (like this 145W/25000mAh one, which can charge a MacBook Pro from zero to full and still have ~30% capacity to spare).
I’ve been playing around with various combinations and I can charge a bunch of stuff throughout the day–mostly for science and understanding of limitations, but also because it’s a fun thing to do even though it doesn’t really add up to meaningful savings.
But since I found myself using that powerbank for charging stuff away from an outlet more than a few times now, I am strongly considering getting another one and making a little game out of seeing how far I can go with regularly charging things from solar only over Summer.
However, I managed to break off the rubber port cover of the new solar panel while testing it, so I went and designed myself a new one–and actually improved the fit a bit, since the DC port wasn’t plugged in the original:
I wish I could do this more often, really
The end result is pretty decent, if you’ll excuse the usual TPU stringing (which I later removed with a hot gun):
I’ve been using GitHub Copilot extensively over the past month and found it has improved massively, so after some experimentation I’ve settled on a workflow that is quite productive (and will write a separate note about).
I had a hand at doing several things, some of which were spurred by my desire to have better free CAD software with parametric design (and no, please don’t talk to me about FreeCAD, I abhor its UX, and yes, I keep trying it every release):
Miguel de Icaza’s tour de force in Swift development (that I have had the priviledge of beta testing, albeit not as consistently as I would like) is now on the App Store.
Xogot brings a full-fledged Godot game development environment to the iPad, and it is very slick indeed. The bundled projects give a good idea of what you can achieve, and it has lots of thoughtful creature comforts.
There’s a dry appeal to watching a traditionally desktop-oriented engine make the jump to mobile (and yes, the notion of building and running games on the same iOS device is intriguing, and pretty much unique, but Godot has been working on Android for years).
This is an amazing technical achievement on all counts, and yes, it proves that you can pack professional-grade tools into a mobile experience, even if Apple doesn’t really want you to and some of the desktop workflows feel a bit alien on an iPad.
Imagine (again) if Apple actually let us do more.
May 6th 2025 · 1 min read
·
#arm
#microsoft
#qualcomm
#surface
#tablet
#usb-c
This is one of those times when I must say it is very frustrating that Apple not only killed the 12” MacBook but also refuses to make the iPad a more generally useful device (and I’m actually typing this on an 11” model, just after putting away a comparably-sized Linux laptop I am reviewing).
The new Surface Pro 12-inch goes all-in on USB-C, keeps (but downsizes) the keyboard design and promises about 12 hours of battery life thanks to Qualcomm’s Snapdragon X Plus chip. It also seems reasonably priced at $799. I have been considering getting an ARM machine as part of my next corporate refresh, and I hope this one is on the roster.
I can’t wait until Apple comes to their senses on either of the above, though.
May 3rd 2025 · 3 min read
·
#automation
#docker
#home
#homebridge
#homekit
#mqtt
#node-red
#proxmox
#zigbee
This weekend, I finally migrated my home automation setup off the Raspberry Pi 4 it’s been running on for the last four years and into an LXC container managed by Proxmox on my Beelink U59 Pro.
I’ve been meaning to do this for a while, and things finally fell into place yesterday when I had a bit of time to spare.
It’s mostly about consolidation and cleanup, since I now have one less power plug and Ethernet port in use on my server closet.
Being able to backup everything consistently and migrate the setup to any machine I want (as long as it has an USB port for my Zigbee coordinator) is just icing on the cake.
Although HomeKit hasn’t really improved substantially over the past few years (in fact, the Home app has only gotten worse, and most of my unscheduled interactions are via Siri), homebridge and zigbee2mqtt satisfy my relatively simple needs for home automation rather well.
I’ve written about that at length over the years, so the list above should give you a good idea of the finer points of my setup.
But, in short, everything operates 99% on the LAN (with no devices calling home to anyone or relying on outside services to work) while allowing me to do the occasional remote action securely without any new software on our phones, and I quite like it that way.
I also wanted to do a general cleanup of the whole thing from scratch, including renaming all my accessories using a slightly different convention (including renaming them directly in zigbee2mqtt to make sure names are consistent throughout the stack) and removing redundant accessories, since (for instance) I no longer have the need to have as many temperature sensors around the house now that all my heatpumps have been HomeKit-enabled by the addition of ESP32 modules.
Finally, I was having some trouble keeping things up to date, mostly due to JavaScript packaging vagaries. Every update I wanted to make eventually led to me having to either upgrade NodeJS or fiddle with the latest fashion in package management, so it was time to go back to a Docker-based setup for consistency with the rest of what I’m running–although I am not doing automated updates for this stack.
Why both homebridge and zigbee2mqtt don’t have sensible alternatives written in something like Go I have no idea. Even Java would have been better.
Created an LXC container on u59 with the original hostname and made sure my router updated its local DNS (after some finagling with DHCP), so that the Tasmota devices could connect immediately.
Configured Proxmox to pass through the USB device for my Zigbee controller.
Wrote up a docker-compose.yaml file to set up homebridge, zigbee2mqtt, mosquitto and node-red.
Restored the config for each in turn, doing minor tweaks as needed.
Renamed all my Zigbee devices (this makes it easier to manage things on the Home app when HomeKit throws a fit).
Set up piku to manage some MQTT microservices like the plex-listener that powers my “now playing” display and my homelab homepage (which is now a variant of this little dashboard/homepage I hacked a while back).
Set up backups (both of the complete LXC filesystem and git versioning of the configurations)
Started cleaning up old Node-RED flows, removing redundant accessories, etc.
The current filesystem layout is pretty straightforward:
Right now I’m still removing redundant devices, as well as planning replacing some Tasmota plugs with Zigbee equivalents to improve the mesh coverage.
Another thing I will be doing is replacing some Node-RED flows that do metric logging and MQTT transformations with Python microservices.
I no longer have a need to tweak them, so their behavior can be frozen and any changes better versioned in git (Node-RED does support git, but it’s just messy to do some things that way).
May 3rd 2025 · 1 min read
·
#apple
#appstore
#epic
#eu
#guidelines
#policy
#scrooge
#us
Apple’s revised guidelines following the Epic Games ruling are… not a good look, and I hope the E.U. doubles down on this to force them to do the right thing and change the rules “globally”.
The updated rules allow apps on the U.S. storefront to include external links and calls to action without the previous restrictions (sections 3.1.1 and 3.1.3 give a clear green light). But Apple’s insistence on debating what a button is and going out of their way to hold on to their payment fees (instead of acknowledging that the fees could simply be lowered to a point where sheer convenience would ensure developer adoption of their payment system) feels too miserly to dwell upon.
To me, their arguments for developer fees (especially the $99 tax for being able to permanently install builds on your own devices) have always seemed borderline evil, and given their scale and operating margins there is just no excuse for not being fairer about the whole thing.
After all, developers are the ones giving their store real value, and whatever “value” or costs that Apple incurs by maintaining the storefront (which should be stupefyingly efficient from an engineering perspective by now) and App Review (which is still a mystery box of random outcomes) is likely to be much smaller than, say, cutting their fees in half or even waiving them for small volumes of sales.
But Tim Cook’s Apple runs on tallying nicklels and dimes.
It’s been two years now since I got myself one of the first iterations of the Kingroon KP3S Pro, so I thought I’d post a sort of cursory long-term review of what it’s been like to use it.
This one deserves a link to my disclaimer, even though it is quite obviously way above my pay grade.
I do find it positive in the sense that it is a step towards a more resilient and privacy-focused digital landscape in Europe, but I also have to wonder about the implications of such commitments in the context of the ongoing geopolitical tensions and the need for data sovereignty–in short, we’ve been discussing the lack of an European cloud for decades in my closest circles both inside and outside work, and something like this was a long time coming.
Like I pointed out in various (public) places, hosters are not hyperscalers, and being able to spin up a VM on European soil is not the same as having a full-fledged cloud provider with all the bells and whistles. The fact that my current employer is committing to a 40% increase in datacenter capacity in Europe, along with the establishment of sovereign cloud options in France and Germany, is a pretty positive sign that they are taking the needs of European customers seriously even if they weren’t signing my paycheck.
The bit that might come in under the radar, though, is the one I find the most interesting myself: setting up legal mechanisms to contest any government edict that might disrupt cloud operations.
Given the current worldwide situation, it’s a pretty strong statement on the US side, and acknowledgement that digital systems are not immune to geopolitical fickleness.
Well, this was a fun day. Nothing like having to climb up and down seven flights of stairs in pitch dark a few times and keeping yourself entertained with a hand-crank FM radio, portable solar panels and a Kindle.
Mobile networks saturated quickly and went out after a few hours (around five, short of the eight I expected), power took around nine hours to be restored and fiber service is still mostly out, so tomorrow is going to be an interesting day as I try to bring my homelab back online (but at least the Portuguese grid can still be self-sufficient, even if they had to do a black start).
Still no root cause, though, other than the obvious fact that the Spanish grid went unstable and took out ours (because it’s cheaper for us to import their power, and because European power grids tend to be interlinked).
Hot on my rant about Siri on the HomePod Mini, this lays out how, by simply using native Apple APIs like EventKit, MapKit, and Mail’s native compose sheet, Perplexity manages to make conversation with an assistant a practical—if not sometimes quirky—experience. I found it amusing that queries like “play the song that was playing in The O.C. when Seth Cohen was wearing a Spider-Man mask” got a correct response on Perplexity, whereas Siri (even with its ChatGPT integration) was hopeless. Sure enough, Federico notes, “Siri is producing absolute junk while Perplexity is being genuinely useful.”
The piece is worth a look because it isn’t just hype—it carefully points out real limitations (like issues with reminders and the absence of HomeKit control) while hinting at a future where integrations may become the norm rather than the exception. The detailed back and forth shows a thoughtful interaction with AI that should have been within Apple’s ability to deliver rather than bombarding us with vaporware bells and whistles.
It’s a sober reminder that innovation often comes from practical tweaks rather than revolutionary new tricks, and I have to wonder how many more people are doing it better than Apple right now.
Since Alexa has changed the way it handles voice recordings and I don’t feel comfortable with their privacy disclaimers, I decided to retire the Echo Dot I have been using for years in my office and replace it with a HomePod Mini.
I have been mostly in “inbox zero” mode for the past few weeks, which generally meant checking stuff off my to-do list, trying to ignore the news, and using some fairly colorful language when I didn’t.
Pete Koomen’s essay takes aim at the current crop of AI apps by comparing them to “horseless carriages” – a neat metaphor for tools that lean too heavily on outdated thinking.
He points out that Gmail’s AI email draft generator misses the mark by forcing a one-size-fits-all tone and then, for an encore, he goes and does an almost perfect common sense prototype that puts a lot more control in the hands of the user.
Letting people customize behavior rather than defaulting to slop is definitely a much better way to use AI, and I’d be here for it if people were actually doing it.
The Synology software makes it dead easy to have encrypted cloud backups to Azure and mirror both my Dropbox and OneDrive contents locally, and those are just two of the features I have relied on over the years–many other people use a lot more of their core software, and pretty much everyone I know has a Plus model.
The TerraMaster F4-424 MAX, for instance, doesn’t do all of those things out of the box, and going custom would be a major pain even for me as I’m just running Proxmox and a bespoke Samba server there, treating it as a dedicated VM and media server. But maybe I should start hedging my bets…
I haven’t written about 3D printing in a while, but I have both kept at it and actually doing a bit of market research–I’ve been considering either building an MMU or getting a multi-material printer, but I haven’t made up my mind yet, and the tariff war isn’t helping.
It’s been a little while since I last looked at regular mini-PCs, and considering that the market is flooded with cheap Intel N100 and N150 variants, you would think there isn’t a lot of diversity in the EUR 200 range.
I’ve spent the past couple of days watching the tariffs fracas unfolding, and with China’s fresh hiking of truly “reciprocal” tariffs to 34%, things are not looking good at all–but Apple is in a pretty serious bind here, since there are newscasters projecting their phones might become over 40% more expensive in the US, with Chinese restrictions likely harming their sales in China as well.
Tim Cook’s going to have to pull a pretty stressful balancing act on the tariff high-wire as it stretches taut on both directions…
As much as I strive to avoid doomscrolling, the overall feeling here in Europe is not positive. The circus-like political statements, the lack of basic competence in either SIGINT handling or even basic math (the “reciprocal” values look more and more like they were done either on a napkin or using AI without the benefit of natural intelligence), the loss of confidence in a major power that we used to see as ally and the immediate impact on the economy are a tad overwhelming.
The chorus of informed consent that is surfacing around the real consequences that have yet to come, as depicted in this week’s edition of the Economist (in this and other articles I’ve just started reading) are all things I’m actively trying to both ignore and mitigate–although there is very little I can do regarding the latter.
But with the DOW falling 2.000 points and most tech stocks dipping at least 5%, this is already at least as bad as the economic impact of COVID, with the main difference that this is by design. We’re well into the “chaotic evil” quadrant of economic policy.
I’m sick with a sore throat, so I missed the celebrations at the local office.
Having witnessed most of this (40 years of it second-hand as I grew up, and the last 10 directly involved as my hair turns a definite grey), I have mixed feelings–for instance, I don’t have a lot of nostalgia for the the early days of DOS and Windows (or the earlier days of CP/M, which are barely hinted at).
It might be because I ran Windows 2.0 on my first Schneider-branded 286 PC and spent a lot of time putting together new machines during college until I was blown away by how much better the Mac user experience was, but it’s most likely because the latter decade has been a roller coaster.
Still, a lot of the anniversary gallery is fun to peruse. Like with all work things it’s kind of amusing to do so from an outside perspective when you know how the AI sausage is made.
But as far as future prospects are concerned, there is a lot of substance to Microsoft’s approach that allows me to ignore all the hype and hope for the best.
Let’s see how things go from here.
Mar 28th 2025 · 1 min read
·
#apple
#development
#ios
#macos
#sequoia
#snowleopard
#software
#ui
Although there are a few innacuracies here (Snow Leopard was not that much of an improvement, more of a freebie and a way to level set), it can’t be argued that today’s MacOS Sequoia and iOS/iPadOS 18 feel like products patched together by engineers who may not actually use the software they build.
From Messages’ erratic copy/paste behavior and bloated background processes to the counterintuitive UI changes in System Settings (goodbye, easy drag-and-drop display rearrangement), it’s clear that Apple is slipping, and the number of people who replied to me in the Hacker News thread (yeah, I know, HN is kind of a weird place for Apple folk right now) to echo my complaints about Spotlight’s erratic behavior in Sequoia is staggering.
The whole situation shines a… Spotlight (ha!) into frustrations about a platform that seems to become more and more brittle to the point of actively neglecting the basics it rose to prominence on.
Yes, there will always be a bit of rose-tinted longing for the methodical, almost surgical improvements of the Jobs era. But I honestly have no idea how Apple can keep pushing AI features without cleaning house, and whatever they’re doing in the platform teams just isn’t working.
Mar 26th 2025 · 1 min read
·
#apple
#dasher
#lumon
#mac
#severance
#terminal
#tv
#unix
Having loved Severance Season 2 and its amazing marketing campaign (which includes a Lumon presence on LinkedIn and other strokes of genius), I have to say that I actually wish Apple would sell something like this.
I’ve been playing with Anthropic’s MCP for a little while now, and I have a few gripes. I understand it is undergoing a kind of Cambrian explosion right now, but I am not very impressed with it. Maybe it’s echoes of TRON, but I can’t bring myself to like it.
Rui Carmo
