$150-$180 seems expensive for 4gb ram and 16gb flash when you can get an sbc with the same soc, the sipeed licheepi 4a with 16gb of ram and 128gb flash for $180, or $120 for 8gb ram and 8gb flash, or $135 for 8gb ram and 32gb flash
Every goddamned RPi-like SBC seems to require a very, very specific version of the Linux kernel that has been patched to hell and back. Almost always bundled with binary blobs/firmware that only work with that very specific version of the kernel.
None of these patches get upstreamed and the binary blobs/ultra proprietary who-knows-wtf-its-doing required firmware never get updated after the release. This means that you'll be stuck with whatever version of the kernel that shipped with the device forever. Complete with all the bugs and vulnerabilities that get discovered later.
Never again! Either the vendor needs a history of staying on top of things or they need to make some serious promises about upstreaming kernel patches and drivers.
Example of a terrible SBC vendor you should never buy from: Orange. All the OrangePi SBCs are exactly as I described. You can expect any bug or security issue that exists at release to be a problem with that board forever. They will never get fixed. They might release an update or two within a few months of release (if it's real bad) but that's all you'll ever get.
They ALL suck, some just suck less than others. Broadcom, Renesas? The worst. ST, NXP, TI? Slightly better than fully sucking. Look to the chipmaker (ST, NXP) and not the board maker (Orange) for a guide in how well things go.
From experience I agree with you, the chipmakers suck because they utterly fail to be open source when they're one of the groups that needs it the most. It is to the extent that I would advocate for laws in the theme of right-to-repair to force chip vendors to provide source for necessary code to use their products to consumers. (in this case open source in the narrowest definition, they can keep their copyrights but would be required to distribute source to end users in a form and with a license that makes them usable)
If the question is "are any of the SBCs worth the trouble?" and the default answer is no unless I have a really good reason and want to dedicate the time to building the janky software stack (I don't), or they're from a small list of vendors I'd trust won't be a mess (RPi, nvidia, beagle, ... that's it off the top of my head)
The real question is if Broadcom is devoting internal software resources to improving the ecosystem, or if it's coming from the devoted users. I don't track commits on kernel.org enough to know what's what.
As someone that has worked with these EVKs for decades, you never treated them as part of your final product. But with the advent of Beagle and RPI, that's where we are now.
But when you buy an RPi or Beaglebone as the core of your industrial smelter and expect support for that module comparable to, say, a module from Kontron? You're going to be disappointed.
You move off that kernel version, no BSP, no boot. sad times.
This is one reason why you don't get android phones supported past the android release shipped.
You're completely at the mercy of the SoC provider. Promises of 'n' years support are quite often quietly dropped after 18 months, when they realise all the engineers have moved to working madly to get the latest SoC's BSP out of the door.
Rinse and repeat.
Hopefully Fuchsia’s stable ABI promises pan out and companies start releasing drivers for it.
Haiku remarkably does have proper driver APIs and stable ABIs.
Linux is and will remain painful, on all platforms, until it is finally deprecated, and for a while longer after that.
The idea here would be to run things like the TCP stack, USB from the lowest proxy-able level the in USB stack, etc in the guest kernel(s), as well as the entire application level, so as to reduce exposure to vendor kernel bugs and feature freeze leaving it only with minimal SOC-specific nitty gritty. For GPIO the vendor kernel could be used as a PRU of sort, passing messages to the guest kernel for actual processing.
Then the vendor kernel is just treated as a BIOS/blob getting in the way as little as practicable, it's very ugly but would allow using all these boards, also same method could possibly be used to recycle obsolete android phones.
Some of the real issues are as follows:
1) Most companies use Debian as a base. Debian has a notoriously slow release cycle. This means it takes loads of time to submit patches -> get approval -> get merged in a merge window -> wait for debian to use new kernel with new code.
2) The GPU situation is a mess. No decent (compatible) vendors with open source GPU drivers exist. Imagination is said to be working on open source drivers, but with no real release date, we are stuck using closed source blobs. Once drivers and Mesa get updated, we then have to wait for a new release of Debian to pick these up.
3) Far fewer people use these boards over a Raspberry Pi. This means community support takes longer to develop. The VF2 has other distros like Arch and Ubuntu, for example, but no real active community behind them. Last I checked, hardware GPU acceleration was not working in these distros.
Vision Five 2 it is then
They seem to have basically outsourced their software maintenance to Armbian, and if that relationship holds it's probably a win-win. Armbian's build system is really nice, IMO.
FriendlyElec are borderline; they make nice hardware but definitely seem to take a "here's a kernel we got to boot once, good luck!" attitude towards software support. Some of their boards are supported by Armbian but often without key features due to lack of documentation or binary blobs.
Below that is a vast sea of largely-anonymous Chinese-based hardware companies who drop a design (sometimes really neat) into the world, then disappear without a trace. Mostly I think these are designs whipped up quickly to use up spare parts, or originally designed for embedded use in a particular product and being sold on the side. (I've definitely seen 'development boards' that were clearly designed for security cameras or TV decoder boxes, f.ex.) But you are buying yourself a new hobby if you decide to get one.
Every time I opted for cheaper clone of beagleboard or RPi I ended up regretting it when I inevitably had to spend hours building custom kernel patches and struggling to get it working reliabily. The more expensive boards usually work out of the box with mainline kernel.
For some that can be worth the extra $50.
I'm just hesitant to buy one of those without having some 3rd party confirm everything works well out of the box, and the more obscure the device the harder to find such accounts.
The reason I'd buy a Beagle (well, really an ESP32) isn't the price, it's the convenience of havng real time GPIOs.
The SoC had quad C910 OoO cores (similar to A72) as the application processors. There is also a simple E902 (in-order, 2 pipe stages, RV32EMC ... basically Cortex M0 equiv) in the Always-On subsystem and a C906 (64 bit in-order, 5 pipe stages, used as main applications processor in numerous AllWinner D1, Bouffalo BL808 etc boards) in the "audio" subsystem.
Looks like this board (if you mean https://linuxgizmos.com/dev-kit-debuts-risc-v-xuantie-c910-s... or something like it) runs Linux (android or debian). With the BB, you could at least program the PRUs to handle these problems directly in hardware. With the ESP32 you're writing code that runs in an RTOS. Most SBCs I've seen make you use userspace to access GPIOs. unfortunately for my use case, I have about a 100 nanoseconds to move a signal from one GPIO to another, and if I drop an interrupt, it means part of my data ends up missing.
Why would I be talking about the RVB-ICE? They use the same main CPU cores, but a totally different SoC.
The TH1520 has, as I wrote in my last post, two secondary RISC-V CPUs that are not managed by Linux, and which can be used for real-time tasks.
Of course you don't HAVE to run Linux in the first place if you don't want to. RISC-V chips are very standardised and easy to program bare-metal. The only tough part is usually DRAM and clocks initialisation. You can use the board's standard U-Boot SPL for that if you want, then either replace the Linux kernel by your own code, or also replace the higher level part of U-Boot.