I really wish these lists would talk about software support. If I buy these, do they have mainline Linux support? Will I have security patches in a year? Is there decent distro support, or am I stuck with the vendor's half broken default image?
I frequently come across comments from people who think raspberry pis are overpriced and you are better off buying from one of the numerous Chinese SBCs with better bang for the buck. Your comment is why these people are often wrong.
Most of those SBCs have very poor software support. You will often need to go on GitHub or the manufactuer's support website to hunt down an OS image that hopefully works. If you want to stay up to date, tough luck. You will be lucky if your board is still receiving updates two years after release.
In the meanwhile in raspberry pi land, you can just go to download a reasonably new OS image from their website anytime you want and it will run on all their models. Even the Pi 1 model B+ which is over ten years old still receives updates, and will continue to do so until at least 2030.
Unless reviewing and playing with random boards is your hobby or job, in which case more power to you and thank you for providing valuable information to the community, you are likely better off buying a boring raspi so you can just get things done.
I don't think RPi is the gold standard nor is Chinese production that strongly correlated with poor SW support?
Raspberry Pi usually requires customisation from the distro. This is mitigated by the fact that many distros have done that customisation but the platform itself is not well-designed for SW support.
Meanwhile many Allwinner and Rockchip platforms have great mainline support. While Qualcomm is apparently moving in the right direction but historically there have been lots of Qualcomm SBCs where the software support is just a BSP tarball on a fixed Linux kernel.
So yeah I do agree with your conclusion but it's not as simple as "RPi has the best software support and don't buy Chinese". You have to look into it on a case by case basis.
> Your comment is why these people are often wrong.
Interestingly, it’s the opposite for me, and I almost exclusively see comments about software support & linux mainlaine.
That said, I think 90% of the time it’s better to buy small x86 machine than a PI. Those have great software support, are more powerful, and can be cheaper (slightly larger & no GPIO, those two are the main reasons to go SBC)
The difference is between x64 machines and ARM machines. The no-name x64 machines have excellent software support because they all run EFI and have fairly ordinary hardware. The no-name ARM boards have cobbled together bootloaders and require specific U-Boot magic most of the time to even get them online.
> In the meanwhile in raspberry pi land, you can just go to download a reasonably new OS image from their website anytime you want and it will run on all their models.
Are you saying that even with the Raspberry Pi we are still at the mercy of the hardware manufacturer when it comes to OS images?
I mean, nothing stops you from taking the device tree from raspbian and tinkering with other distros. But that's true for most other boards since they have to ship a device tree with their official image.
Raspberry Pi supports their images long term however, so you won't have to do that anytime soon.
Another benefit of raspberry pi is its popularity, there are just more projects out there compared to less known SBC manufacturers.
Iirc the Archlinux arm project have images for the raspberry pi 4 (maybe 5).
I would second this. For SBCs the software support is the biggest deal breaker for me these days. Being cheaper or more powerful isn't as much of a benefit without the software ecosystem and community to back it up.
And then the construction quality/tolerance too. I've had Pis last for years and then cheap alternatives burn out after a few months of moderate use.
This comment made me think that RPi is almost like a Windows laptop where the windows license price is baked in. But here is the price of constant maintenance of Raspbian and just drivers in general
The Chinese understand that everyone will be burned once and then never again(hopefully). Thats still millions of dollars in their pockets and not yours. There is a sucker born every minute attracted by the low prices expecting these things to work just like Raspberry pi. I got burned on the Cubieboard 1 in 2012. Still have that junk somewhere in the house having never run any major applications on the device.
I wonder if AI can help bridge the gap and provide the missing support that these vendors don't wish to provide.
Hey! Author of the post someone linked here. Fair comment, though this wasn't really meant to be a review, or "go buy this!" type of post, it was more to highlight what I tested from the boards released in 2025 and share the results to those benchmarks via sbc.compare
Armbian do a great job of handling support for a whole host of boards (including most I included in this list), so you'll usually have Debian/Ubuntu-based flavours. Vendor kernels and vendor supplied images will be hit and miss. Mainline Linux support is a flag you filter by on the benchmark comparison site linked in the article, but it's a difficult one to keep up to date and define exactly. It could have some kind of support, but miss out on display functionality, or WiFi yada yada. What would we then class as having mainline support? All hardware etc functioning? If so, very, very few will meet that definition.
I get the desire for the information, and perhaps I should have envisioned these types of questions, but all I initially meant for the post to be was a recap for people following me to see which boards I'd tested that were released last year :D
Suspend / resume? I'll settle for "keyboard works".
(From what I've learned so far, some magic incantation is required to convince Linux that a Lifebook E559 is a laptop not a tablet. I'm finding I have way less patience with these side-quests as I get older.)
That laptop has an 8th gen Intel processor which should make it completely compatible with the Linux kernel, yet surprisingly it’s not. https://linux-hardware.org/?probe=2ec391ffdc
Did Fujitsu choose an obscure component or interface?
Even on random ARM boards, it's not usually the CPU that's the problem. (It's generally drivers for everything else; eg. a sensor hub that should tell you when a laptop is in tablet mode)
Yes, software support is what kills projects for me. I have been burned on boards with terrible support before. No documentation and some Linux kernel patched by someone on crack. Usually the Chinese comments in the patches are a dead giveaway of where the software originated from.
I'm really curious what will happen to this space when Valve releases great open source drivers for the Qualcomm chip they have in the Steam Frame. It might be one of the first, very powerful, GPU accelerated SoC you can buy that has mainline support.
I can image having a very usable ARM linux laptop and tablet as a result of this — maybe even cellphone when the modems get mainlined or used via USB.
I've worked with many boards from many vendors for many years now...
If you need software to be available in 2, 3, 5 years, get a raspberry pi.
Some might have some software available, some might have patches, some may need manual compiling, some only support debian with 2.4 kernel, some have binary blobs that only work on that 2.4 kernel, some have working usb ports on 2.4 and no gpio, but working gpio with 2.6 kernel but no usb ports, etc.
> ollama benchmark ... for now, it's purely CPU, with DeepSeek R1 models tested based on the RAM available.
Then the results aren't comparable across different boards across RAM sizes. It'd be better to test a set of different model sizes on all and report -- if it didn't fit. But could you report the full ollama model name and version size slug for each?
> I pull Jeff's fork of the ollama-benchmark software
Hmm, I'm not sure if I'm missing something but that 1st comment is what I'm doing. I have 3 different sized Deepseek R1 models (1.5, 8, 16) and they run on each board that can handle them and then the data is reported.
For the 2nd, the file I grabbed initially was https://github.com/geerlingguy/ai-benchmarks/blob/main/obenc... - which I now notice wasn't modified in his repository, so I can check that out, but either way, the same version has been tested across everything thus far.
The BPI-R4 is great for use as a 10G WAN router if your ISP uses PPPoE since the network processing engine has hardware acceleration for it.
Unifi released the UCG-Fiber around a year ago that can also apparently finally handle it, but plenty of threads about slow performance with their UDMs since it's entirely done on the CPU [0].
I'm not the biggest fan of OpenWRT and would prefer something like OPNSense, but it's x86 only and good PPPoE performance isn't guaranteed either - need a CPU with good single core performance that costs more than the BPI-R4, or apparently virtualizing OPNSense allows it to process PPPoE with multiple threads.
I've found it to be the better choice for x86 hardware, because it performs so much better on older CPUs. FreeBSD has gotten better with driver support, but the Linux kernel in OWRT is just a better base to build off of.
not GP but I've found the install and upgrade experience for OpenWRT on larger machines is not great compared to the alternatives and normal Linux distros, everything is biased towards the use case of occasionally flashing/configuring little systems
I still use it though, can't complain in terms of actual routing/switching
I basically stopped buying SBCs several years ago, are there any SoC platforms that have mainline Linux support these days? Or is x86 still the way to go?
The Radxa Orion O6 is a really nice ARMv9.2 ITX board, and supports UEFI boot. Installation of Debian trixie using Debian's vanilla installation media went flawlessly, and it's been running fine for 6 months now.
I am generally happy with my Orange Pi 5, but I have flip flopped between the vendor kernel and a mainline kernel depending on what purpose the OPi5 is serving at that moment.
Does the vendor kernel support more of the board's peripherals than the mainline kernel?
Had that issue with some Odroid boards, where the vendor kernel supported MFC hardware acceleration but the vanilla kernel didn't/doesn't. I'd like to avoid that
Yes, that’s the main reason to run the vendor kernel. Mainline support is improving all the time though.
I believe I needed the vendor kernel to use video through the USB-C port, and to use the HW acceleration for transcoding in Jellyfin. This situation may have changed since my last attempts.
Libre Computer makes a range of SBCs and supports mainline Linux. I use their products, and I'm very happy with them.
"Most ARM single board computers depend on proprietary binary blobs to boot or ship with outdated vendor kernels that are never upstreamed and quickly abandoned. Libre Computer takes a different approach: we fund and contribute to the mainline Linux kernel and U-Boot directly, ensuring our platforms run on upstream open-source software with minimal proprietary firmware."
I find it really weird that it's not until you get to the $200 range that anything has USB-C DP Alt mode support. You'd have though that anyone trying to squeeze space would want to drop full-size HDMI or DisplayPort ports at the first opportunity.
I wish comparisons would get into whether or not drivers have been upstreamed far enough where it is possible to run real Linux distros. And whether or not they've made braindead choices about boot device ordering.
A table or similar where it lists the maker, cost, board name, ram, soc, arch, and maybe other columns like high end/low/budget friendly, and size form factor.
That would be helpful before you dive into the details, for example, I build drones, and seeing nvidia Xavier specs I would be thrilled about it until I see its size and power consumption. Great article btw!
Thanks! See my reply below to the other user on this, I think the links to sbc.compare in the article have a lot of the data that you're looking for. I didn't really want to duplicate all of the data I have on the other site, I was more giving a quick recap, with links to the mass of data if people wanted to go that far. Some you mentioned like the dimensions are in the database, but I've not yet exposed them to the frontend.. Ever growing to-do list of life!
I hadn't seen your site before (or been following SBC for a while) and just skimmed the article and was going to move on. (The post was very cool.)
It wasn't until this thread that I actually clicked through to the sbc.compare. I saw you complement the CIX P1 and Qualcomm in the post but it took looking at the Geekbench numbers on sbc.compare to understand the magnitude of the situation.
(I guess I'm saying the table might've helped me. But I still appreciate the post as is.)
The balancing of wanting to draw attention to sbc.compare and allow the post to stand on its own feet has failed it seems :D No worries, the feedback is good and I'll see if I get time to go back and add a summary for this, otherwise, I'll definitely take it on board for the next one(s).
I think being able to switch between a phone and desktop is a great use-case for SBC. Important to be able to attach a power bank and the real bottleneck to adoption: a telco addon.
You could take that SBC with you on a bike, car, around the home, to the worksite. Even a mobile web server for temporary gatherings placed on a high vantage point. Signage is also an important area for SBCs.
I'd wager on Polymarket that Apple will end up doing something in this space.
For that I'd really point you towards the links in the article, as that was really what it was supposed to do :D As I mentioned to another person in the comments, this was literally supposed to be a recap of the boards I tested, with links to in-depth benchmark results for each of the boards, with the ability to then filter and compare against around 100 other SBCs that I own and have tested in a controlled manner. Software support is a very tricky one though, sadly. I have a few ideas for little things like being able to search for Armbian support, but others would need a long hard think!
Most of those SBCs have very poor software support. You will often need to go on GitHub or the manufactuer's support website to hunt down an OS image that hopefully works. If you want to stay up to date, tough luck. You will be lucky if your board is still receiving updates two years after release.
In the meanwhile in raspberry pi land, you can just go to download a reasonably new OS image from their website anytime you want and it will run on all their models. Even the Pi 1 model B+ which is over ten years old still receives updates, and will continue to do so until at least 2030.
Unless reviewing and playing with random boards is your hobby or job, in which case more power to you and thank you for providing valuable information to the community, you are likely better off buying a boring raspi so you can just get things done.
Raspberry Pi usually requires customisation from the distro. This is mitigated by the fact that many distros have done that customisation but the platform itself is not well-designed for SW support.
Meanwhile many Allwinner and Rockchip platforms have great mainline support. While Qualcomm is apparently moving in the right direction but historically there have been lots of Qualcomm SBCs where the software support is just a BSP tarball on a fixed Linux kernel.
So yeah I do agree with your conclusion but it's not as simple as "RPi has the best software support and don't buy Chinese". You have to look into it on a case by case basis.
Interestingly, it’s the opposite for me, and I almost exclusively see comments about software support & linux mainlaine.
That said, I think 90% of the time it’s better to buy small x86 machine than a PI. Those have great software support, are more powerful, and can be cheaper (slightly larger & no GPIO, those two are the main reasons to go SBC)
Are you saying that even with the Raspberry Pi we are still at the mercy of the hardware manufacturer when it comes to OS images?
Raspberry Pi supports their images long term however, so you won't have to do that anytime soon.
Another benefit of raspberry pi is its popularity, there are just more projects out there compared to less known SBC manufacturers. Iirc the Archlinux arm project have images for the raspberry pi 4 (maybe 5).
And then the construction quality/tolerance too. I've had Pis last for years and then cheap alternatives burn out after a few months of moderate use.
If you're lucky! Most of the time it's a questionable Google Drive link.
I wonder if AI can help bridge the gap and provide the missing support that these vendors don't wish to provide.
Armbian do a great job of handling support for a whole host of boards (including most I included in this list), so you'll usually have Debian/Ubuntu-based flavours. Vendor kernels and vendor supplied images will be hit and miss. Mainline Linux support is a flag you filter by on the benchmark comparison site linked in the article, but it's a difficult one to keep up to date and define exactly. It could have some kind of support, but miss out on display functionality, or WiFi yada yada. What would we then class as having mainline support? All hardware etc functioning? If so, very, very few will meet that definition.
I get the desire for the information, and perhaps I should have envisioned these types of questions, but all I initially meant for the post to be was a recap for people following me to see which boards I'd tested that were released last year :D
If your standard is "supports suspend/resume", there's even plenty of laptops that won't meet it.
That gave me a laugh.
(From what I've learned so far, some magic incantation is required to convince Linux that a Lifebook E559 is a laptop not a tablet. I'm finding I have way less patience with these side-quests as I get older.)
Disclaimer: I have never used any RISC-V board.
https://dietpi.com
I can image having a very usable ARM linux laptop and tablet as a result of this — maybe even cellphone when the modems get mainlined or used via USB.
If you need software to be available in 2, 3, 5 years, get a raspberry pi.
Some might have some software available, some might have patches, some may need manual compiling, some only support debian with 2.4 kernel, some have binary blobs that only work on that 2.4 kernel, some have working usb ports on 2.4 and no gpio, but working gpio with 2.6 kernel but no usb ports, etc.
Just get a raspberry pi.
Then the results aren't comparable across different boards across RAM sizes. It'd be better to test a set of different model sizes on all and report -- if it didn't fit. But could you report the full ollama model name and version size slug for each?
> I pull Jeff's fork of the ollama-benchmark software
A link would be nice.
For the 2nd, the file I grabbed initially was https://github.com/geerlingguy/ai-benchmarks/blob/main/obenc... - which I now notice wasn't modified in his repository, so I can check that out, but either way, the same version has been tested across everything thus far.
Unifi released the UCG-Fiber around a year ago that can also apparently finally handle it, but plenty of threads about slow performance with their UDMs since it's entirely done on the CPU [0].
I'm not the biggest fan of OpenWRT and would prefer something like OPNSense, but it's x86 only and good PPPoE performance isn't guaranteed either - need a CPU with good single core performance that costs more than the BPI-R4, or apparently virtualizing OPNSense allows it to process PPPoE with multiple threads.
0: https://community.ui.com/questions/What-is-the-max-performan...
I've found it to be the better choice for x86 hardware, because it performs so much better on older CPUs. FreeBSD has gotten better with driver support, but the Linux kernel in OWRT is just a better base to build off of.
I still use it though, can't complain in terms of actual routing/switching
Edit: never mind. Not official images.
There’s also a fairly usable UEFI implementation.
Had that issue with some Odroid boards, where the vendor kernel supported MFC hardware acceleration but the vanilla kernel didn't/doesn't. I'd like to avoid that
I believe I needed the vendor kernel to use video through the USB-C port, and to use the HW acceleration for transcoding in Jellyfin. This situation may have changed since my last attempts.
"Most ARM single board computers depend on proprietary binary blobs to boot or ship with outdated vendor kernels that are never upstreamed and quickly abandoned. Libre Computer takes a different approach: we fund and contribute to the mainline Linux kernel and U-Boot directly, ensuring our platforms run on upstream open-source software with minimal proprietary firmware."
https://libre.computer/
That would be helpful before you dive into the details, for example, I build drones, and seeing nvidia Xavier specs I would be thrilled about it until I see its size and power consumption. Great article btw!
It wasn't until this thread that I actually clicked through to the sbc.compare. I saw you complement the CIX P1 and Qualcomm in the post but it took looking at the Geekbench numbers on sbc.compare to understand the magnitude of the situation.
(I guess I'm saying the table might've helped me. But I still appreciate the post as is.)
I mean really though unless you have a lot of time I don't think there's anything close to worth leaving the software support of Raspberry Pi for.
https://www.waveshare.com/product/cm4-disp-base-2.8a.htm
I think being able to switch between a phone and desktop is a great use-case for SBC. Important to be able to attach a power bank and the real bottleneck to adoption: a telco addon.
Some sort of vibration absorbing case would also be great with a few different varieties around too: https://www.gttwireless.com/raspberry-pi-outdoors/ https://github.com/NebraLtd/IP67-Enclosure
You could take that SBC with you on a bike, car, around the home, to the worksite. Even a mobile web server for temporary gatherings placed on a high vantage point. Signage is also an important area for SBCs.
I'd wager on Polymarket that Apple will end up doing something in this space.
Rpi and also nvidia jetson I would add.