> And yes, documentation and software support are still a bit of a mess, but that’s par for the course with these boards–and the M7 is at least better supported than most.
Well, I’ve had extremely good results with Armbian for server stuff, which is why I’ve always tried testing with that. Networking, standard peripherals, etc. all work, so the only real oddities are still GPU and specialized hardware support…
The problem with Armbian is, while it's neatly packed and made with a lot of care, you lose board-specific capabilities, esp. in Rockchip systems.
Using Armbian for OrangePi 5B means losing hardware accelerated video encoding, AI acceleration, etc. But, I bought the board for these features.
I'd either use OrangePi's own, short living Debian image with all the features or an Armbian build which I won't be able to update cross-release but will be supported and developed, losing all the differentiating features of the board.
There's no winning here. This is why Raspberry Pi is winning.
Update: Like I mentioned above, in the weeks since I fleshed out this draft Armbian came out with an Ubuntu Noble version with improved MESA/VPU support, but I haven’t had time to test it yet. I’ll update this post when I do.
Which is what I’m asking. The article doesn’t contain information on media transcoding with Armbian, and I asked the question to learn whether there is more info on that. Otherwise, OrangePi’s image already does what I want.
Video encoding has a lot of patents attached to it, so the access to that IP block is not always open source due to plethora of reasons. It’s a very non-ideal situation for non-embedded use, hence the question.
Pretty sure the issue is that the RK3588 drivers are not upstreamed into Linux/U-Boot etc. This is the issue with most ARM CPUs in this area like the Broadcom ones RPi is using. Which is why they have Raspberry Pi OS to ship you the drivers. The first good ARM CPU to actually get mainlined will probably see more sales.
When you say "closed source pi", are you referring to the hardware or the software that ships with? My experience with the Raspberry Pi is that it's been a very open platform and that there's tons of options for me and that licensing has never been a problem but also never tried to take a CPU off and Transplant it to a new board or something.
Open source software seems to be winning? I mean, the whole point is that people want SBCs running Linux.
I think it's probably fair to say that open source hardware is not winning. I'm not sure I'd say it's "losing", the BeagleBoard exists and seems to do alright for itself if that's what you want.
I've found with all the SBCs, the booting story is pretty sad. In particular, I've got a pile of more-or-less powerful but uninteresting SBCs (Raspberry Pis of multiple generations, OrangePi 5+, etc). I find that putting the OS on these machines is always quirky and failures to boot from SD are extremely hard to debug.
From what I can tell these systems don't have a "BIOS" or UEFI or other bootloader that has a command line that supports USB keyboard, console display, and iterating over boot devices. TBH what I really want is an embedded copy of linux in an on-board firmware that boots me into a minimal filesystem with busybox-like toolkit, with the ability to use it to mount filesystem and boot a kernel from there.
Maybe I'm missing this feature in OrangePi 5+ but a lot of my devices involve hooking up to a full monitor, a full keyboard, and then serially testing each of my SD cards until one can actually boot the OS. I much prefer my Intel NUCs (eveyrthing from the wimpiest to the most powerful) although Intel exited that business (IIRC they handed the NUC tech to Asus?).
FWIW, there are working and usable ports of EDK2 to the RPi4 (not sure about v5) so you can just throw the image on an attached USB drive. The FSBL then boots the EDK2 image, which can then load a generic UEFI image like normal. I used that reliably for quite a while; Fedora's generic UEFI aarch64 ISO worked out of the box with no extra fiddling, just burned it to a separate USB stick and booted the installer.
There's also some in progress ports of EDK2 to RK3588, and various other boards, though there's often some missing features as they need to be implemented properly in EDK.
Really, there's two parts to the whole story, the second being device enumeration, that gets handled by either a device tree blob (DTB) or via ACPI. For UEFI that means that either the UEFI build you're using needs to come with the DTBs pre-configured and embedded inside it so they can be passed to the OS you boot up. Or your device/build will be configured to use ACPI. (The story here is actually weirder than that on some devices where e.g. they have ACPI that requires enumeration, but they expose the actual raw DTBs from that, which you then pass on to the kernel, so you actually have to handle both.)
UBoot also has a minimal EFI implementation that you can use, though I don't know how much it implements or if a random generic AArch64 linux ISOs will work with it. Last I checked modern UBoot can even netboot over HTTPS these days, too, so if it could do all the above on a supported board, that would be awesome.
phi3:instruct does a good job with simple summarization. I haven’t tested it for grammar checking (I am focusing on automation and tool use), but it would likely work.
In every one of these threads: "why not a NUC!!?!!"
If you ever hope to deploy a bespoke board with whatever SOC you're using on it, you will never select an Intel or AMD chip. The level of supporting componentry is an order of magnitude more expensive, difficult to obtain, and not publicly documented.
You could spin an RK3399, RK3566, RK3568, RK3588 board today with nothing more than the SOC and potentially the accompanying PMIC (most of these SOCs and blessed PMICs have mainline Linux support): you cannot do this with the x86 chips.
It depends. I am also testing N100 (and N97) machines, but for other reasons. Pricing will vary a lot depending on the number of interfaces, case, etc.
Because the code for that is nowhere near stable/usable unless you have the exact planetary alignment and/or blobs in your distro, and you invariably have to convert LLM weights. The number of LLMs supported is very, very small right now.
And that's why Raspberry Pi keeps winning:\