Hacker News new | past | comments | ask | show | jobs | submit login
Orion O6 ITX Arm V9 board – temper your expectations (jeffgeerling.com)
47 points by rbanffy 8 days ago | hide | past | favorite | 24 comments





Here's a Geekbench comparison vs Orange Pi 5+ with rk3588. https://browser.geekbench.com/v6/cpu/compare/10014991?baseli...

60% or better lift across the board for single core. Not bad imo.

Catching up with a larger tablet/MID (mobile internet device)/ultra Snapdragon 8cx gen3 is unlikely to come from nowhere. The A720 class core here is good, Neoverse N3 class, but it's still a small chip for arm.

On phones there's been the Cortex-X cores above in the lineup for a long time. It's widely assumed the bigger performance flagship Neoverse V3 services from the Cortex-X lineup. https://www.anandtech.com/show/21270/arm-announces-neoverse-...

What's the power consumption actually looking like?!? 8 wasn't expecting anywhere remotely near phone or desktop cores, apple or Qualcomm chips. Also note that this has considerably more I/o than I think anything made by Qualcomm?

There was zero chance this thing was going to come out of the gate well supported with mainline Linux support & a good uefi/acpi boot chain. Whether Cix can straddle the line & release enough information while not breaking any disclosure limits ARM is setting will as ever be a challenge, assuming Cix even wants to make this a well supported chip some day.

Radxa bears some responsibility as an integrator and board maker but it is such a wider web of work that it takes to make these things happen, and although open source has amazing force multipliers of existing libraries, there's countless force dividers of legal × documentation challenges that detract.

One does not just ship ARM Immortalis GC10 support! These are broader projects, are practically civilization scale or deci-civlizatiok scale efforts, ones open source would gladly be doing & more fervently... If there weren't so so many lawyers & NDA's in the mix, from the top on down.

I'm still very excited here. This looks like it could be an awesome nas. I wonder if it'll support PCIe-bifurcation, which would help NAS'ing it out so much. Jeff? :)


> Here's a Geekbench comparison vs Orange Pi 5+ with rk3588. https://browser.geekbench.com/v6/cpu/compare/10014991?baseli... > >60% or better lift across the board for single core. Not bad imo.

The numbers look like nonsense. There's no indication of what's being comapred.

From the look of it (see the table), the little core on RK3588 is compared against big core on Cix.


Now, looking at supposed inter-generational CPU performance increases between Cortex-A76 up to A720 (as presented on wikipedia), that adds theoretically to ~50% increase at the same clock frequency, so I guess it's plausible.

> Whether Cix can straddle the line

At least there is a kernel and PC-like boot process. I'm cautiously optimistic.


> At least there is a kernel and PC-like boot process. I'm cautiously optimistic.

Me too, I hope it makes building general purpose ARM desktops more feasible.

ARM UEFI/ACPI has been around for quite some time, but nearly all SBCs (outside server space) either don't support it or don't support it properly, and if iirc Linux has been hesitant to support it due to device trees.


> As we all know, for a successful development kit, open source support is essential. Cix technology will actively embrace the community and contribute to open source. For the newly released Radxa Orion O6 development kit, Cix technology will promote the open source and upstream support of EDK2 firmware and Linux kernel in the first half of 2025.

https://forum.radxa.com/t/plans-for-adding-support-into-main...

We should see more upstream work starting after CNY. Anyway this board can already boot the vanilla Debian arm64 iso, thanks to the Day 1 EDK2 UEFI/ACPI support provided by Cix.


Is that EDK2 support being upstreamed into Tianocore projects?

Yes, Cix will do it.

Good to hear, thanks! Since most Linux folks get their boot firmware updates from the Linux Vendor Firmware Service (LVFS) rather than distros or upstreams, does Cix plan to work with the fwupd folks to include support for boot firmware updates?

https://fwupd.org/


> like many Radxa hardware products, the hardware seems to be in a pretty good place. The software? Not so much ... I've harped on this numerous times: one reason I prefer Raspberry Pi, despite the lower value hardware per dollar spent

I agree. Same with FriendlyElec, Orange Pi, and especially Banana Pi


100%. Vendor drop BSP releases with no upstream plans are so annoying. Getting proper usage of IPs on the SoC is hard, if not impossible, when not using the "blessed" kernel by the vendor. Even when using what's blessed it can be a pain. depending on what kind of integration you are doing.

Then you're misinformed. :) Eg. RPi 5 didn't have mainline Linux support for a very long time after launch and it's still very barebones and was not even submitted by RPi foundation or whatever, but by Suse employee.

Just a nit—Raspberry Pi often works with vendors and outside contractors (with funding and engineering support) to upstream various parts over time. For example, Igalia is officially partnered with Raspberry Pi to work on Mesa drivers which are in 6.13[1].

I don't think Raspberry Pi has as much priority on pushing everything into 'mainline' ASAP, but less than two years after launch, some things are there.

And unlike many Arm vendors, at least Pi engineers assist with the efforts (e.g. [2]) even _5 years_ post-launch.

