OrangePi 5 Ultra Review: An ARM64 SBC Powerhouse | Hacker News Reader

OrangePi 5 Ultra Review: An ARM64 SBC Powerhouse

boilingsteam.com

61 pointsekianjo34 comments

> As you can see, the Ubuntu 24.04 distro is missing from the list, and this is a shame, since this is a board released late 2024. I contacted OrangePi and they mentioned that they would eventually release a 24.04 version, but there was no clear timeline for that.

> Sadly, but this was almost expected, there does not seem to be any kind of GPU support in the version that I have chosen. A quick check with glxgears confirms that there is just a software pipe for rendering.

Stuff like this is why people keep picking Raspberry Pi. There's tons and tons of alternative SBCs that have better price to performance on paper, but the software support is always awful. You're always limited to a few distro images released by the SBC vendor, and there's no effort spent by them on getting everything working. This product came out in December 2024, and they STILL don't have images with working GPU acceleration.

The support for GPU acceleration is there in the mainline kernel and in Mesa, it is down to the distribution including older versions.

There is upcoming support as part of BredOS, as mentioned at the end. (the link to BredOS has more details on the status). So eventually, that SBC should be working with a mainline kernel.

>There's tons and tons of alternative SBCs that have better price to performance on paper, but the software support is always awful.

And it is kind of funny, when hardware manufacturers will release a board and will then go great lengths of bending whole distros for the board, instead of just using UBoot which already has UEFI and ACPI layers, loading it permanently on the board into some SPI flash and then let it boot as a normal PC...

> the Ubuntu 24.04 distro is missing from the list, and this is a shame, since this is a board released late 2024. I contacted OrangePi and they mentioned that they would eventually release a 24.04 version, but there was no clear timeline for that.

Pretty much that is where most of these SBCs fall off my list. Without an active OS development its only 1/2 of the puzzle.

> * Without an active OS development its only 1/2 of the puzzle.*

And this is an unfortunate state of the general purpose ARM64 computing. This board, with 16 GB of RAM and M.2 slot, would make the perfect Linux desktop machine. However, you only receive one or two major distribution updates from the hardware vendor, and then you're stuck with it.

>However, you only receive one or two major distribution updates from the hardware vendor

I like your optimism. Some boards literally get no updates.

Massive shout out to Raspberry Pi team - Raspberry Pi 1 launched 12 years ago with Debian 7, and currently can run Debian 12.

Man it sounds like an android phone where the vendor only supports a few releases. Is that the model they're trying for or did they just land there?

Am I the only one who is enormously sketched out by pretty much any SBC requiring an OS put out by the hardware vendor, active support or no?

A lot of these vendors are overseas, do not share my values around open source, and may well look at my computing activity as a potential data mine to be sold.

Maybe I have trust issues. But if I can't install some community OS out of the box without relying on vendor binary blobs, I don't buy the SBC.

I have the same issues with trusting whatever random vendor. Unfortunately even Raspberrypi OS'es come with some blobs...

imo it's more a driver thing than an os thing.

I can get arch/slack to work on weird hardware, what I can't do is get the promised hardware performance without specific (usually semi-closed) hardware drivers.

If you're relying on , say, rockchip features -- then you're boned without their support -- this is already a big enough heartach without the malware/data-mine angle (which is likely just as valid.)

ARMbian is quite alive, and supports many RISC-V boards in addition to ARM64

I looked it up rapidly and couldn't figure out the difference with the original OrangePi 5.

By the way, the OrangePi 5 is a pretty good SBC. Much better bang/bucks than RPi, and the mainline kernel support is pretty good and getting better with every release thanks to the folks at Collabora.

https://gitlab.collabora.com/hardware-enablement/rockchip-35...

I give OrangePi a lot of points for putting an M.2 slot on the bottom of the PCB. Not only does Raspberry Pi charge extra for their M.2 board, it sits in an obnoxious location above the board where it interferes with many other things one might want to put on top, e.g. any sort of passive cooling.

A non-Broadcom SoC and actually fast network? Absolutely better than any Raspberry Pi

