The Orange Pi 6 Plus

Sure. But a heterogenous environment is interesting. And I wouldn't put all my eggs in one product line.

Qualcomm has rebranded a Snapdragon with quadruple Cortex-A78 cores (and 4 small Cortex-A55), from the expensive smartphones of 2021, as "Dragonwing" QCM6490 and they now sell it for embedded devices.

There are at least 3 or 4 SBCs with it, in RPI sizes and prices.

Cortex-A78 is much faster than the Cortex-A76 from RK3588 or the latest RPI (e.g. at least 50% faster at the same clock frequency), and its speed at the same clock frequency does not differ much from that of recent medium-size cores like Cortex-A720 or Cortex-A725.

Cortex-A78 is the stage when Arm stopped making significant micro-architectural changes in medium-sized cores. The later improvements were in the bigger Cortex-X cores. The main disadvantage of the older Cortex-A78 is that it does not implement the SVE instruction set of the Armv9-A ISA.

While mini-PCs with Intel/AMD CPUs are usually preferable, for an ARM SBC I would no longer buy any model that has older cores than Cortex-A78.

Besides the Qualcomm Dragonwing based SBCs, there are also Cortex-A78 based SBCs with Mediatek or NVIDIA CPUs, but those are more expensive.

> So it's either a linux learning toy, or an integrated component within another product, and not much in between.

Raspberry Pi are excellent at being general-purpose, full-Linux boxes that consume very low power (some can idle at <1W). Perfect for ambient computing, cron-jobs, MQTT-related hackery, VPN gateways, ad-blocking DNS servers, or anything else that isn't CPU-bound, but benefits from being always available[1].

1. In my case, this ironically includes orchestrating higher-wattage computers via Wake-on-Lan and powering them down when not needed

Bottom tier computers were more than $25.

It's tiny and low power, I run CI on a Pi5 and do a few other things and experiments on them.

I built a nice little cyberdeck around an RPi 5 but it's turned out to be very disappointing. I was counting on classic X11's virtual display stuff to enable a 1080x480 screen to be usable with panning (virtual 720p or something, just a cool vertical pan). Problem is, the X11 support sucks, and so there's almost no 2D acceleration, so this simple thing that used to work great on a 486 with an ATI SVGA doesn't work very well at all on a machine a thousand times faster. Wayland has of course no support for a feature like this one, so I'm stuck with a screen too narrow to use, and performance for everything else that's pretty sub-par.

I concur with this. The novelty of the Pi is getting a computer somewhere that you normally wouldn't due to the size and complexity. GPIO is a very nice addition, but it looks like conventional USB to GPIO is a thing so it's not really a huge driver to use a Pi.

Also, unlike a lot of other manufacturers who only provide builds of Linux for their own hardware for a couple of years, it seems that even the latest version of the official Raspberry Pi OS supports every Raspberry Pi model all the way back to the first one with the 32-bit version of the OS.

Likewise, the 64-bit version of the OS looks like it supports every Raspberry Pi model that has a 64-bit CPU.

https://www.raspberrypi.com/software/operating-systems/

With the caveat that I might be slightly out of touch (I have nothing beyond the Pi4/400 and the last x86 mini-box I bought was over a year ago)…

IMO the key benefit of a Pi over an x86/a64 box, assuming you aren't using the IO breakouts and such, is power efficiency (particularly at idle-ish). The benefits of the x86/a64 boxes is computing power and being all-in-one (my need was due to my Pi4-based router becoming the bottleneck when my home line was upgraded to ~Gbit, and I wanted something with 2+ built-in NICs rather than relying on USB so didn't even look into the Pi5). Both options beat other SBC based options due to software support, the x86/a64 machines because support is essentially baked in and the rPi by virtue of the Pi foundation and the wider community making great efforts to plug any holes. A Pi range used to win significantly on price (or at least price/performance) too, but that is not the case these days.

I don't get how your argument infers from your parents comment.

To me it would be the opposite conclusion: stay away from ARM SBCs with proprietary firmware and just go Intel-x86 NUCs if you don't want surprises.

And yes, RPI was(is?) a proprietary-FW SBC as the Broadcom VideoCore GPU driver was never open sourced from the start and relied on community efforts for reverse engineering, which the rPI foundation then leveraged to sell their products at a markup to commercial customers after the FOSS community did all the legwork for them for free. Like so long and thanks for all the fish.

Meanwhile Intel iGPUs had full linux kernel drivers out of the box. That's why they're great Jellyfin transcoding servers.

It’s a combination of IP and deep institutional expertise. The 5G standards plus other important protocol documentation, for example, are on the order of fifty thousand pages, built on decades of experience with edge/2g, 3g, and LTE. That’s just the documentation on the protocol, the real secret is in the mixed signal ICs that require custom cell libraries which Qualcomm/Broadcom work with fabs to develop for their own use. The only other company of note in this field is Apple which bought the initial IP from Intel (which bought it from Infineon, another IC manufacturer), so we’re talking about something so technically complex that only the deepest pockets and expertise can make any headway. When Apple bought Intel’s modem IP, over two thousand employees transferred with the deal, to give you an idea of the scale.

