I think everyone considering an SBC should be warned that none of these are going to be supported by upstream in the way a cheap Intel or AMD desktop will be.
Even the Raspberry Pi 5, one of the most well supported of the SBCs, is still getting trickles of mainline support.
The trend of buying SBCs for general purpose compute is declining, thankfully, as more people come to realize that these are not the best options for general purpose computing.
Were people actually doing that?
If the RPI came with any recent mid-tier Snapdragon SOC, it might be interesting. Or if someone made a Linux distro that supports all devices on one of the Snapdragon X Elite laptops, that would be interesting.
Instead, it's more like the equivalent of a cheap desktop with integrated GPU from 20 years ago, on a single board, with decent linux support, and GPIO. So it's either a linux learning toy, or an integrated component within another product, and not much in between.
Since the introduction of the OG Raspberry Pi, 14 years ago, there's been an ongoing cognitive problem wherein people look at the price of a brand new, never used SBC that can purchased from a reliable retail company.
Then they also look at the price of a used corpo PC (that is bigger, and noisier) that some rando in Iowa is selling on eBay.
And then they boldly compare the prices of the two things as if these details just don't exist.
But the details do exist. The details show that the two things are not the same. They can never be the same.
One is a shiny fresh apple that is free of blemishes, and the other is a bruised old grapefruit that someone has already started eating. They're both fruit, but they're very different things.
There are at least 3 or 4 SBCs with it, in RPI sizes and prices.
Cortex-A78 is much faster than the Cortex-A76 from RK3588 or the latest RPI (e.g. at least 50% faster at the same clock frequency), and its speed at the same clock frequency does not differ much from that of recent medium-size cores like Cortex-A720 or Cortex-A725.
Cortex-A78 is the stage when Arm stopped making significant micro-architectural changes in medium-sized cores. The later improvements were in the bigger Cortex-X cores. The main disadvantage of the older Cortex-A78 is that it does not implement the SVE instruction set of the Armv9-A ISA.
While mini-PCs with Intel/AMD CPUs are usually preferable, for an ARM SBC I would no longer buy any model that has older cores than Cortex-A78.
Besides the Qualcomm Dragonwing based SBCs, there are also Cortex-A78 based SBCs with Mediatek or NVIDIA CPUs, but those are more expensive.
Raspberry Pi are excellent at being general-purpose, full-Linux boxes that consume very low power (some can idle at <1W). Perfect for ambient computing, cron-jobs, MQTT-related hackery, VPN gateways, ad-blocking DNS servers, or anything else that isn't CPU-bound, but benefits from being always available[1].
1. In my case, this ironically includes orchestrating higher-wattage computers via Wake-on-Lan and powering them down when not needed
I have a couple of RPi4 with 8GB and 4GB RAM respectively, these I have been using as kind-of general computers (they're running off SSDs instead of SD cards). I've had no reason so far to replace them with anything Intel/AMD. On the other hand they can't replace my laptop computer - though I wish they could, as I use the laptop computer with an external display and external keyboard 100% of the time, so its form factor is just in the way. But there's way too little RAM on the SBCs. It's bad enough on the laptop computer, with its measly 16GB.
I think in all cases it's the sheer novelty of doing something with a different ISA and form factor. Having built and racked my share of servers I see no reason to build a miniature datacenter in my home but, hey, to each their own.
I wouldn't wish it upon an enemy, but it's a thing.
I thought raspberry pi could basically run a mainline kernel these days -- are there unsupported peripherals besides Broadcom's GPU?
The major difference is Raspberry Pi maintains a parallel fork of Linux and keeps it up to date with LTS and new releases, even updating their Pi OS to later kernels faster than the upstream Debian releases.
Likewise, the 64-bit version of the OS looks like it supports every Raspberry Pi model that has a 64-bit CPU.
Going big-name doesn't even help you here. It's the same story with Nvidia's Jetson platforms; they show up, then within 2-3 years they're abandonware, trapped on an ancient kernel and EOL Ubuntu distro.
You can't build a product on this kind of support timeline.
If we take a step back, I think this is something to be saddened by. I, too, find boards without proper mainline support to be e-waste, and I am glad that we perhaps aren't producing quite as much of that anymore. But imagine if a good chunk of these boards did indeed have great mainline support. These incredibly cheap devices would be a perfect guarantor of democratized, unstoppable general compute in the face of the forces that many of us fear are rising. Even if that's not a fear you share, they'd make the perfect tinkering environment for children and adults not otherwise exposed to such things.
It's now way easier to write drivers/libraries etc whereas before, smaller hardware wasn't worth dedicating developer cycles.
Came looking for this. It's the pitfall of 99% of hardware projects. They get a great team of hardware engineer, they go through the maddening of actually producing a thing (which is crazy complex) at scale, economically viable (hopefully), logistic hurdles including tax worldwide, tariffs, etc... only to have only people on their team be able to build and run a Hello World example.
To be fair even big player, e.g. NVIDIA, sucks at that too. Sure they have their GPU and CUDA but if you look at the "small" things like Jetson everybody I met told me the same thing, great hardware, unusable because the stack worked once when shipped then wasn't maintained.
The reality for actual products is even worse. Qualcomm and Broadcom (even before the PE acquisition) are some of the worst companies to work with imaginable. I’ve had situations where we wasted a month tracking down a bug only for our Qualcomm account manager to admit that the bug was in a peripheral and in their errata already but couldn’t share the whole thing with us, among many other horror stories. I’d rather crawl through a mile of broken glass than have to deal with that again, so I have an extreme aversion to using anything but RPi, as distasteful as that is sometimes.
And today that is replaced with a single relatively tiny in area chip (those old FPGAs were huge) from Broadcom, which does literally everything and complies with newest standard and uses tens of watts of power, and it is passively cooled. It's not quite the correct comparison since arch changed in the meantime, but if someone would build an exact replacement for that older big device using new chips and have the same specs, it would be half as big and use under 1000W or even less. And all software is ready to use without reinventing half of it manually.
But yeah, Broadcom's support is slow and opaque. and they will stall any non-major customer for month for almost any request, because they are prioritizing different tasks internally. It's like a drug dealer dependency and there is only one dealer in your town :) .
That’s just the radios, which is their bread and butter. A lot of their other products have similar barriers to entry.
As the sibling comment noted, FPGAs aren’t even in the running. Ignoring their power consumption, the biggest FPGAs only have a hundred thousand or so logic elements. While its not easy to map that to number of transistors per se, even a legacy nodes are capable of much more complex designs than you can fit on an cutting edge FPGA. This really makes a difference even at the lower end because you have to get the timing right between all the different parts of your logic, and making everything smaller gives a lot more room for error (its a lot easier to put delay lines than to reconfigure a section of your design to fit closer to another section).
There are no ARM NUCs at such prices, and even if there were the GNU/Linux support would be horrible.
To me it would be the opposite conclusion: stay away from ARM SBCs with proprietary firmware and just go Intel-x86 NUCs if you don't want surprises.
And yes, RPI was(is?) a proprietary-FW SBC as the Broadcom VideoCore GPU driver was never open sourced from the start and relied on community efforts for reverse engineering, which the rPI foundation then leveraged to sell their products at a markup to commercial customers after the FOSS community did all the legwork for them for free. Like so long and thanks for all the fish.
Meanwhile Intel iGPUs had full linux kernel drivers out of the box. That's why they're great Jellyfin transcoding servers.
I had to throw away, literally, a Gigabyte BRIX, because its firmware did not recognised any distro I throwed at it from internal drives, only if connected externally over USB.
The experiements with various kinds of SSD modules, Linux distros, and UEFI booting partitions, end up killing the motherboard in someway due to me manipulating it all the time, whatever.
Raspberry PIs are the only NUCs I can buy in something like Conrad Electronic, and be assured it actually works without me going through it as if I had just bough Linux Unleashed in 1995's Summer.
The thing is, for such a niche use-cases it's expected it's not gonna have major retailer availability since it's not something the general consumer is gonna be knowledgeable enough for it to sell in high volumes to be wort for retail stores wherever you may live to stock up shelves on NUCs with Linux preinstalled just to cater to your limited demographic who refuses to order online for some reason, is a very tall order and not really a good faith argument for anything.
The market for people who are like "ah shit, I need to spontaneously go out to the store and pick up a NUC right fucking now, and it has to have Linux preinstalled, because I can't wait a couple of days till it arrives online or know how to install Linux myself", is really REALLY small.
On a more serious note, how do you want normies to get introduced to the Year of Desktop Linux, outside WebOS LG TVs, Android/Linux and ChromeOS, instead of getting Mac minis and Neos at said stores?
I guess it is buying SteamDecks to play Windows games. /s
Raspeberry PIs are the few devices that normies can buy with GNU/Linux pre-installed.
LE to your reply from below here: Excuse me but a form of expression for what? The spec sheet of that Gigabyte Brix explicitly lists only Windows 11 as the supported OS, not Linux. You tried to install an unsupported OS, and you broke it in the process. What exactly do you expect the retail store workers to do to fix the issue you yourself caused via using the product in a way it wasn't advertised? You can contact the manufacturer for warranty or return it via the online return window, but the fuckup is still on your end and not the issue of retail workers.
But I was in Target one day anyway, and they had a Raspberry Pi 3 kit for sale on the shelf. IIRC, it was one of the Google DIY smart speaker kits. I thought that was neat to see.
My usual source for Raspberry Pi stuff is Microcenter. That's also not near to me, but it's a viable destination that's worth a trip all on its own.
At this Microcenter, they move enough Pi hardware that they don't even have them on the shelves anymore. They're instead stocked at each checkout register, and priced at or below MSRP. They're right there alongside a wide assortment of minimally-packaged house-brand SD cards and USB keys and other geek fodder.
It's quick and easy to walk in and grab a couple of spools of printer filament, some 22AWG solid wire for breadboarding, a card of LR44 batteries for the digital calipers, and a Raspberry Pi. (Well, it can be quick. Last time I went, I got sucked into the mechanical keyboard department for an embarrassingly long time.)
Anyway, they also have NUC-shaped computers there if someone wants go that direction instead. Just pick one out, pay for it, and take it home.
IMO the key benefit of a Pi over an x86/a64 box, assuming you aren't using the IO breakouts and such, is power efficiency (particularly at idle-ish). The benefits of the x86/a64 boxes is computing power and being all-in-one (my need was due to my Pi4-based router becoming the bottleneck when my home line was upgraded to ~Gbit, and I wanted something with 2+ built-in NICs rather than relying on USB so didn't even look into the Pi5). Both options beat other SBC based options due to software support, the x86/a64 machines because support is essentially baked in and the rPi by virtue of the Pi foundation and the wider community making great efforts to plug any holes. A Pi range used to win significantly on price (or at least price/performance) too, but that is not the case these days.
This is a common business model sadly where the seller wants the buyer to buy an additional support contract for any actual firmware development.
Sometimes easier to acquire, but usually the same price or more expensive.
Not sure how this compares to the OrangePI in terms of performance per watt but it is already pretty far into the area of marginal gains for me at the cost of having to deal with ARM, custom housing, adapters to ensure the wall socket draw to be efficient etc. Having an efficient pico psu power a pi or orange pi is also not cheap.
A lot of the cheaper mini PCs seem to let the chip go wild, and don't implement sleep/low power states correctly, which is why the range is so wide. I've seen N100 boards idle at 6W, and others idle at 10-12W.
Boost enabled. WiFi disabled. No changes to P clock states or something from bios. Fedora. Applied all suggestions from powertop. I don’t recall changing anything else.
It has major overheating issues though, the N100 was never meant to be put on such a tiny PCB.
It performs well but there is definitely a thermal problem compared to other N100 based systems I got.
It's 127 x 127 x 508 mm. I think most mini N100 PCs are around that size.
The OrangePi 5 Max board is 89x57mm (it says 1.6mm "thickness" on the spec sheet but I think that is a typo - the ethernet port is more than that)
Add a few mm for a case and it's roughly 2/3 as long and half the width of the A40.
Big by comparison, but still pretty small
Unless you strictly need the tiny form factor of an SBC you are so much better going with x86.
Unreliable USB: https://github.com/raspberrypi/linux/issues/3259
Unreliable Wi-Fi:
* https://github.com/raspberrypi/linux/issues/7092
* https://github.com/raspberrypi/linux/issues/7111
* https://github.com/raspberrypi/linux/issues/7272
I don't understand why many say that RPi software/firmware support is 'fantastic'. Maybe it used to be in the beginning compared to other chips and boards, but right now it's a bit above average: they ignore many things which is out of their control/can't debug and fix (as in Wi-Fi chip firmware).
Because other vendors are way worse. Those tickets would not be "unreliable" but simply "broken" with a "Won't fix" status.
Check the Wi-Fi tickets, they are sitting without any replies from the RPi team since 2025. It is broken in these configurations, I decided not to use this strong general term for this case (it's broken only in certain configurations and use cases).
The USB bug (from 2019) has not be fully fixed. They got it much less extent, but did not eliminate the issue.
>Because other vendors are way worse.
There's only a single difference: Chinese vendors don't fix issues in both things they do control and in things they don't. The thing they control is usually a "Distro Build" or Buildroot rootfs hierarchy, which I personally see little value in.
Bugs related to third-party hardware and firmware present on the board gets rarely fixed by both sides.
Don't get me wrong, I'm absolutely not happy with it. I bought Intel NUC, which has Intel Ethernet and Intel Wi-Fi, as my PC with the idea that Intel has end-user support and writes drivers, and NUCs should come with golden Linux support, right? Yet Intel developers still supposed that I had to fix the bug in Intel drivers myself: https://marc.info/?l=linux-pci&m=175368780217953&w=2
Worse, if you flash it to UEFI you’ll lose compat with the one system that did support it (older versions of BredOS). For that, you grab an old release, and never update. If you’re running something simple that you know won’t benefit from any update at all, that’s great. An RK3588 is a decent piece of kit though, and it really deserves better.
There's a reason people just default to RaspberryPi even though better _hardware_ exists. RPi at least gets drivers and software support consistently.
As far as I can tell, the OrangePi 6 remains distinctly uncompetitive with SBCs based on low-end intel chips.
- Orange pi consumes much more power (despite being an arm CPU) - A bit faster on some benchmarks, a bit slower on others - Intel SBC is about 60% the price, and comes with case + storage - Intel SBC runs mainline linux and everything has working drivers
Not on this list is the current GPU Vulkan drivers Collabora are working on too. Don't think that's really blame Rockchip since they're ARM Mali-G610 GPUs, but yeah those didn't get stable in Mesa until last year.
Don't bother trying anything before kernel 6.18.x -- unless you are willing to stick with their 6.1.x kernel with a million+ line diff.
The u-boot environment that comes with the board is hacked up. eg: It supports an undocumented amount of extlinux.conf ... just enough that whatever Debian writes by default, breaks it. Luckily, the u-boot project does support the board and I was able to flash a newer u-boot to the boot media and then the onboard flash [1].
Now the hdmi port doesn't show anything and I use a couple of serial pins when I need to do anything before it's on-net.
--
I purchased a Rock 5T (also rk3588) and the story is similar ... but upstream support for the board is much worse. Doing a diff between device trees [2] (supplied via custom Debian image vs vanilla kernel) tells me a lot. eg: there are addresses that are different between the two.
Upstream u-boot doesn't have support for the board explicitly.
No display, serial console doesn't work after boot.
I just wanted this board for its dual 2.5Gb ethernet ports but the ports even seem buggy. It might be an issue with my ISP... they seem to think otherwise.
--
Not being able to run a vanilla kernel/u-boot is a deal-breaker for me. If I can't upgrade my kernel to deal with a vulnerability without the company existing/supporting my particular board, I'm not comfortable using it.
IMHO, these boards exist in a space somewhere between the old-embedded world (where just having a working image is enough) and the modern linux world (where one needs to be able to update/apply patches)
[1] https://www.reddit.com/r/OrangePI/comments/1l6hnqk/comment/n...
[2] https://gist.github.com/imoverclocked/1354ef79bd24318b885527...
It's pretty hacky for sure but wouldn't classify it as useless. e.g. I managed to get some LLMs to run on the NPU of an Orange pi 5 a while back
I see there is now even a NPU compatible llama.cpp fork though haven't tried it
This is the problem with every SBC that is not a Pi. I don't understand how they just ignore the software problem. I guess people keep buying them?
I guess manjaro just abandoned arm entirely. The options are armbian (probably the pragmatic choice, but fsck systemd), or openbsd (no video acceleration because the drivers are gpl for some dumb reason).
This sort of thing is less likely to happen to rpi, but it’s also getting pretty frustrating at this point.
Er?
https://manjaro.org/products/download/arm explicitly lists the pinebook pro?
Maybe the LLM was wrong and manjaro completely broke the gpg chain (again), but it spent a long time following mirror links, checking timestamps and running internet searches, and I spent over an hour on manual debugging.
But now, I just did the system update, rebooted and got 7.0.0-1 from the package manager, which is never than my x86 laptop. I still have trust issues with this, expecting it to not boot or get up without HDMI output zo.