The Banana Pi M7
taoofmac.com
taoofmac.com
And that's why Raspberry Pi keeps winning:\
open source and open hardware lost.
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.
RK3588 upstreaming project: https://www.collabora.com/news-and-blog/blog/2024/02/21/almo...
Risc-V JH7110[0] upsteam status: https://rvspace.org/en/project/JH7110_Upstream_Plan
[0] used in https://www.starfivetech.com/en/site/boards
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.
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?).
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.
Just pick up an N100 with 4x2.5G ports.
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.
And there is even some viable work of it running on the NPU:
https://old.reddit.com/r/RockchipNPU/
...that leaves the CPU free for other tasks