That’s just the radios, which is their bread and butter. A lot of their other products have similar barriers to entry.

As the sibling comment noted, FPGAs aren’t even in the running. Ignoring their power consumption, the biggest FPGAs only have a hundred thousand or so logic elements. While its not easy to map that to number of transistors per se, even a legacy nodes are capable of much more complex designs than you can fit on an cutting edge FPGA. This really makes a difference even at the lower end because you have to get the timing right between all the different parts of your logic, and making everything smaller gives a lot more room for error (its a lot easier to put delay lines than to reconfigure a section of your design to fit closer to another section).

The range of their offerings is immense and I think each product should be evaluated individually to competition. But just as an anecdote from my company - to create a full spectrum DOCSIS signal our HW team used multiple huge FPGA chips, I think it was Altera 10 or something (device is EOS by now) and that only for the DAC (kinda), there were separate CPU, separate 10G switch, separate utility FPGA, separate memory, separate everything. And it had to be glued together with some insane mash of code on top of the FPGA blobs which not always work as expected. All in all it was a ten unit monster which used something like 4000W in steady state and a dozen of industrial coolers at max to cool it off.

And today that is replaced with a single relatively tiny in area chip (those old FPGAs were huge) from Broadcom, which does literally everything and complies with newest standard and uses tens of watts of power, and it is passively cooled. It's not quite the correct comparison since arch changed in the meantime, but if someone would build an exact replacement for that older big device using new chips and have the same specs, it would be half as big and use under 1000W or even less. And all software is ready to use without reinventing half of it manually.

But yeah, Broadcom's support is slow and opaque. and they will stall any non-major customer for month for almost any request, because they are prioritizing different tasks internally. It's like a drug dealer dependency and there is only one dealer in your town :) .

active cooling is the killer though. I'd prefer a board that is fanless any day.

This only has 4 gb lpddr4 memory max, 1GbE and it seems no pcie lanes at all. The orange pi has much better specs.

Lmao the hero background. They photoshopped the pc into the back pocket of that AI-generated woman. (or the entire thing is AI-generated)

I can run my N100 nuc at 4W wall socket power draw idle. If I keep turbo boost off, it also stays there under normal load up to 6W full power. Then it is also terribly slow. With turbo boost enabled power draw can go to 8-10W on full load.

Not sure how this compares to the OrangePI in terms of performance per watt but it is already pretty far into the area of marginal gains for me at the cost of having to deal with ARM, custom housing, adapters to ensure the wall socket draw to be efficient etc. Having an efficient pico psu power a pi or orange pi is also not cheap.

On the other hand RPi doesn't support suspend. So which wins depends if your application is always-on.

They also sell a heatsink for mere $21 (on AliExpress), just in case you don't know how to fit a spare PC cooler onto it.

I recently tested a palmshell with a N100 from Radxa too [0]

It performs well but there is definitely a thermal problem compared to other N100 based systems I got.

- https://palmshell.io/slim-x4l

I used to run some weird 5.x kernel until I found about collabora and then I still had to cook my own fdt files and patch some weird stuff in kernel, keeping my own local branch, but yeah, it's always the same story with upstreaming, sadly. Been there, done that since OpenEZX days.

But now, I just did the system update, rebooted and got 7.0.0-1 from the package manager, which is never than my x86 laptop. I still have trust issues with this, expecting it to not boot or get up without HDMI output zo.

It's not just about booting though. We solve this with hardware-specific devicetrees, which is less nice in a way than runtime discovery through PCI/ACPI/UEFI/etc, but it works. But we're not just talking about needing a hardware-specific devicetree; we're talking about needing hardware-specific vendor kernels. That's not due to the lack of boot standardization and runtime discovery.

Microsoft's standardization got AMD and Intel to write upstream Linux GPU drivers? Microsoft got Intel to maintain upstream xHCI Linux drivers? Microsoft got people to maintain upstream Linux drivers for touchpads, display controllers, keyboards, etc?

I doubt this. Microsoft played a role in standardizing UEFI/ACPI/PCI which allows for a standardized boot process and runtime discovery, letting you have one system image which can discover everything it needs during and after boot. In the non-server ARM world, we need devicetree and u-boot boot scripts in lieu of those standards. But this does not explain why we need vendor kernels.

It's legacy of IBM PC compatible standard, that has multiple vendors building computers, peripherals that work with each other. Microsoft tried their EEE approach with ACPI that made suspend flaky in linux in early years.

I've just been doing some reading. The driver situation in Linux is a bit dire.

On the one hand there is no stable driver ABI because that would restrict the ability for Linux to optimize.

On the other hand vendors (like Orange Pi, Samsung, Qualcomm, etc etc) end up maintaining long running and often outdated custom forks of Linux in an effort to hide their driver sources.

Seems..... broken