Besides that fact, Raspberry Pi has the resources to maintain their patches against current and future LTS branches, meaning you can run their fork at 6.6, 6.12, 6.13, and beyond, which is handy in terms of broad hardware and feature support.

For years many Rockchip SoCs were stuck at ancient 3.x, 4.x, 5.x kernel LTSes, which made a lot of use cases quite difficult.

I am extremely hopeful Cix (and Radxa, to some extent) is pushing to get things in mainline more quickly. But until it starts happening at a rate better than other Arm vendors, I won't give a gold medal to them yet :)

[1] https://www.phoronix.com/news/Igalia-Raspberry-Pi-3D-Opts

[2] https://github.com/lategoodbye/rpi-zero/issues/43


While this is all true, this is not unique feature of Raspberry Pi / foundation.

Rockchip does work on mainlining support for some of their SoCs into various projects. Recently they finally got their TF-A support merged for RK356x and RK3588. They also have people on staff maintaining U-Boot and reviewing Linux patches and doing some upstreaming. Some companies that make boards also fund upstreaming via third parties like free electrons/bootlin/collabora/paid individuals, or donate HW and/or funds to projects like Armbian or again to random individuals who show interest (which is Pine64 modus operandi, I guess), or do it themselves.

And then, there are seemingly independent developers (on the HW/SBC manufacturer) doing sometimes very significant development for personal or other reasons (to have some well working HW for their SW projects - routers, or media center software like libreelec comes to mind)

End result is that quite a lot of boards end up having good quality upstream support not very long after launch these days, as a confluence of all these factors. And having resources for maintaining out-of-tree patches becomes irrelevant.

> For years many Rockchip SoCs were stuck at ancient 3.x, 4.x, 5.x kernel LTSes, which made a lot of use cases quite difficult.

That may be true if you only look at Linux provided via BSP, but there are Rockchip SoCs that are well supported in mainline Linux for many years, like RK3399 (because of strong push from Google to get it upstreamed).

Other thing now, is that there's such a critical mass of say Rockchip/Allwinner related drivers upstream, that adding almost fully working support for a new SoC that had no support upstream, is sometimes attainable even for individuals who have a weekend or two of time to give to the project.

Eg. here is me porting Rockchip RV1103/1106 SoC support over the current mainline https://codeberg.org/megi/linux/commits/branch/luckfox-6.14 and adding a few boards on top. Except for CRU driver, it's mostly just light changes to existing drivers. So these days for some simpler SoCs you don't even need vendor support, or rely on anyone, and can just port it yourself based on released BSP code in a few days.

Super complex SoCs like RK3588, featuring a lot of new IP blocks of course take longer time and larger cooperation, but now, at similar [to rpi5] time after launch, there's very nice U-Boot support for booting via anything that the SoC can offer, fully opensource TF-A, and my Orange Pi 5 + supports GPU in kernel/mesa, dual HDMI output, PCIe, and pretty much all of the onboard features + working suspend to RAM, and this will only get better.

So RPi having resources for maintaining their out-of-tree patches will be more of a burden to them, eventually, because you'll be able to use many boards with generic distro kernel, while RPi will become an exception requiring some special handling and custom kernel.

It's already an exception in my world, where pretty much everything I have uses U-Boot, except for RPi which has to be it's own weird thing.


Indeed, though ironically, just today Oleksii Moisieiev posted a patchset to add the Pi 5 to u-boot :D

https://lists.denx.de/pipermail/u-boot/2025-February/579540....

Though from informal conversations with some of the Pi engineers, it seems like they're typically more involved in Yocto/buildroot, and their own tool https://github.com/raspberrypi/pi-gen-micro (not saying it's better or anything, but they do have a lot of engineers who come from Broadcom... they are a bit different!).


Pi and mainline kernel support has been a thorn since the OG Pi. Usually they get barebones support and then drip-feed in patches from folks who can be bothered enough to upstream it

The Pi foundation meanwhile just has the `rpi-kernel` fork on github and pretends nothing is wrong with doing it that way


I love Radxa. When the time comes to replace my Raspberry Pi, I will likely buy a Radxa board.

Why?

I am also very grateful Radxa is there because if you need something with "a lot" of RAM (64Gb) and cheap (sub $500 price), I believe something like the Orion O6 is the only game in town.

great hardware, good support, nice prices

Cool that it fits in a Mini ITX case and has a standard boot system rather than requiring custom images that won't get updated after two years.

Somewhat a low cost alternative to building a ARM desktop PC to Ammpere. You could build a low cost NAS by putting additional storage over the PCIE slot.

I wonder if it comes with a shroud to go over the ports if put in a case.


It does come with a IO shield / backplate for the ports.

Would be cool if that SoC gets released on a "compute module" board design, so it can be used with ComputeBlade. Would love to build a cluster out of a few of them.

https://computeblade.com/


Radxa has their own ITX cluster board (modules are RISC-V for now), but the thermals aren't encouraging (the fan in the middle seems rather large compared to a small module).

What you can do is mount a couple boards with standoffs and make a cube of ARM processing power.

With 16 cores, you can add 16 activity LEDs hanging on the GPIO and turn the cube into a small Connection Machine (if you get a nice dark acrylic enclosure).




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: