It would be nice if the software weren't terrible and they properly make linux kernel contributions to make their product usable. Every chinese soc that comes out is a broken experience out of box, rpi is about the only vendor that supports their product adequately. Until this changes, these chips will always be nothing more than a novelty and simple money grab left dumbfounded at why they failed so painfully.
Most of these chips have perfectly fine Linux kernel support, it just comes more from the community rather than the vendor, and that is a common practice among pretty much all manufacturers other than the Raspberry PI Foundation. Just pick the distribution that suits your needs. Either the usual ones that already support the ARM architecture (Debian, Alpine, etc) or others specifically made for embedded systems such as Armbian and DietPI. Hardware support is a moving target; if your board doesn't appear there today, check the forums, then return in a week. The amount of work these folks are doing is amazing and well worth of donations and other contribution.
Using a distribution developed by the community is a lot better than relying from the vendor: no planned obsolescence because the vendor wants to sell the latest board, and great integration between different boards from different manufacturers. Of course that means some more time to wait until support by the community reaches a stable state, which I concur can be a subjective problem; not a huge one however.
I wrote that there's no lack of support due to planned obsolescence, which is very different. Of course the community too eventually moves on, but that usually happens a lot later than the product goes out of production.
Honestly, the StarFive VisionFive 2 RISC-V based board is approaching, or maybe even beyond that reality. It is only slightly more expensive than the Pi 4, is almost just as fast, has way more IO options, is completely open source, and has Ubuntu support coming soon, Debian, etc. I preordered one after the kickstarter, so I guess I'll see how it adds up. I will try to add my thoughts here when I receive it.
Please do. I worked on the Hifive board and was depressed with how expensive it was. StarFive's been coming on strong and I really want to like their products.
I have three SystemReady arm devices and it's pretty awesome to be able to just boot an aarch64 live ISO and install. The experience is the same for running vms via ESXi arm edition.
It can be tedious building/provisioning the firmware but once complete they are ready for any aarch64 uefi iso.
What is annoying however is when distros don't ship an aarch64 uefi iso - but instead choose to build a zillion device specific "preinstalled" arm images. (looking at you manjaro)
The list of supported devices for ESXi arm edition is a great place to start for identifying options and is constantly updated.
I'm really hoping the PINE64 Quartz64 continues improving its support (I'm looking forward to getting my boards hooked up with a bootloader testing CI pipeline) the progress getting it to use stock UEFI/SystemReady has been good.
The current RPi shortage really highlights the need for multiple cheap(ish), widely available, and well enough supported ARM boards if we want to have a healthy ecosystem for hobby/tinkerers.
Alternative take: Linux could finally create a stable driver ABI so that drivers compiled in 1999 still work with the latest kernel without recompiling, as is with Windows. Until then only the most main-stream devices will be supported.
Alternativer take: vendors should get their drivers upstreamed so they don't have to maintain them much. Of course, this also means publishing decent hardware documentation which they should be doing regardless.
Windows did have and to some extent still has many crappy, old drivers that reduce system stability. We don't need to encourage that on Linux.
> Alternativer take: vendors should get their drivers upstreamed so they don't have to maintain them much
This is ideology. In real-life, some OEMs are binded by NDAs (so they can't do all what they'd like), and the split between hardware and software is quite blurry (chipset vendors don't want to disclose their secrets by open-sourcing their code).
I wish like you that more code would be supported in mainline kernel (just as I wish every single board would support SystemReady/UEFI or any similar solution (ideally more lightweight) so that they could boot a generic kernel just like x86 does (and regardless of the availability of the proper dts for this specific board, which may be hard to download after several years)). But this is not the world we live in.
Because of this "stable-api-nonsense" ideology, we end up with piles of junk (e.g. all old smartphones and boards that become unsupported after 2-3 years... and we only have one planet !) while we can still easily use 10-15 years-old PCs.
What is in it for the maintainers who would then have to support hardware they do not neccessarly have access to, adding development time to the linux kernel maintainers who honestly would be better off spending their time improving linux further instead of supporting potentially thousands of users at best?
Imo the responisibility lies with the hardware vendors. Sell your hardware with working software, and support it for x years guaranteed. When the support period ends they can decide to extend it (they wont, but they could) instead of relying on developers who have nothing to do with the product and are working for free for the hardware vendor.
Either that or contract kernel maintainers to upstream it for x years and they do the heavy lifting, but that's always going to be more expensive than doing it in-house.
This is exactly what I am struggling with as well - what's the point of having it in the upstream, when developers CAN'T TEST THE DRIVER WITH THE DEVICE.
Just provide some stable API for drivers and let hardware developers do their job. Microsoft Windows understood this, why is it so difficult for Linux Kernel do get the memo.
Make it open source, let it be merged in the Linux kernel, and be happy.
I don't want windows and exactly this outdated shit. I want Linux and vendors that understand, that software is part of their job if they want to sell me hardware.
rockchip does a fine job of getting stuff upstream, actually.
The vendor-specific device trees are not always upstreamed, but you can compile a mainline kernel post-rk3588 release and have it work with the right device tree.
5V 4A is not really part of the USB PD specification. I mean, sure, you can do it with PPS but you bet it's not that but something nonstandard where it just pulls 4A instead of the standard 3A yolo style.
At the specs and price, I found it to be very competitive with the Raspberry Pi 4, and it may even be more accessible for most people considering RPi's are still in high demand.
Didn't downvote but I've owned most of the OrangePi models over the years. Many of them require you to run their non-mainline kernels because of drivers that aren't upstreamed (and likely cannot be due to quality issues), and they never really update those kernels. It's quite annoying. Nowadays for routers and other utility boxen I often use Intel NUCs which are a bit more expensive but much more pleasant to work with (decent UEFI firmware, perfect mainline kernel support, etc).
The RK3399 is indeed a great chip. I have an OrangePi RK3399 sitting on my desk right now in fact. But (at least when I last tried, last year) the mainline kernel support for the OrangePi RK3399 isn't really there beyond booting, and the board documentation is poor-to-non-existent so it's unlikely to improve.
FWIW I've been building a product on top of Orange Pi Ones (a $20 SBC roughly comparable to Raspberry Pi 2) with Armbian and while I have to dig into the forums for certain configurations (enabling hardware serial is an edit to /boot/armbianEnv.txt, while switching the micro USB port from OTG to HOST mode is an edit to a file within armbian-config) it's been a smooth development experience with about 10 days lead time from Shenzhen via AliExpress
I own a RBP and several mini computers. I once had to set an office up with network scanners which didn’t have integrated networking. Otherwise, over the many years, I never actually found a use for these.
When I need an experimental box I usually setup a droplet on Digital Ocean or a local VM.
Can someone speak to their experience with these Raspberry Pi-style SBCs? I'm curious, in particular, if their performance actually aligns with their on-paper specs and how reliable they are.
Janky long term kernel driver support. Essentially you get a minimally functional SBC OS, and then have to buy another SBC a year later as the kernel developers find something more interesting to work on.
The Pi are not just the hardware, but foundation and community maintained OS too.
A functional Pi GPU took herculean effort (hardware codecs etc.), and years of dedicated people trying to get mystery binary-blobs to work. I think the beagleboard are pretty good too, but have nowhere near the user-base of the pi.
Many people are now upcycling low-power micro PC thin clients, as they refuse to get price gouged for a pi4.
They usually perform well, but get put in a drawer and forgotten about because the software compatibility is generally atrocious. Peripherals advertised generally never work, but you know, might in a future kernel. I've been burned enough that I've sworn to never buy a SBC no matter the specifications.
That's good to know, thanks. I've had pretty good luck over the years with ordinary RPis (I keep a couple around for random projects); the most serious problem I ever have with them is the long-standing one around slow SD card corruption.
The RPI is sort of the exception; I have a couple of them doing odd tasks around the house like displaying security cameras, but that's an outlier due to the massive amount of support it gets.
In boxes in the basement are all sorts of SBCs, from the original A10 Cubieboard from 2012, to many Hardkenel boards, to all sorts of bizarre barely operational SBCs from various sources. They all had the same issue of being basically unsupported unless you made it your life goal to dig through obscure datasheets and compile kernel patches from some forum post you found.
A good holistic replacement for the RPI is the APU2, a x86 board of similar cost that has a bunch more peripherals, real support for booting from SATA, ECC memory, and that sort of thing. Absolutely no video support, but I have years of uptime on the things with no issue.
Thinking about how much ewaste all those clone sbcs must amount to makes me sad. I fell for some pi zero clone too about three years ago and it ended up the same. Meanwhile my original pi (the 512mb variant) is still running Kodi on my main TV.
I upgraded from the x86-amd64 Mac Mini to Rpi 4Gb then 8Gb. Changing from the default window manager to KDE really made the pixels easy on the eyes.
Compiling from source code products like GNU Emacs, SBCL, Racket Lang IDE, TeX, Graphviz sorts of things is a breeze. I don't feel like I am being pushed around like China's Foxconn hires subcontracted to Apple that's looking to buy the Man. U's soccer/football hooligan fanbase.
The FLASH storage medium is unreliable on the Rpi, I know, but I haven't got around to finding something faster and durable and easily replaceable. Samsung has durable external USB devices from what the advertising says.
There are times on the Rpi when the cpu load shoots up, I guess that is due to Garbage In Garbage Out website JS stealing cpu cycles to mine tokens.
I paid $5 for the $50 discount on the 16Gb RockX5B Radxa but by the time they got around to updates on supply I had lost the coupon discount code. Threw it out in the old email box.
Performance wise they are fine, particularly the RK3588 series.
If you want to keep up to date, you will have to do some work.
If you want a seamless experience, use an x86 SBC, they work great, never worry about kernel support, etc.
You will pay for it in performance for watt.
(IE 5 watt rk3588 vs 15 watt pentium J6412)
There are vendors who seem to care a lot, like Radxa (who makes the rockpi series), and others for whom the sbc offering is basically a test kit for their android tablet SOC's.
Just get an Intel based SBC, they're around the same price and don't come with endless headaches because they don't rely on ancient kernel forks that will never have their changes upstreamed.
Edit: I should say x86 SBCs because there are AMD and other x86 SoCs out there.
Get a used NUC if you're not in for the gpio etc. Check power specs first. I've set up a Fujitsu NUC a few weeks ago for my parents as a print server and syncthing node. After enabling link power saving for the SSD it's sitting at 5W idle with headless Debian.
It would be nice if the software weren't terrible and they properly make linux kernel contributions to make their product usable. Every chinese soc that comes out is a broken experience out of box, rpi is about the only vendor that supports their product adequately. Until this changes, these chips will always be nothing more than a novelty and simple money grab left dumbfounded at why they failed so painfully.
Most of these chips have perfectly fine Linux kernel support, it just comes more from the community rather than the vendor, and that is a common practice among pretty much all manufacturers other than the Raspberry PI Foundation. Just pick the distribution that suits your needs. Either the usual ones that already support the ARM architecture (Debian, Alpine, etc) or others specifically made for embedded systems such as Armbian and DietPI. Hardware support is a moving target; if your board doesn't appear there today, check the forums, then return in a week. The amount of work these folks are doing is amazing and well worth of donations and other contribution.
https://www.armbian.com/download/?device_support=Supported
https://dietpi.com/#download
Using a distribution developed by the community is a lot better than relying from the vendor: no planned obsolescence because the vendor wants to sell the latest board, and great integration between different boards from different manufacturers. Of course that means some more time to wait until support by the community reaches a stable state, which I concur can be a subjective problem; not a huge one however.
> Most of these chips have perfectly fine Linux kernel support, it just comes more from the community rather than the vendor
So you mean no actual support and bug fix is pretty much never once the community moved on.
"The community" is not a magic bullet.
I wrote that there's no lack of support due to planned obsolescence, which is very different. Of course the community too eventually moves on, but that usually happens a lot later than the product goes out of production.
Honestly, the StarFive VisionFive 2 RISC-V based board is approaching, or maybe even beyond that reality. It is only slightly more expensive than the Pi 4, is almost just as fast, has way more IO options, is completely open source, and has Ubuntu support coming soon, Debian, etc. I preordered one after the kickstarter, so I guess I'll see how it adds up. I will try to add my thoughts here when I receive it.
Please do. I worked on the Hifive board and was depressed with how expensive it was. StarFive's been coming on strong and I really want to like their products.
I'm very excited! Got it for myself as an Christmas gift.
My only concern is the PCB quality looked poor but they were pre-production models.
Do you know if it has Tensorflow support?
I might order one of these for a Mycroft unit.
I'm guessing these are not SystemReady certified with UEFI firmware and require "bespoke" preinstalled arm images?
https://www.arm.com/architecture/system-architectures/system...
https://developer.arm.com/documentation/102677/0100/UEFI-req...
I have three SystemReady arm devices and it's pretty awesome to be able to just boot an aarch64 live ISO and install. The experience is the same for running vms via ESXi arm edition.
Nvidia Jetson AGX Xavier - https://developer.nvidia.com/embedded/downloads#?search=uefi
Honeycomb LX2 - https://github.com/SolidRun/lx2160a_uefi
RPI4 - https://github.com/pftf/RPi4
It can be tedious building/provisioning the firmware but once complete they are ready for any aarch64 uefi iso.
What is annoying however is when distros don't ship an aarch64 uefi iso - but instead choose to build a zillion device specific "preinstalled" arm images. (looking at you manjaro)
The list of supported devices for ESXi arm edition is a great place to start for identifying options and is constantly updated.
https://flings.vmware.com/esxi-arm-edition
I'm really hoping the PINE64 Quartz64 continues improving its support (I'm looking forward to getting my boards hooked up with a bootloader testing CI pipeline) the progress getting it to use stock UEFI/SystemReady has been good.
The current RPi shortage really highlights the need for multiple cheap(ish), widely available, and well enough supported ARM boards if we want to have a healthy ecosystem for hobby/tinkerers.
Alternative take: Linux could finally create a stable driver ABI so that drivers compiled in 1999 still work with the latest kernel without recompiling, as is with Windows. Until then only the most main-stream devices will be supported.
Alternativer take: vendors should get their drivers upstreamed so they don't have to maintain them much. Of course, this also means publishing decent hardware documentation which they should be doing regardless.
Windows did have and to some extent still has many crappy, old drivers that reduce system stability. We don't need to encourage that on Linux.
> Alternativer take: vendors should get their drivers upstreamed so they don't have to maintain them much
This is ideology. In real-life, some OEMs are binded by NDAs (so they can't do all what they'd like), and the split between hardware and software is quite blurry (chipset vendors don't want to disclose their secrets by open-sourcing their code).
I wish like you that more code would be supported in mainline kernel (just as I wish every single board would support SystemReady/UEFI or any similar solution (ideally more lightweight) so that they could boot a generic kernel just like x86 does (and regardless of the availability of the proper dts for this specific board, which may be hard to download after several years)). But this is not the world we live in.
Because of this "stable-api-nonsense" ideology, we end up with piles of junk (e.g. all old smartphones and boards that become unsupported after 2-3 years... and we only have one planet !) while we can still easily use 10-15 years-old PCs.
> This is ideology. In real-life, some OEMs are binded by NDAs (so they can't do all what they'd like)
This can be solved by offering a binary firmware, can it not?
What is in it for the maintainers who would then have to support hardware they do not neccessarly have access to, adding development time to the linux kernel maintainers who honestly would be better off spending their time improving linux further instead of supporting potentially thousands of users at best?
Imo the responisibility lies with the hardware vendors. Sell your hardware with working software, and support it for x years guaranteed. When the support period ends they can decide to extend it (they wont, but they could) instead of relying on developers who have nothing to do with the product and are working for free for the hardware vendor.
Either that or contract kernel maintainers to upstream it for x years and they do the heavy lifting, but that's always going to be more expensive than doing it in-house.
This is exactly what I am struggling with as well - what's the point of having it in the upstream, when developers CAN'T TEST THE DRIVER WITH THE DEVICE. Just provide some stable API for drivers and let hardware developers do their job. Microsoft Windows understood this, why is it so difficult for Linux Kernel do get the memo.
Why do these things have to be mutually exclusive?
They already hire kernel hackers to build their drivers and bespoke images in the first place.
Make it open source, let it be merged in the Linux kernel, and be happy.
I don't want windows and exactly this outdated shit. I want Linux and vendors that understand, that software is part of their job if they want to sell me hardware.
rockchip does a fine job of getting stuff upstream, actually.
The vendor-specific device trees are not always upstreamed, but you can compile a mainline kernel post-rk3588 release and have it work with the right device tree.
http://www.orangepi.org/img/pi-5-top-view.png
5V 4A is not really part of the USB PD specification. I mean, sure, you can do it with PPS but you bet it's not that but something nonstandard where it just pulls 4A instead of the standard 3A yolo style.
Presumably some of that 4A would be for USB peripherals anyway? It seems likely that 3A is sufficient if you're not drawing much from those.
At the specs and price, I found it to be very competitive with the Raspberry Pi 4, and it may even be more accessible for most people considering RPi's are still in high demand.
This comment seems reasonable to me but is getting downvoted without reply. What am I missing in the parent’s remarks?
Didn't downvote but I've owned most of the OrangePi models over the years. Many of them require you to run their non-mainline kernels because of drivers that aren't upstreamed (and likely cannot be due to quality issues), and they never really update those kernels. It's quite annoying. Nowadays for routers and other utility boxen I often use Intel NUCs which are a bit more expensive but much more pleasant to work with (decent UEFI firmware, perfect mainline kernel support, etc).
Armbian and similar communities have worked hard to mainline Allwinner and Rockchip SOCs kernel drivers.
Note that this boards SOC is about 3x faster than a Raspberry Pi 4 https://www.reddit.com/r/linuxhardware/comments/r60lcp/rk358...
The RK3399 is indeed a great chip. I have an OrangePi RK3399 sitting on my desk right now in fact. But (at least when I last tried, last year) the mainline kernel support for the OrangePi RK3399 isn't really there beyond booting, and the board documentation is poor-to-non-existent so it's unlikely to improve.
FWIW I've been building a product on top of Orange Pi Ones (a $20 SBC roughly comparable to Raspberry Pi 2) with Armbian and while I have to dig into the forums for certain configurations (enabling hardware serial is an edit to /boot/armbianEnv.txt, while switching the micro USB port from OTG to HOST mode is an edit to a file within armbian-config) it's been a smooth development experience with about 10 days lead time from Shenzhen via AliExpress
I own a RBP and several mini computers. I once had to set an office up with network scanners which didn’t have integrated networking. Otherwise, over the many years, I never actually found a use for these.
When I need an experimental box I usually setup a droplet on Digital Ocean or a local VM.
Someone already mentioned PiHole, so I'll just second that use. I've been using one of my Pis as a PiHole for years, and it's been great.
I also use another Pi to control my sound system[1].
[1]: https://blog.yossarian.net/2022/11/07/Modernizing-my-1980s-s...
RBPs are good for unbound DNS server or a PiHole setup.
Quite some alternative: - Khadas Edge 2 -> https://www.khadas.com/edge2
Can someone speak to their experience with these Raspberry Pi-style SBCs? I'm curious, in particular, if their performance actually aligns with their on-paper specs and how reliable they are.
Janky long term kernel driver support. Essentially you get a minimally functional SBC OS, and then have to buy another SBC a year later as the kernel developers find something more interesting to work on.
The Pi are not just the hardware, but foundation and community maintained OS too.
A functional Pi GPU took herculean effort (hardware codecs etc.), and years of dedicated people trying to get mystery binary-blobs to work. I think the beagleboard are pretty good too, but have nowhere near the user-base of the pi.
Many people are now upcycling low-power micro PC thin clients, as they refuse to get price gouged for a pi4.
They usually perform well, but get put in a drawer and forgotten about because the software compatibility is generally atrocious. Peripherals advertised generally never work, but you know, might in a future kernel. I've been burned enough that I've sworn to never buy a SBC no matter the specifications.
That's good to know, thanks. I've had pretty good luck over the years with ordinary RPis (I keep a couple around for random projects); the most serious problem I ever have with them is the long-standing one around slow SD card corruption.
The RPI is sort of the exception; I have a couple of them doing odd tasks around the house like displaying security cameras, but that's an outlier due to the massive amount of support it gets.
In boxes in the basement are all sorts of SBCs, from the original A10 Cubieboard from 2012, to many Hardkenel boards, to all sorts of bizarre barely operational SBCs from various sources. They all had the same issue of being basically unsupported unless you made it your life goal to dig through obscure datasheets and compile kernel patches from some forum post you found.
A good holistic replacement for the RPI is the APU2, a x86 board of similar cost that has a bunch more peripherals, real support for booting from SATA, ECC memory, and that sort of thing. Absolutely no video support, but I have years of uptime on the things with no issue.
Worth noting that by "of a similar cost" you mean the insane scalper prices (£175), not the £35 a Raspberry Pi ought to cost.
Mount SDs with "noatime" option :)
Thinking about how much ewaste all those clone sbcs must amount to makes me sad. I fell for some pi zero clone too about three years ago and it ended up the same. Meanwhile my original pi (the 512mb variant) is still running Kodi on my main TV.
I upgraded from the x86-amd64 Mac Mini to Rpi 4Gb then 8Gb. Changing from the default window manager to KDE really made the pixels easy on the eyes.
Compiling from source code products like GNU Emacs, SBCL, Racket Lang IDE, TeX, Graphviz sorts of things is a breeze. I don't feel like I am being pushed around like China's Foxconn hires subcontracted to Apple that's looking to buy the Man. U's soccer/football hooligan fanbase.
The FLASH storage medium is unreliable on the Rpi, I know, but I haven't got around to finding something faster and durable and easily replaceable. Samsung has durable external USB devices from what the advertising says.
There are times on the Rpi when the cpu load shoots up, I guess that is due to Garbage In Garbage Out website JS stealing cpu cycles to mine tokens.
I paid $5 for the $50 discount on the 16Gb RockX5B Radxa but by the time they got around to updates on supply I had lost the coupon discount code. Threw it out in the old email box.
Performance wise they are fine, particularly the RK3588 series. If you want to keep up to date, you will have to do some work.
If you want a seamless experience, use an x86 SBC, they work great, never worry about kernel support, etc.
You will pay for it in performance for watt.
(IE 5 watt rk3588 vs 15 watt pentium J6412)
There are vendors who seem to care a lot, like Radxa (who makes the rockpi series), and others for whom the sbc offering is basically a test kit for their android tablet SOC's.
Just get an Intel based SBC, they're around the same price and don't come with endless headaches because they don't rely on ancient kernel forks that will never have their changes upstreamed.
Edit: I should say x86 SBCs because there are AMD and other x86 SoCs out there.
Get a used NUC if you're not in for the gpio etc. Check power specs first. I've set up a Fujitsu NUC a few weeks ago for my parents as a print server and syncthing node. After enabling link power saving for the SSD it's sitting at 5W idle with headless Debian.
great on paper, irl no support
In my experience they are only worthwhile if you are utilizing the GPIO pins.
I have looked but I can't find a 32GB variant for sale. Any ideas when they might be available?
No AV1 codec seems like a glaring omission given these are often used as media players.
is there a debian based OS that can be used with these SBCs? does apt work on that OS?
Armbian supports most of these rando arm boards.
yep, and personally I've found Raspbian to run without much issues too
> Orange Pi 5: 8-core CPU 2.4GHz, up to 32GB DDR4
... and no SATA. Only an M2 interface
Still... better than my work PC. Sadly.
I suspect this will emulate GameCube/Wii and even WiiU.
What on earth is a mask rom key?
Looks like a special rockchip boot mode for when there is no suitable boot environment installed on one of the storage devices.
https://wiki.kobol.io/helios64/maskrom/
Fascinating, thanks
>up to 32GB DDR4
Its up to 8GB at the moment
16 GB version:
https://www.aliexpress.com/store/group/OPI-5/1553371_4000000...
Holding out for 32GB