My experience with the OrangePi 4 LTS has been poor, and I'm unwilling to purchase more of their hardware. Mine is now running Armbian because I didn't care for the instability, or for the Chinese repos.
They seem uninterested in trying to get their hardware supported by submitting their patches for inclusion in the Linux kernel, and popular distros. Instead, you have to trust their repos (based in PRC).
"Chinese repos" is a very charitable interpretation of the Google drive links they used to distribute the os. It seemed like it was on the free plan too, it often didn't work because it tripped the maximum downloads per month limit.
It's always better than a link in the sticky post on the manufacturer's phpbb forum. I bought some audio equipment directly from a Chinese company, and everything look like a hobbies/student project.
I opened the review and immediately ctrl-F'd "kernel". It said no upstream support so I closed the article.
I would never buy one of these things without upstream kernel support for the SoC and a sane bootloader. Even the Raspberry Pi is not great on this front TBH (kernel is mostly OK but the fucked up boot chain is a PITA, requires special distro support).
so what would you recommend for arm which has good proper support.
I feel like rasp pi has the most community support for everything so I had the intution that most things would just work out of the box on it or it would have the best arm support (I assumed the boot chain to be that as well)
what do you mean by the boot chain being painful to work with and can you provide me some examples perhaps?
I don't have any Radxa model, but I have a bunch of SBCs from different makers and I have never seen a problem with boot working half of the time only.
The review shows ARM64 software support is still painful vs x86. For $200 for the 16gb model, this is the price point where you could just get an Intel N150 mini PC in the same form factor. And those usually come with cases. They also tend to pull 5-8w at idle, while this is 15w. Cool if you really want ARM64, but at this end of the performance spectrum, why not stick with the x86 stack where everything just works a lot easier?
From the article: "[...] the Linux support for various parts of the boards, not being upstreamed and mainlined, is very likely to be stuck on an older version. This is usually what causes headaches down the road [...]".
The problem isn't support for the ARM architecture in general, it's the support for this particular board.
Other boards like the Raspberry Pi and many boards based on Rockchip SoCs have most of the necessary support mainlined, so the experience is quite painless. Many are starting to get support for UEFI as well.
The exception (even those are questionable as running plain Debian did not work right on Pi 3B and others when I tried recently) proves the rule. You have to look really hard to find an x86 computer where things don't just basically work, the reverse is true for ARM. The power draw between the two is comparable these days, so I don't understand why anyone would bother with ARM when you've got something where you need more than minimally powerful hardware.
This. The issue is the culture inside many of these HW companies that is oppositional to upstreaming changes and developing in the open in general.
Often an outright mediocre software development culture generally, that sees software as a pure cost centre, in fact. The "product" is seem to be the chip, the software "just" a side show (or worse, a channel by which their IP could leak).
The Rockchip stuff is better, but still has similar problems.
These companies need to learn that their hardware will be adopted more aggressively for products if the experience of integrating with it isn't sub-par.
My uninformed normie view of the ecosystem suggests that it's the support for almost every particular board, and that's exactly the issue. For some reason, ARM devices always have some custom OS or Android and can't run off-the-shelf Linux. Meanwhile you can just buy an x86/amd64 device and assume it will just work. I presume there is some fundamental reason why ARM devices are so bad about this? Like they're just missing standardization and every device requires some custom firmware to be loaded by the OS that's inevitably always packaged in a hacky way?
So, I agree but less than I did a few months ago. I purchased an Orange Pi 5 Ultra and was put off by the pre-built image and custom kernel. The “patch“ for the provided kernel was inscrutable as well. Now I’m running a vanilla 6.18 kernel on a vanilla uboot firmware (still a binary blob required to build that though) with a vanilla install of Debian. That support includes the NPU, GPU, 2.5G Ethernet and NVMe root/boot. I don’t have performance numbers but it’s definitely fast enough for what I use it for.
No it's definitely a problem with the ARM architecture, specifically that it's standard to make black box SoCs that nobody can write drivers for and the manufacturer gives you one binary version and then fucks off forever. It's a problem with the ARM ecosystem as a whole for literally every board (except Raspberry Pi), likely stemming from the bulk of ARM being throwaway smartphones with proprietary designs.
If ARM cannot outdo x86 on power draw anymore then it really is entirely pointless to use it because you're trading off a lot, and it's basically guaranteed that the board will be a useless brick a few years down the line.
There's also a risk of your DeviceTree getting pruned from the kernel in X years when it's decided that "no one uses that board anymore", which is something that's happened to several boards I bought in the 2010's, but not something that's happened to any PC I've ever owned.
That makes sense, as the Pi is as easy as x86 at this point. I almost never have to compile from scratch.
I'm not a compiler expert... But it seems each ARM64 board needs its own custom kernel support, but once that is done, it can support anything compiled to ARM64 as a general target? Or will we still need to have separate builds for RPi, for this board, etc?
With this board the SoC is the main problem.
CIX is working on mainlining that stuff for over a year and we still dont have gpu and npu support in mainline
> The problem isn't support for the ARM architecture in general,
Of course it is not. That's why almost every ARM board comes with it's own distro, sometimes bootloader and kernel version. Because "it is supported". /s
I was soured on ARM SBCs by the Orange Pi 5, which does not have an option to ignore its SD card during boot. Something trivial on basically every x86 platform I had been taking for granted.
With RAM it will be costing notably more, with 4 cores instead of 12. I'd expect this to run circles around an N150 for single-threaded perf too.
They are not in the same class, which is reflected in the power envelope.
BTW what's up with people pushing N150 and N300 in every single ARM SBC thread? Y'all Intel shareholders or something? I run both but not to the exclusion of everything else. There is nothing I've failed to run successfully on my ARM ones and the only thing I haven't tried is gaming.
> BTW what's up with people pushing N150 and N300 in every single ARM SBC thread?
At this point I expect a lot of people have been enticed by niche SBCs and then discovered that driver support is a nightmare, as this article shows. So in time, everyone discovers that cheap x86-64 boxes accomplish their generic computing goals easier than these niche SBCs, even if the multi-core performance isn't the same.
Being able to install a mainline OS and common drivers and just get to work is valuable.
> BTW what's up with people pushing N150 and N300 in every single ARM SBC thread?
Because they have a great watt/performance ratio along with a GPU that is very well supported by a wide range of devices and mainline kernel support. In other words a great general purpose SBC.
Meanwhile people are using ARM SBCs, with SoCs designed for embedded or mobile devices, as general purpose computers.
I will admit with RAM and SSD prices sky rocketing these ARM SBC look more attractive.
Because most ARM SBCs are still limited to whatever linux distro they added support to. Intel SBCs might underperform but you can be sure it will run anything built for x86-64.
Are you sure you don't have single-threaded and multi-threaded backwards?
Why would the A720 at 2.8 GHz run circles around the N150 that boosts up to 3.6 GHz in single-threaded workloads, while the 12-core chip would wouldn't beat the 4-core chip in multithreaded workloads?
I can't speak to why other people bring up the N150 in ARM SBC threads any more than "AMD doesn't compete in the ~$200 SBC segment".
FWIW, as far as SBC/NUCs go, I've had a Pi 4, an RK3399 board, an RK3568 board, an N100 NUC from GMKTec, and a N150 NUC from Geekom, and the N150 has by far been my favorite out of those for real-world workloads rather than tinkering. The gap between the x86 software ecosystem and the ARM software ecosystem is no joke.
P.S. Stay away from GMKTec. Even if you don't get burned, your SODIMM cards will. There are stoves, ovens, and hot plates with better heat dissipation and thermals than GMKTec NUCs.
> BTW what's up with people pushing N150 and N300 in every single ARM SBC thread?
For 90% of use cases, ARM SBCs are not appropriate and will not meet expectations over time.
People expect them to be little PCs, and intend to use them that way, but they are not. Mini PCs, on the other hand, are literally little PCs and will meet the expectations users have when dealing with PCs.
x86 based small computers are just so much easier to work with than most second- and third-string ARM vendors. The x86 scene has had standards in place for a long time, like PCIe and the PC BIOS (now UEFI) for hardware initialization and mapping, that make it a doddle to just boot a kernel and let it get the hardware working. ARM boards don't have that yet, requiring per-board support in the kernel which board manufacturers famously drag their feet on implementing openly let alone upstreaming. Raspberry Pi has its own setup, which means kernel support for the Pi series is pretty good, but it doesn't generalize to other boards, which means users and integrators may be stuck with whatever last version of Ubuntu or Android the vendor thought to ship. Which means if you want a little network appliance like a router, firewall, Jellyfin server, etc. it often makes more sense to go with an N150 bitty box than an ARM SBC because the former is going to be price- and power-draw-competitive with the latter while being able to draw on the OS support of the well-tested PC ecosystem.
ARM actually has a spec in place called SystemReady that standardizes on UEFI, which should make bringup of ARM systems much less jank. But few have implemented it yet. I keep saying, the first cheap Chinese vendor that ships a SystemReady-compliant SBC is gonna make a killing.
1. Wow, never thought I'd need to do an investment disclosure for an HN comment. But sure thing: I'm sure Intel is somewhere in my 401K's index funds, but also probably Qualcomm. But I'm not a corporate shill, thank you very much for the good faith. Just a hobbyist looking to not get seduced by the lastest trend. If I were an ARM developer that'd be different, I get that.
2. The review says single core Geekbench performance is 1290, same as i5-10500 which is also similar to N150, which is 1235.
3. You can still get N150s with 16gb ram in a case for $200 all in.
Yes x86 will win for convenience on about every metric (at least for now), but this SoC's CPU is much faster than a mere Intel N150 (especially for multicore use cases).
I've got i3 and i5 systems that do 15W or better idle, and I don't have to worry about the absolute clusterfuck of ARM hardware (and those systems used can be had for less and will probably long outlive mystery meat ARM SBCs).
Agreed, at least for a likely "home use" case, such as a TV box, router, or general purpose file server or Docker host, I don't see how this board is better than something like a Beelink mini PC. The Orange Pi does not even come with a case, power supply or cooler. Contrast that with a Beelink that has a built-in power supply (no external brick) and of course a case and cooler.
I've got two RK3588 boards here doing Linux-y things around my place (Jellyfin, Forgejo builders, Immich, etc) and ... I don't think I've run into pain? They're running various debian and just ... work? I can't think of a single package that I couldn't get for ARM64.
Likewise my VPS @ Hetzner is running Aarch64. No drama. Only pain is how brutal the Rust cross-compile is from my x86 machine.
(Those things are expensive, but I just ordered one [the ASUS variant] for myself.)
Meanwhile Apple is pushing the ARM64 architecture hard, and Windows is apparently actually quite viable now?
Personally... it's totally irrational, but I have always had a grudge against x86 since it "won" in the early 90s and I had to switch from 68k. I want diversity in ISAs. RISC-V would be nice, but I'll settle for ARM for now.
the high end of the performance is impressive and this has idle power similar to the processors in it's performance range(AMD Ryzen 7 4800H idles at 45W). This is certainly not meant for lower power computing.
We need an acronym for these types of boards: Yet Another SBC With Poor Longterm Support. YASBCWPLS. Really rolls off the tongue.
Or we should just have "STS" (Short Term Support) after the board names to let others know the board will be essentially obsolete (based on lack of software updates) in two months.
Without mainline Linux support I have no interest in these more obscure SBCs. Mainline Linux is the bare minimum, put in some effort please manufacturers.
Buying one of these Pi knockoffs taught me one thing, software support is the key to raspberry pi’s success.
Whenever I would have a problem, and it was more often than not, I would search for a solution and come across something that worked for rpi that I could try to port across.
Double the hardware spec matters little if you can’t get the software to even compile
When something has an 30 TOPS NPU, what are the implications? Do NPUs like this have some common backend that ggml/llama.cpp targets? Is it proprietary and only works for some specific software? Does it have access to all the system RAM and at what bandwidth?
I know the concept has been around for a while but no idea if it actually means anything. I assume that people are targeting ones in common devices like Apple, but what about here?
Can't speak to this specific NPU but these kind of accelerators are really made more for more general ML things like machine vision etc. For example while people have made the (6 TOPS) NPU in the (similar board) RK3588 work with llama.cpp it isn't super useful because of the RAM constraints. I believe it has some sort of 32-bit memory addressing limit, so you can never give it more than 3 or 4 GB for example. So for LLMs, not all that useful.
Ignorant of this NPU, but in my experience, you're expected to use some cursed stack of proprietary tools/runtimes/SDKs/etc and no, it will not play nicely with anything you want it to unless you write the support yourself.
30 TOPS NPU is the almost-useful minimum for a device, but as we've seen that even microsoft couldn't come up with anything useful to do with it in the AI laptops. This has all but disappeared, they are pushing the cloud licensing over local AI now
The specific NPU doesn't seem to be mentioned in TFA, but my guess is that the blessed way to deal with it is the Neon SDK: https://www.arm.com/technologies/neon
I've not found Neon to be fun or easy to use, and I frequently see devices ignoring the NPU and inferring on CPU because it's easier. Maybe you get lucky and someone has made a backend for something specific you want, but it's not common.
TFA does directly mention the NPU "Arm-China Zhouyi: 30 TOPS (Dedicated)"
"you cannot simply use standard versions of PyTorch or TensorFlow out of the box. You must use the NeuralONE AI SDK."
Neon is a SIMD instruction set for the CPU, not a separate accelerator. It doesn't need an SDK to use, it's supported by compiler intrinsics and assembly language in any modern ARM compiler.
It needs specific support, and for example llama.cpp would have support for some of them. But that comes with limitations in how much RAM they can allocate. But when they work, you see a flat CPU usage and the NPU does everything for inference.
I'm not sure I'm gonna grab another OrangePi board again. I was happy to grab the RV2 just to experiment around with, but I didn't realize that the linux kernel they provided to build their ubuntu distro doesn't actually build properly. I got it to build after throwing a version of ubuntu onto an unused pc, but then it didn't matter the options I selected for the build (like gui options) it seemed like the gui just didn't exist at all in the final binary. I've yet to try and build a 3rd party os with support since I spent so much time just trying to get the official distro to work properly.
I think the sweet spot for ARM SBCs are smaller, less powerful and cheaper for headless IOT edge cases. I use a couple of them that way when I need LAN connectivity, either by ethernet or wifi, and things wired to GPIO pins. I don't need a powerful CPU or lots of RAM for that. The SBC makers are caught up in a horsepower race and I just shrug, it's not for me.
This is my experience as well. I have a couple PINE64 devices, a Rock64 (Rockchip RK3328) and a RockPro64 (RK3399). And an N150 device.
Both ARM64 devices run headless, make use of GPIO, and have more than enough CPU. In fact, these are stable enough that I run BSDs on them and don't bother with Linux.
The Rock64 runs FreeBSD for SDR applications (e.g. ADS-B receiver). FreeBSD has stable USB support for RTL-SDR devices.
The RockPro64 runs NetBSD with ZFS with a PCIe SSD. NetBSD can handle ARM big.LITTLE well. I run several home lab workloads on this. Fun device.
I also have an N150 device running the latest Debian 13 as my main home lab server for home automation, Docker, MQTT broker, etc.
In short: SBCs are cheap enough that you can choose more than one, each for the right task, including IoT.
How are we still in a world where there are breathless, hand-waving blog posts written about the theoretical potential of super-fast SBCs for which the manufacturer shows fuck all interest in competent OS support?
Yet again, OrangePi crank out half-baked products and tech enthusiasts who quite understandably lack the deep knowledge to do more than follow others' instructions on how to compile stuff talk about it as if their specifications actually matter.
Yet again the HN discourse will likely gather around stuff like "why not just use an N1x0" and side quests about how the Raspberry Pi Foundation has abandoned its principles / is just a cynical Broadcom psyop / is "lagging behind" in hardware.
This stuff can be done better and the geek world should be done excusing OrangePi producing hardware abandonware time after time. Stop buying this crap and maybe they will finally start focussing on doing more than shipping support for one or two old kernels and last year's OS while kicking vague commitments about future support just far enough down the road that they can release another board first.
Please stop falling for it :-/
ETA: I think what grinds my gears the most is that OrangePi, BananaPi etc., are largely free-riding off the Linux community while producing products that only "beat" the market-defining manufacturers (Raspberry Pi, BeagleBoard) because they treat software support as an uncosted externality.
This kind of "build it and they will use it" logic works well for microcontrollers, where a manufacturer can reasonably expect to produce a chip with a couple of tech demos, a spec sheet and a limited C SDK and people will find uses for it.
But for "near-desktop class" SBCs it is not much better than misrepresentation. Consequently these things are e-waste in a way that even the global desk drawer population of the Raspberry Pi does not reach.
And yet they are graded on a curve and never live up to their potential.
I wouldn’t be surprised if it performs adequately in this context —- isn’t the manufacturer a VOIP device maker?
The reality is that they spam the market with a large number of products with little consistency, poor (if labyrinthine) documentation, random google drive links for firmware etc., and there are the same issues with hardware support.
I dunno, maybe the situation there is better than it was. But the broad picture is the same: better hardware but you are basically on your own.
Their approach to software support does leave a lot to be desired.
For what it's worth though the v5 did have Talos support, so you could just throw that on there, connect it to a cluster and have a decent arm node that is fanless and has 32gb
My Orange Pi RV2 sucks :( The available distros, drivers, kernel, and tools do work, but they’re crappy, and poorly maintained. There’s no support and very little documentation, which is a real shame. From a hardware point of view, it’s a nice board and when I properly compiled some softwares myself I actually got really interesting performance, but it was a pain in the ass.
So I ended up buying a Raspberry Pi 4, much better supported and documented.
I have a software that need to build aarch64 (for some aarch64 box with 4 core cpu), currently using Oracle cloud's 4core24G Arm neoverse n1 as github self host runner to build it.
Seems this machine is more powerful than it, definitely attractive to me for a physical aarch64 self host runner.
I am newly interested in Compute Module style SBCs after I bought a one to toy around with. I was surprised to learn that the PCBs that interface to them are open specs and I can probably build myself more custom PCB solutions to match different form factors instead of being stuck with a bulky normal Raspberry Pi.
I was pleased to learn that Radxa and Orange Pi have compatible similar boards.
I have wanted to see more RISC SBCs so I may toy with these but I rather wait for the software support to get much richer.
I'm still using the Orange Pi 3 LTS. It's been two years, I've managed to move to another city, and she's still in service. I use it mainly for testing my amateur projects, nothing more. Linux distributions (Debian, Ubuntu) from Xunlong are just terrible. I don't remember why, but I didn't like them. But Armbian has been running on such a computer for almost two years. Well, I love OPi ^)
I am not a kernel developer, so I don't really have any idea what this means, but CIX appears to have patches in the Linux kernel[0], so I assume mainlining more stuff is in the works?
I bought a used thinkcentre tiny off of eBay. It's got great GPU decoding/encoding support, great driver support for all the peripherals, and can boot from an m2 NVME or a SATA drive, it has a very normal bootloader. It can even run Windows. The mostly-aluminum enclosure is very nice and well-engineered, it's easy to pop open, it has a power button. It was under $100 and makes me question why any hobbyist bothers with SBCs like these.
What is the Real World use case for dual 5Gbit/s Ethernet ports? I just don't understand how a relatively underpowered board could ever make good use of (combined) 10Gbit/s Ethernet bandwidth. Is this strictly bragging rights?
Prices are considerably higher through the links than quoted in the article. This usually happens when someone posts about a great deal for surplus hardware on Ebay or a hidden gem on aliexpress. Just the thundering herd of traffic causes algorithmic pricing to spike the price.
i really with raspberry pi foundation released a pi with built in nvme instead of using a hat. i think using flash memory is the true bottleneck on the system
Heh, I'm the opposite. I wish the rpi stayed the course of cheapest "working" SBC, and move their high-end boards to a different brand. Raspberry Sigma, or 67 or whatever gets the younguns crazy these days.
After the pandemic, the "25$" SBC suddenly became 100+ with low availability. The main thing that made rpis worth it is gone now, and they're all chasing number go up on benchmarks.
I hear you. There is obviously a lot of tension between price and performance. I think the introduction of boards with larger and larger ram specs really pushed the cost just before the pandemic and then scarcity spiked things even more. As when I purchased the rpi4, I got the maximum RAM and that became expensive.
However, SD Cards are really terrible devices to run a general purpose computer on and they are designed for storing large files like photos, videos and mp3’s sequentially not the SWAP, logs, and databases that a full operating system is constantly writing and accessing in a random fashion.
I think if you are running a base 2gb, then maybe absolute value makes sense, but once you start hitting the larger RAM configutations, an M2 slot is a no brainer.
I think the cheapest working SBC is really the zero line.
Actually the Orange Pi 5 Ultra would be the most recent board from Orange Pi to compare it with. You can see a comparison between the Orange Pi 5 Ultra and the Raspberry Pi 5 here: https://boilingsteam.com/orange-pi-5-ultra-review/
In a nutshell, this new Orange Pi 6 Plus is much faster than Orange Pi 5 Ultra and anything that came before.
Plus and ultra are almost identical with the exception of an HMDI in port on the latter. I've used the same HAL on both boards, they are effectively the same.
Yet another board which will never have proper upstream support because the SoC vendor refused to implement the ARM BSA standard which would provide EFI/ACPI support instead of relying on undiscoverable devices only exposed through device tree. ACPI isn't perfect but it's way better than device trees which are seldom updated so the device will remain stuck with old kernels.
It was originally sold as 2.8ghz but never actually could hit 2.8ghz. after some complaints on the forums they reduced the advertised frequency to 2.6ghz.
My experience with the OrangePi 4 LTS has been poor, and I'm unwilling to purchase more of their hardware. Mine is now running Armbian because I didn't care for the instability, or for the Chinese repos.
They seem uninterested in trying to get their hardware supported by submitting their patches for inclusion in the Linux kernel, and popular distros. Instead, you have to trust their repos (based in PRC).
"Chinese repos" is a very charitable interpretation of the Google drive links they used to distribute the os. It seemed like it was on the free plan too, it often didn't work because it tripped the maximum downloads per month limit.
It's always better than a link in the sticky post on the manufacturer's phpbb forum. I bought some audio equipment directly from a Chinese company, and everything look like a hobbies/student project.
3 replies →
> "Chinese repos" is a very charitable interpretation of the Google drive links they used to distribute the os.
"Chinese repos" refer to the fact that the debian repos links for updates point to custom Huawei servers.
> it often didn't work because it tripped the maximum downloads per month limit.
it always work if you login into a Google account prior to downloading. If you don't, indeed the downloads will regularly fail.
3 replies →
I opened the review and immediately ctrl-F'd "kernel". It said no upstream support so I closed the article.
I would never buy one of these things without upstream kernel support for the SoC and a sane bootloader. Even the Raspberry Pi is not great on this front TBH (kernel is mostly OK but the fucked up boot chain is a PITA, requires special distro support).
so what would you recommend for arm which has good proper support.
I feel like rasp pi has the most community support for everything so I had the intution that most things would just work out of the box on it or it would have the best arm support (I assumed the boot chain to be that as well)
what do you mean by the boot chain being painful to work with and can you provide me some examples perhaps?
3 replies →
I have this experience with most of these SBC-s. The new Radxa board boots 50% of the time. The only reliable SBCs I have are RPI3|4.
The Orion? God mine is so annoying. What a waste of money.
2 replies →
I don't have any Radxa model, but I have a bunch of SBCs from different makers and I have never seen a problem with boot working half of the time only.
I have a Radxa zero 3E that boots and runs fine.
Sounds like a faulty SD card.
1 reply →
That's always the problem with these non-Pi SBCs. They never have good software support.
Olimex does provide both open source hardware and open source software for example: https://www.olimex.com/Products/OLinuXino/STMP1/STMP157-OLin...
1 reply →
Even bigger brands such as Nvidia seem to expect us to recycle SBCs every couple years.
3 replies →
The NanoPi models from FriendlyElec tend to have better support.
you keep insinuating PRC yet you don't realize you're already pwned just running their hardware no matter the OS.
Directly stating something twice is not insinuating…
Point to the spot on the board where China hurt you.
3 replies →
The review shows ARM64 software support is still painful vs x86. For $200 for the 16gb model, this is the price point where you could just get an Intel N150 mini PC in the same form factor. And those usually come with cases. They also tend to pull 5-8w at idle, while this is 15w. Cool if you really want ARM64, but at this end of the performance spectrum, why not stick with the x86 stack where everything just works a lot easier?
From the article: "[...] the Linux support for various parts of the boards, not being upstreamed and mainlined, is very likely to be stuck on an older version. This is usually what causes headaches down the road [...]".
The problem isn't support for the ARM architecture in general, it's the support for this particular board.
Other boards like the Raspberry Pi and many boards based on Rockchip SoCs have most of the necessary support mainlined, so the experience is quite painless. Many are starting to get support for UEFI as well.
The exception (even those are questionable as running plain Debian did not work right on Pi 3B and others when I tried recently) proves the rule. You have to look really hard to find an x86 computer where things don't just basically work, the reverse is true for ARM. The power draw between the two is comparable these days, so I don't understand why anyone would bother with ARM when you've got something where you need more than minimally powerful hardware.
1 reply →
This. The issue is the culture inside many of these HW companies that is oppositional to upstreaming changes and developing in the open in general.
Often an outright mediocre software development culture generally, that sees software as a pure cost centre, in fact. The "product" is seem to be the chip, the software "just" a side show (or worse, a channel by which their IP could leak).
The Rockchip stuff is better, but still has similar problems.
These companies need to learn that their hardware will be adopted more aggressively for products if the experience of integrating with it isn't sub-par.
3 replies →
My uninformed normie view of the ecosystem suggests that it's the support for almost every particular board, and that's exactly the issue. For some reason, ARM devices always have some custom OS or Android and can't run off-the-shelf Linux. Meanwhile you can just buy an x86/amd64 device and assume it will just work. I presume there is some fundamental reason why ARM devices are so bad about this? Like they're just missing standardization and every device requires some custom firmware to be loaded by the OS that's inevitably always packaged in a hacky way?
15 replies →
So, I agree but less than I did a few months ago. I purchased an Orange Pi 5 Ultra and was put off by the pre-built image and custom kernel. The “patch“ for the provided kernel was inscrutable as well. Now I’m running a vanilla 6.18 kernel on a vanilla uboot firmware (still a binary blob required to build that though) with a vanilla install of Debian. That support includes the NPU, GPU, 2.5G Ethernet and NVMe root/boot. I don’t have performance numbers but it’s definitely fast enough for what I use it for.
3 replies →
No it's definitely a problem with the ARM architecture, specifically that it's standard to make black box SoCs that nobody can write drivers for and the manufacturer gives you one binary version and then fucks off forever. It's a problem with the ARM ecosystem as a whole for literally every board (except Raspberry Pi), likely stemming from the bulk of ARM being throwaway smartphones with proprietary designs.
If ARM cannot outdo x86 on power draw anymore then it really is entirely pointless to use it because you're trading off a lot, and it's basically guaranteed that the board will be a useless brick a few years down the line.
There's also a risk of your DeviceTree getting pruned from the kernel in X years when it's decided that "no one uses that board anymore", which is something that's happened to several boards I bought in the 2010's, but not something that's happened to any PC I've ever owned.
3 replies →
That makes sense, as the Pi is as easy as x86 at this point. I almost never have to compile from scratch.
I'm not a compiler expert... But it seems each ARM64 board needs its own custom kernel support, but once that is done, it can support anything compiled to ARM64 as a general target? Or will we still need to have separate builds for RPi, for this board, etc?
3 replies →
With this board the SoC is the main problem. CIX is working on mainlining that stuff for over a year and we still dont have gpu and npu support in mainline
I still have to run my own build of kernel on Opi5+, so that unfortunately tracks. At least I dont have to write the drivers this decade
3 replies →
> The problem isn't support for the ARM architecture in general,
Of course it is not. That's why almost every ARM board comes with it's own distro, sometimes bootloader and kernel version. Because "it is supported". /s
I was soured on ARM SBCs by the Orange Pi 5, which does not have an option to ignore its SD card during boot. Something trivial on basically every x86 platform I had been taking for granted.
With RAM it will be costing notably more, with 4 cores instead of 12. I'd expect this to run circles around an N150 for single-threaded perf too.
They are not in the same class, which is reflected in the power envelope.
BTW what's up with people pushing N150 and N300 in every single ARM SBC thread? Y'all Intel shareholders or something? I run both but not to the exclusion of everything else. There is nothing I've failed to run successfully on my ARM ones and the only thing I haven't tried is gaming.
> I'd expect this to run circles around an N150 for single-threaded perf too
It has basically the same single-core performance as an N150 box
Random N150 result: https://browser.geekbench.com/v6/cpu/10992465
> BTW what's up with people pushing N150 and N300 in every single ARM SBC thread?
At this point I expect a lot of people have been enticed by niche SBCs and then discovered that driver support is a nightmare, as this article shows. So in time, everyone discovers that cheap x86-64 boxes accomplish their generic computing goals easier than these niche SBCs, even if the multi-core performance isn't the same.
Being able to install a mainline OS and common drivers and just get to work is valuable.
> BTW what's up with people pushing N150 and N300 in every single ARM SBC thread?
Because they have a great watt/performance ratio along with a GPU that is very well supported by a wide range of devices and mainline kernel support. In other words a great general purpose SBC.
Meanwhile people are using ARM SBCs, with SoCs designed for embedded or mobile devices, as general purpose computers.
I will admit with RAM and SSD prices sky rocketing these ARM SBC look more attractive.
Because most ARM SBCs are still limited to whatever linux distro they added support to. Intel SBCs might underperform but you can be sure it will run anything built for x86-64.
Are you sure you don't have single-threaded and multi-threaded backwards?
Why would the A720 at 2.8 GHz run circles around the N150 that boosts up to 3.6 GHz in single-threaded workloads, while the 12-core chip would wouldn't beat the 4-core chip in multithreaded workloads?
Obviously, the Intel chip wins in single-threaded performance while losing in multi-threaded: https://www.cpubenchmark.net/compare/6304vs6617/Intel-N150-v...
I can't speak to why other people bring up the N150 in ARM SBC threads any more than "AMD doesn't compete in the ~$200 SBC segment".
FWIW, as far as SBC/NUCs go, I've had a Pi 4, an RK3399 board, an RK3568 board, an N100 NUC from GMKTec, and a N150 NUC from Geekom, and the N150 has by far been my favorite out of those for real-world workloads rather than tinkering. The gap between the x86 software ecosystem and the ARM software ecosystem is no joke.
P.S. Stay away from GMKTec. Even if you don't get burned, your SODIMM cards will. There are stoves, ovens, and hot plates with better heat dissipation and thermals than GMKTec NUCs.
ARM SBCs that cost over $90 are totally not worth it considering those Nxxx options exist
1 reply →
> BTW what's up with people pushing N150 and N300 in every single ARM SBC thread?
For 90% of use cases, ARM SBCs are not appropriate and will not meet expectations over time.
People expect them to be little PCs, and intend to use them that way, but they are not. Mini PCs, on the other hand, are literally little PCs and will meet the expectations users have when dealing with PCs.
x86 based small computers are just so much easier to work with than most second- and third-string ARM vendors. The x86 scene has had standards in place for a long time, like PCIe and the PC BIOS (now UEFI) for hardware initialization and mapping, that make it a doddle to just boot a kernel and let it get the hardware working. ARM boards don't have that yet, requiring per-board support in the kernel which board manufacturers famously drag their feet on implementing openly let alone upstreaming. Raspberry Pi has its own setup, which means kernel support for the Pi series is pretty good, but it doesn't generalize to other boards, which means users and integrators may be stuck with whatever last version of Ubuntu or Android the vendor thought to ship. Which means if you want a little network appliance like a router, firewall, Jellyfin server, etc. it often makes more sense to go with an N150 bitty box than an ARM SBC because the former is going to be price- and power-draw-competitive with the latter while being able to draw on the OS support of the well-tested PC ecosystem.
ARM actually has a spec in place called SystemReady that standardizes on UEFI, which should make bringup of ARM systems much less jank. But few have implemented it yet. I keep saying, the first cheap Chinese vendor that ships a SystemReady-compliant SBC is gonna make a killing.
3 replies →
1. Wow, never thought I'd need to do an investment disclosure for an HN comment. But sure thing: I'm sure Intel is somewhere in my 401K's index funds, but also probably Qualcomm. But I'm not a corporate shill, thank you very much for the good faith. Just a hobbyist looking to not get seduced by the lastest trend. If I were an ARM developer that'd be different, I get that.
2. The review says single core Geekbench performance is 1290, same as i5-10500 which is also similar to N150, which is 1235.
3. You can still get N150s with 16gb ram in a case for $200 all in.
4 replies →
No idea - the ryzen based ones are better!
1 reply →
Yes x86 will win for convenience on about every metric (at least for now), but this SoC's CPU is much faster than a mere Intel N150 (especially for multicore use cases).
I've got i3 and i5 systems that do 15W or better idle, and I don't have to worry about the absolute clusterfuck of ARM hardware (and those systems used can be had for less and will probably long outlive mystery meat ARM SBCs).
1 reply →
Agreed, at least for a likely "home use" case, such as a TV box, router, or general purpose file server or Docker host, I don't see how this board is better than something like a Beelink mini PC. The Orange Pi does not even come with a case, power supply or cooler. Contrast that with a Beelink that has a built-in power supply (no external brick) and of course a case and cooler.
This OrangePi 6 Plus board comes with cooling and a power supply (usb-c). No case, though.
2 replies →
It allows you to build for what is coming. In a couple of years arm hardware this powerful will cheap and common.
I feel like SBC stuff hasn't been worth it over x86 boxes like that for awhile now. Other than the GPIO being useful in certain use cases.
N100 boxes are cheap and use so little power, while having normal OS support and boot setup.
I've got two RK3588 boards here doing Linux-y things around my place (Jellyfin, Forgejo builders, Immich, etc) and ... I don't think I've run into pain? They're running various debian and just ... work? I can't think of a single package that I couldn't get for ARM64.
Likewise my VPS @ Hetzner is running Aarch64. No drama. Only pain is how brutal the Rust cross-compile is from my x86 machine.
I mean, here's Geerling running a bunch of Steam games flawlessly on a Aarch64 NVIDIA GB10 machine: https://www.youtube.com/watch?v=FjRKvKC4ntw
(Those things are expensive, but I just ordered one [the ASUS variant] for myself.)
Meanwhile Apple is pushing the ARM64 architecture hard, and Windows is apparently actually quite viable now?
Personally... it's totally irrational, but I have always had a grudge against x86 since it "won" in the early 90s and I had to switch from 68k. I want diversity in ISAs. RISC-V would be nice, but I'll settle for ARM for now.
the high end of the performance is impressive and this has idle power similar to the processors in it's performance range(AMD Ryzen 7 4800H idles at 45W). This is certainly not meant for lower power computing.
i use the rpi zero 2 for the IO pins
4b / 5 for the camera stuff.
i don’t think using these boards for just compute makes a lot of sense unless it’s for toy stuff like an ssh shell or pihole
We need an acronym for these types of boards: Yet Another SBC With Poor Longterm Support. YASBCWPLS. Really rolls off the tongue.
Or we should just have "STS" (Short Term Support) after the board names to let others know the board will be essentially obsolete (based on lack of software updates) in two months.
> We need an acronym for these types of boards: Yet Another SBC With Poor Longterm Support. YASBCWPLS.
Deadend is how I describe it.
STS - Shit Tier Support
Without mainline Linux support I have no interest in these more obscure SBCs. Mainline Linux is the bare minimum, put in some effort please manufacturers.
Note that this is also happening with Nvidia and the Jetson boards.
Buying one of these Pi knockoffs taught me one thing, software support is the key to raspberry pi’s success.
Whenever I would have a problem, and it was more often than not, I would search for a solution and come across something that worked for rpi that I could try to port across.
Double the hardware spec matters little if you can’t get the software to even compile
> Double the hardware spec matters little if you can’t get the software to even compile
You can get any software to compile on this SBC. On the Raspberry Pi platform you usually don't need to compile anything.
When something has an 30 TOPS NPU, what are the implications? Do NPUs like this have some common backend that ggml/llama.cpp targets? Is it proprietary and only works for some specific software? Does it have access to all the system RAM and at what bandwidth?
I know the concept has been around for a while but no idea if it actually means anything. I assume that people are targeting ones in common devices like Apple, but what about here?
NPUs like this tend to have one thing in common: being decorative without drivers and support 9 times out of 10.
Even if it worked though, they're usually heavily bandwidth bottlenecked and near useless for LLM inference. CPU wins every time.
Can't speak to this specific NPU but these kind of accelerators are really made more for more general ML things like machine vision etc. For example while people have made the (6 TOPS) NPU in the (similar board) RK3588 work with llama.cpp it isn't super useful because of the RAM constraints. I believe it has some sort of 32-bit memory addressing limit, so you can never give it more than 3 or 4 GB for example. So for LLMs, not all that useful.
Ignorant of this NPU, but in my experience, you're expected to use some cursed stack of proprietary tools/runtimes/SDKs/etc and no, it will not play nicely with anything you want it to unless you write the support yourself.
30 TOPS NPU is the almost-useful minimum for a device, but as we've seen that even microsoft couldn't come up with anything useful to do with it in the AI laptops. This has all but disappeared, they are pushing the cloud licensing over local AI now
The specific NPU doesn't seem to be mentioned in TFA, but my guess is that the blessed way to deal with it is the Neon SDK: https://www.arm.com/technologies/neon
I've not found Neon to be fun or easy to use, and I frequently see devices ignoring the NPU and inferring on CPU because it's easier. Maybe you get lucky and someone has made a backend for something specific you want, but it's not common.
TFA does directly mention the NPU "Arm-China Zhouyi: 30 TOPS (Dedicated)"
"you cannot simply use standard versions of PyTorch or TensorFlow out of the box. You must use the NeuralONE AI SDK."
Neon is a SIMD instruction set for the CPU, not a separate accelerator. It doesn't need an SDK to use, it's supported by compiler intrinsics and assembly language in any modern ARM compiler.
1 reply →
It needs specific support, and for example llama.cpp would have support for some of them. But that comes with limitations in how much RAM they can allocate. But when they work, you see a flat CPU usage and the NPU does everything for inference.
I'm not sure I'm gonna grab another OrangePi board again. I was happy to grab the RV2 just to experiment around with, but I didn't realize that the linux kernel they provided to build their ubuntu distro doesn't actually build properly. I got it to build after throwing a version of ubuntu onto an unused pc, but then it didn't matter the options I selected for the build (like gui options) it seemed like the gui just didn't exist at all in the final binary. I've yet to try and build a 3rd party os with support since I spent so much time just trying to get the official distro to work properly.
e-*ing-waste if you have to wait for manufacturer to provide supported images.
Upstream the drivers to the mainline kernel or go bankrupt. Nobody should buy these.
this. Warning: do not buy any SBC without mainline kernel support, or if you have to download an unverified image from a google drive.
I think the sweet spot for ARM SBCs are smaller, less powerful and cheaper for headless IOT edge cases. I use a couple of them that way when I need LAN connectivity, either by ethernet or wifi, and things wired to GPIO pins. I don't need a powerful CPU or lots of RAM for that. The SBC makers are caught up in a horsepower race and I just shrug, it's not for me.
This is my experience as well. I have a couple PINE64 devices, a Rock64 (Rockchip RK3328) and a RockPro64 (RK3399). And an N150 device.
Both ARM64 devices run headless, make use of GPIO, and have more than enough CPU. In fact, these are stable enough that I run BSDs on them and don't bother with Linux.
The Rock64 runs FreeBSD for SDR applications (e.g. ADS-B receiver). FreeBSD has stable USB support for RTL-SDR devices.
The RockPro64 runs NetBSD with ZFS with a PCIe SSD. NetBSD can handle ARM big.LITTLE well. I run several home lab workloads on this. Fun device.
I also have an N150 device running the latest Debian 13 as my main home lab server for home automation, Docker, MQTT broker, etc.
In short: SBCs are cheap enough that you can choose more than one, each for the right task, including IoT.
I'm setting up to run an APRS iGate. Is Rock64 a decent alternative to Pi with Linux?
Unfortunately, this board seems to be using the CIX CPU that has power management issues:
> 15W at idle, which is fairly high
I have a pre-Ryzen AMD thin client which draws MAXIMUM 10W. Idle 5W. A lot less CPU power but still. 15W for a modern SBC is a joke.
For comparison, an N150 mini PC uses around 6 watts at idle.
And here I was thinking the Pi 5 which idles at 3W was unreasonably high.
How are we still in a world where there are breathless, hand-waving blog posts written about the theoretical potential of super-fast SBCs for which the manufacturer shows fuck all interest in competent OS support?
Yet again, OrangePi crank out half-baked products and tech enthusiasts who quite understandably lack the deep knowledge to do more than follow others' instructions on how to compile stuff talk about it as if their specifications actually matter.
Yet again the HN discourse will likely gather around stuff like "why not just use an N1x0" and side quests about how the Raspberry Pi Foundation has abandoned its principles / is just a cynical Broadcom psyop / is "lagging behind" in hardware.
This stuff can be done better and the geek world should be done excusing OrangePi producing hardware abandonware time after time. Stop buying this crap and maybe they will finally start focussing on doing more than shipping support for one or two old kernels and last year's OS while kicking vague commitments about future support just far enough down the road that they can release another board first.
Please stop falling for it :-/
ETA: I think what grinds my gears the most is that OrangePi, BananaPi etc., are largely free-riding off the Linux community while producing products that only "beat" the market-defining manufacturers (Raspberry Pi, BeagleBoard) because they treat software support as an uncosted externality.
This kind of "build it and they will use it" logic works well for microcontrollers, where a manufacturer can reasonably expect to produce a chip with a couple of tech demos, a spec sheet and a limited C SDK and people will find uses for it.
But for "near-desktop class" SBCs it is not much better than misrepresentation. Consequently these things are e-waste in a way that even the global desk drawer population of the Raspberry Pi does not reach.
And yet they are graded on a curve and never live up to their potential.
What is wrong with BananaPi? My understanding is it used for the basis for the OpenWRT community flagship router.
I wouldn’t be surprised if it performs adequately in this context —- isn’t the manufacturer a VOIP device maker?
The reality is that they spam the market with a large number of products with little consistency, poor (if labyrinthine) documentation, random google drive links for firmware etc., and there are the same issues with hardware support.
I dunno, maybe the situation there is better than it was. But the broad picture is the same: better hardware but you are basically on your own.
Mark my words, 2026 will be the year that vendors finally start taking ARM seriously!
Their approach to software support does leave a lot to be desired.
For what it's worth though the v5 did have Talos support, so you could just throw that on there, connect it to a cluster and have a decent arm node that is fanless and has 32gb
https://docs.siderolabs.com/talos/v1.12/platform-specific-in...
My Orange Pi RV2 sucks :( The available distros, drivers, kernel, and tools do work, but they’re crappy, and poorly maintained. There’s no support and very little documentation, which is a real shame. From a hardware point of view, it’s a nice board and when I properly compiled some softwares myself I actually got really interesting performance, but it was a pain in the ass. So I ended up buying a Raspberry Pi 4, much better supported and documented.
I have a software that need to build aarch64 (for some aarch64 box with 4 core cpu), currently using Oracle cloud's 4core24G Arm neoverse n1 as github self host runner to build it.
Seems this machine is more powerful than it, definitely attractive to me for a physical aarch64 self host runner.
I am newly interested in Compute Module style SBCs after I bought a one to toy around with. I was surprised to learn that the PCBs that interface to them are open specs and I can probably build myself more custom PCB solutions to match different form factors instead of being stuck with a bulky normal Raspberry Pi.
I was pleased to learn that Radxa and Orange Pi have compatible similar boards.
I have wanted to see more RISC SBCs so I may toy with these but I rather wait for the software support to get much richer.
I'm still using the Orange Pi 3 LTS. It's been two years, I've managed to move to another city, and she's still in service. I use it mainly for testing my amateur projects, nothing more. Linux distributions (Debian, Ubuntu) from Xunlong are just terrible. I don't remember why, but I didn't like them. But Armbian has been running on such a computer for almost two years. Well, I love OPi ^)
I am not a kernel developer, so I don't really have any idea what this means, but CIX appears to have patches in the Linux kernel[0], so I assume mainlining more stuff is in the works?
[0] https://lwn.net/ml/all/20250609031627.1605851-1-peter.chen@c...
That is correct.
Why bother with these obscure boards with spotty software support when you can get a better deal all around with an x86 mini PC with a N150 CPU?
Exactly! Just grab a mini PC such an Optiplex, it will be so much better.
I bought a used thinkcentre tiny off of eBay. It's got great GPU decoding/encoding support, great driver support for all the peripherals, and can boot from an m2 NVME or a SATA drive, it has a very normal bootloader. It can even run Windows. The mostly-aluminum enclosure is very nice and well-engineered, it's easy to pop open, it has a power button. It was under $100 and makes me question why any hobbyist bothers with SBCs like these.
> at the beginning, my OrangePi did not boot ... Turns out that the firmware required an update to be able to boot
No thanks.
What is the Real World use case for dual 5Gbit/s Ethernet ports? I just don't understand how a relatively underpowered board could ever make good use of (combined) 10Gbit/s Ethernet bandwidth. Is this strictly bragging rights?
Prices are considerably higher through the links than quoted in the article. This usually happens when someone posts about a great deal for surplus hardware on Ebay or a hidden gem on aliexpress. Just the thundering herd of traffic causes algorithmic pricing to spike the price.
I was in the market for cheaper sbc with npu and ended up using orange pi.
Raspberry pi with ai hat was basically useless as i was not able to convert my neural networks to halio npu format.
The software looked horrendous and felt, but it ended up working surprisingly well
Is the orangePi 6 plus really almost 4x as fast as an intel n100?
There are faster Intel chips though.
i really with raspberry pi foundation released a pi with built in nvme instead of using a hat. i think using flash memory is the true bottleneck on the system
Heh, I'm the opposite. I wish the rpi stayed the course of cheapest "working" SBC, and move their high-end boards to a different brand. Raspberry Sigma, or 67 or whatever gets the younguns crazy these days.
After the pandemic, the "25$" SBC suddenly became 100+ with low availability. The main thing that made rpis worth it is gone now, and they're all chasing number go up on benchmarks.
I hear you. There is obviously a lot of tension between price and performance. I think the introduction of boards with larger and larger ram specs really pushed the cost just before the pandemic and then scarcity spiked things even more. As when I purchased the rpi4, I got the maximum RAM and that became expensive.
However, SD Cards are really terrible devices to run a general purpose computer on and they are designed for storing large files like photos, videos and mp3’s sequentially not the SWAP, logs, and databases that a full operating system is constantly writing and accessing in a random fashion.
I think if you are running a base 2gb, then maybe absolute value makes sense, but once you start hitting the larger RAM configutations, an M2 slot is a no brainer.
I think the cheapest working SBC is really the zero line.
The 500+ model has NVMe storage and comes with a 256GB drive.
It is still achieved with an add-on and not integrated into the board.
1 reply →
I thought the /. effect was to hug a site to death, not cause the price of the product under review to skyrocket. I see $414 instead of $258 now!
This happens with algorithmic marketplaces.
Weird article: it compares with raspberry pi 5 instead of OrangePi 5 Plus, the predecessor.
Actually the Orange Pi 5 Ultra would be the most recent board from Orange Pi to compare it with. You can see a comparison between the Orange Pi 5 Ultra and the Raspberry Pi 5 here: https://boilingsteam.com/orange-pi-5-ultra-review/
In a nutshell, this new Orange Pi 6 Plus is much faster than Orange Pi 5 Ultra and anything that came before.
Plus and ultra are almost identical with the exception of an HMDI in port on the latter. I've used the same HAL on both boards, they are effectively the same.
Wow this website just keep crashing my firefox, like 3 times in a row
Which version of Firefox and OS are you on?
146.0 (Build #2016129543) on Android.
How yo trigger: just follow the link, and start scrolling down. Totally reproducible, just did it again
Yet another board which will never have proper upstream support because the SoC vendor refused to implement the ARM BSA standard which would provide EFI/ACPI support instead of relying on undiscoverable devices only exposed through device tree. ACPI isn't perfect but it's way better than device trees which are seldom updated so the device will remain stuck with old kernels.
Devicetree continues to be a massive crutch for arm soc vendors.
Does uboot work on this?
I have the itx board from radxa. This CIX chip is a disappointment, you'll never see the 2.8ghz.
> you'll never see the 2.8ghz.
What do you mean?
It was originally sold as 2.8ghz but never actually could hit 2.8ghz. after some complaints on the forums they reduced the advertised frequency to 2.6ghz.
Cool. Somebody put it in a laptop please.
The half baked hardware comments are humerous, because pretty much any piece of software is half baked if we are lucky.