Hacker News Reader

The VisionFive 2 developers are working on getting things upstreamed/open-sourced for their board. IIRC the kernel has already mainlined many (if not all) of the patches.

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.

As someone that has actually shipped RPi-like boards and clones, I'll tell you that it's just part of the job description.

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.

But the RPi is broadcom and arguably the best supported. Obviously this is special.

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)

Were the kernel and BSP improvements and ongoing support for RPi produced by Broadcom, or by the user community?

There is some sort of close relationship between Broadcom and the raspberry pi foundation which is not entirely clear, they are a bit more than just customers although companies use the “partnership” label to mean just about anything.

The relationship is very clear: Upton was a Broadcom FAE that started the RPi Foundation. The secondary story was that he found a use for an orphaned SoC and embarked on an 'educational' quest to make small computers for classrooms.

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.

Please excuse my ignorance here, but are you saying that the board makers have no say on what chip they want to incorporate into their board? And those chips firmware are not open or at least accessible to the board makers?

What I'm saying is treat the board as a development harness to get your project going. If you have issues with the processor don't take it up with the board maker because they're usually just as clueless. The exception would be boards like RPi or Beagle where the designers are tight with or owned by the chipmakers themselves.

Right, which is what GP was saying: stick to those that are able to support longer than zero time horizon.

But the fundamental difference here is that most people buying SBCs are treating them as self-contained COTS compute modules.

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.

Support is the S in IOT.

I thought that.... oh, Security is the other S. Got it!

Identity is the Id in IdIoT.

Board support packages very rarely get updated and usually target a very specific kernel version.

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.

This problem wouldn’t exist if linux had a stable ABI.

Hopefully Fuchsia’s stable ABI promises pan out and companies start releasing drivers for it.

Haiku is already working on the board, although you need to build your own, as there's no public builds 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.

Are these vendor kernels good enough to run some sort of hypervisor and pass through devices at the lowest possible level to (updatable) guest kernel(s)?

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.

Wait, I used OrangePi's with Allwinner chips before precisely cause of their cheap price and mainline linux support. At the time (~5 years ago) Rpi was worse, foss-wise. Here is a wiki documenting the efforts: https://linux-sunxi.org/Linux_mainlining_effort What am i missing?

i use orangepi prime boards in production as remote NIDS. i used Armbian (a great debian porting project that does what the maker should have done ) until orange released their Debian 10 img. I put an endurance rated sdcard in those pis and they run like the little pink bunny! Love these little orangepis. I have tried a handful of other boards ( beagle, raspberry, banana , have a whole stack. too many to remember) but the oranges are solid. On a lot of these little SoCs, you can use the raspberry pi gpio software since many of these boards follow the same gpio standard & plug in/out.

I agree with everything except I don't think I would have called out OrangePi as the worst of the lot -- at least not anymore.

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.

i agree, that is a problem, mainline linux and working drm, that is direct rendering manager, drivers should exist before release of the product.

Beaglebone Black is used in industrial applications. At scale, those price differences add up.

yes, especially because there is an industrial variant that works down to -40 C. We use them in our detectors in Greenland. rpi's sometimes work at low temperatures, but are not spec'd for it (plus they use tons of power compared to the BBB).

Yes, for the application I used them in, we were concerned about both the upper and lower limits (heat from operation + cold when turned off in the winter). Outdoor installation, with hundreds of units per site.

I keep saying, the first cheap Chinese manufacturer that ships a SystemReady board is going to slaughter the competition.

> There's another factor that's so much more important [...]: Software/kernel support.

Vision Five 2 it is then