The built-in ethernet controller would be fine, not sure why it needs to use up some PCIe lanes on an external one.

> I looked it up rapidly and couldn't figure out the difference with the original OrangePi 5.

RK3588S -> RK3588, LPDDR4 -> LPDDR5

There is also one in between - the plus. Rk3588 but ddr4

Thanks. Does it make a big difference in practice?

Assuming you can get software support for more than one version of 'blessed' distro.

Well, that’s my point exactly: mainline kernel is what all distros eventually use.

As a matter of fact I’m currently running an OrangePi 5 as a server using an unmodified Debian Trixie and hardware support is nearly perfect.

Could you be more specific about what's not perfect yet with the hardware support?

I have a cluster of 3 of the Orange Pi 5 Pros. They're extremely capable machines if you don't need the GPU or NPU (which I don't). That being said, they're more expensive, louder, and less energy efficient than like an Intel N100 mini PC.

This.

If power draw isn't critical, an N95/N100/N150 x86 wins out every time on OS support and price point. Especially when you factor in an SSD, thermal handling, case, power supply...

The NPU is somewhat usable on RK3588(S(2)) boards, as long as the kernel you’re using is recent enough to have the latest NPU driver.

For a quick bring-up and implementation, take a look at this repo: https://github.com/Pelochus/ezrknpu

I have a Radxa Rock 5C (on Armbian) and it runs various models rather well. Trying to convert models is kind of a pain, though, so watch out.

Works great for me on Frigate. I am doing object detection on 3x 4k streams and it’s only 20% utilized.

Has anyone found a good table of tokens/s comparing different cards and systems (CPU, GPU, NPU etc.)?

Also: recent Geekbench should have NN tests: have you found dedicated comparison pages, and is which processor (C/G/NPU) is used clear?

I tried to use an OrangePi but got frustrated with buildroot quirkiness. We ended up just using an RPI. Other folks in this thread have said similar things, but this really is the reason why RPI often wins.

Is it well supported by the kernel and upstream? Or are devs going to be left twisting in the wind like nearly every other offbrand ARM SBC?

I don't have to worry about getting even my freakin' 12-yo Raspberry Pi 1 going with newer software than it was originally built to handle. But the Chinese Gooseberry Pi that seemed like such a bargain on AliExpress, esp. considering the price-performance ratio, is a complete crapshoot.

It's pretty amazing what the Raspberry Pi Foundation has achieved in terms of software support and platform longevity in a world seemingly dedicated to bedroom experiments that are bound to eventually end up in a drawer or landfill. I'm old enough to remember the Gumstix and SheevaPlug, and those had these problems too.

https://github.com/RAMJAC-digital/edk2-rk3588

This may be slightly out of date, but these patches allow HDMI out on uefi for the Max, and can probably be easily modified this for the Ultra. If there is interest I can look into this later on tonight and test on an Ultra. The HDMI device tree isn't too bad, you can kinda guess the address offsets, but you will need to dive into the 3588 refernece manual. There are some design flaws in these boards around using SPI for the wifi and bluetooth and haven't had these work yet. Vulkan hardware support is alright, and can run Chromium and Niri without issues. Ghostty doesn't as it is OpenGL only.

I use these baords for aarch64 linux builds and a basic desktop environment, and it's been pretty rock solid with EDK2. Take a gander ya'll.

These less common SBCs used to be really bad to run because they didn't get updates. Nowadays its always worth checking what is available on Armbian because they have a lot of supported images for these other SBCs.

The previous Orange Pi 5 models now all have support on ARMbian so it's expected that this one would follow (soon?).

There is also https://dietpi.com/#downloadinfo <- click through to OrangePi and then the model.

I have this board and want to mention that the Armbian image supported for the Orange Pi 5 max seems to work fine as well without modifications. Although I haven't tested much yet besides ssh'ing in over ethernet and doing some basic installations.

https://forum.armbian.com/topic/51307-orange-pi-5-ultra/

Reply on news.ycombinator.com