This is what sets the raspberry pi apart from all other SBCs in my experience: software support. Kudos, this is fantastic stuff! Will love to see the ecosystem of stuff that springs up that takes advantage of this.
It's important to note that competitive x86 SBC do exist, and have the typical, full, x86 support. Of course, the downside is that the price is higher (around twice as much for a full system).
A downside of ARM SBCs is that they pretty much all have an expiry date. Due to their closed nature, when the community pulls the plug, they're gone (SW-wise). x86 boards last virtually forever. While they're somewhat compatible with standard Linux distro, in order to have full support, one needs to use the adhoc ARM distros.
First, the "closed nature" thing is just as true about x86 as it is about ARM; you don't get full specs for any machine these days, Broadcom or not. Rather, from the perspective of "Linux developers who write code on and deploy to Linux" — or maybe "Linux Desktop Users" — the difference is in peripheral discovery and setup, of which x86 has ACPI and UEFI to dynamically discover and configure devices upon every boot, while ARM boards use device tree, which is static and requires up front, BSP-specific descriptions.
Userspace binaries for AArch64 Linux will work across most devices. A RPi4 running Ubuntu and a RockPro64 running Ubuntu will use the same binaries just fine. The problem is when vendors have kernel patches or workarounds that make booting harder. But it's not like literally all software stops working on a specific date. If you have the kernel and dtb, you can make it work and keep your system booting. It's definitely less than ideal, if you think of it like a desktop, where timely updates are common and easy. But it's doable. And more devices seem to be moving towards an upstream-first model, so this seems like less of a problem anyway. I'll also note it's not actually hard to package a device tree blob with a userspace+kernel, it's just that most "desktop" distros make spinning custom variants unreasonably hard, IMO, so you need Buildroot/Yocto or whatever to build custom images. And again, "Linux users" like, say, most people reading this comment, don't actually want Yocto — they want Arch or Debian or whatever. A bit chicken and egg.
Furthermore, the RPi4 also supports ACPI and UEFI (upstream Tianocore) which is continuously improving, so it can support generic Linux distros. I have a "generic" Fedora 33 install working on my RPi4, with UEFI boot, all from a USB3 stick. It even installed using an ISO, and I configured the install using Anaconda, identically to x86. The Pi4 also has a production date of at least 2026, and almost the entire userspace software stack is completely upstreamed now, including kernel, graphics drivers, and peripherals. So from the perspective of someone who treats the RPi as a kind of "mini Linux Desktop", most of your complaints don't really apply at all. But...
---
The actual biggest problems with the lack of specs/dtb shit/"closed stuff" isn't when you want to treat it like a normal Linux machine with keyboard/usb/ethernet. That's easy and works today. You can get most of the desktop Raspberry Pi experience, including generic distro boot, today! It's when you want to treat it like an actual "embedded device" where you write custom drivers or poke GPIOs or use hardware features, or whatever. That's where the closedness sucks, but in that case, even if it sucks or there's no specs, there's normally no realistic x86 alternatives.
Sure, you can buy a $100 x86 device in an RPi form factor with RAM and plug a keyboard into it, and it's OK if it uses 2x as much power at load, if you just want a mini desktop that is cool. But where's the $20 x86 device that has a shitload of I/Os I can use to interface with various peripherals of my choosing, with all the accompanying good stuff like good DAC/ADCs, GPIOs, camera support, eMMC? And where can I buy them? Where's the $5 RPi Zero alternative? Because the ODROID-H2+ is $120 USD, and doesn't even have GPIOs!
Heck, they still support the original Pis and A+; I just installed the latest version of Raspberry Pi OS on my A+ with 128 MB of RAM, and while it is slow, it works just the same.
The problem with the $ PiZero w/o WiFi or the $10 PiZero w/WiFi is you don't seem to be able to buy them in quantity. They are simply not 'available' to use in any sort of 'product', it seems.
> While they're somewhat compatible with standard Linux distro, in order to have full support, one needs to use the adhoc ARM distros.
Maybe you mean something specific by "adhoc" or "full support" that isn't apparent to me, but Ubuntu has ARM distros today and I expect that ARM support is only going to get better as (1) ARM continues to make headway in the server space and (2) Apple Silicon pressures desktop/laptop OEMs to adopt ARM.
Just because Ubuntu has "ARM distros" doesn't mean those "ARM distros" have the necessary drivers needed to actually use all features of your SBC. The fact that Vulkan support in raspberry pi landed in 2020 should tell you something.
Even the most well known SBC series is getting driver support at a glacial pace. When was the last time you waited for your x86 iGPU to get vulkan drivers?
And yet one of the reason it achieved such great software support is because it had so much success, despite the non-standard hardware (armv6 at launch, broadcom, no EFI boot, broadcom, no GIC, broadcom, no armv8, broadcom, gpu boots before CPU, etc.)
Broadcom is notorious for hiding everything behind very restrictive NDAs. You want a CPU from them? Don't bother contacting them unless you plan buying six figures, is the common sentiment on HN.
On the other hand, there aren't many competitors that are better in terms of accessibility. Sigh. Implementing embedded devices with any sorts of "smarts" beyond some Atmel uC from scratch is a pain - one has to go with ready-made modules (ESPxx, Raspberry Pi compute module, COMexpress) to not go insane.
And it's not just the data sheets where you will run into issues (at least, usually you can find them somewhere pirated to get started). Design guides, layouting rules and certifications are a way bigger pain point... looking at you Thunderbolt.
And when you finally have your first PCB version ready, you'll soon find out that any components more intelligent than a couple transistors have sometimes ridiculous minimum order quantities. Let's take a SI2494 56k modem chip... 45$ apiece at a MOQ of 43 - which means if you want one or two you'll have to shell out about 2k $! And to add insult to injury, it's apparently still profitable to sell them for under 9$ at high quantities. This fucking rip-off is the reason why many hobbyist electronic projects are restricted to using dumbass components.
edit: I totally forgot about the software side with embedded SoCs. Basically, to boot Linux or anything else on a SoC you need firmware blobs (e.g. for the GPU or wireless radio parts) and lots of custom code (e.g. to bootstrap clocks, memory, IO). Usually the SoC vendors have an ancient fork of a Linux kernel and u-boot in which over each new chipset there gets ever more custom cruft and (often shoddily) backported stuff from newer kernels. This conglomerate is called "board support package" or BSP - and is, despite consisting of open source code, often guarded as heavily by NDAs as the data sheets.
Sometimes, especially for Mediatek stuff, these BSPs get leaked on Github... and it's always a wild ride looking into them. It's no surprise that upstream Linux doesn't have the support for whatever specific CPU... because the quality of the code is more often than not so hardcore rotten that it's a wonder you don't hear every day about some compromised IoT device.
The ways to change this is either regulation or market pressure.
Regulation is out of any question, both in the US and the EU. While there may be some hard-won progress in the "right to repair" fights recently, the needs of hobbyist electronics people aren't on any politician's radar and I doubt that will change soon (even if easier access to high quality electronics could unleash so much potential for innovation!).
Market pressure is out of the question too, simply because the volumes that us hobbyists order are too small. For what it's worth I'd pay a couple hundred bucks for an 1:1 q&a/consulting session with an expert from a semiconductor or other company for my hobby projects and I'd also accept a reasonable "small volume handling/shipping fee" for getting my hands on ten chips... but I'm the utter minority of hobbyists who can actually afford that for a project that won't bring any profit. Corporate entities however who are going to sell thousands or orders of magnitude more units of some random gizmo can afford putting up six figures upfront anyway... so they have no incentive either to pressure vendors into providing better service.
Is in-house CPU printing a (future) possibility? I don’t know a lot about manufacturing, but is a an etching machine a possibility to make custom boards or chips? Even if it’s not up to today’s tech.
Not with current fab / material processes. Silicon Valley hosts the most Superfund sites in the US for a reason - there's an awful lot of really nasty chemicals involved in semiconductor manufacturing, some of which can probably be used to make drugs or explosives (so subject to various control laws), and the feature sizes are so small that the fabs require expensive air filters...
Custom boards are a thing already, you can go up to three layers in an amateur/hobbyist setting AFAIK, but that won't help you much when dealing with high-frequency stuff or very fine pitch settings as the thickness and other parameters will vary across the board. Many countries already have somewhat cheap-ish "rapid prototype PCB" shops, some even do assembly for you. That's good enough even for most HF stuff.
Are there any group buys that could be set up? Surely there are at least 43 people in the world who want to buy that part but don't want to buy the full MOQ
I'd be glad if the big shops (Mouser, Digikey, Conrad) could set up some pool solution... everything one can do as a private person opens up a hellhole of liabilities: international shipping (and tracking), return rights, warranties, import/export tariffs, import/export arms control (GPS receivers come to my mind), CE/RoHS compliance, international taxes (VAT, sales taxes, the US with their mind-boggling state/county/city additional taxes), supply chain integrity (people don't want their "pool buy" for 20 bucks turn out a counterfeit, and it's hard enough for big companies to secure that one).
It's almost like companies value their employee's time and don't want them dealing with non-profitable sales to hobbyists or buying small quantities to poke around and copy IP.
Overhead is typically 40-50% for this kind of corporation. So not really enough.
However the calculation has nothing to do with what guessing a reasonable hourly rate.
The issue is whether someone with the expertise to do this would benefit the company and their own career more doing something other than a tech support role.
> Overhead is typically 40-50% for this kind of corporation. So not really enough.
Even assuming 50% overhead something just short of 200k remains. I agree, for the US it may be on the lower end of the scale (given the ridiculous costs of housing and healthcare), but Europe or Asia? Way more than enough.
> The issue is whether someone with the expertise to do this would benefit the company and their own career more doing something other than a tech support role.
At least in my experience it is definitely good for people to spend time directly with customers. I agree it may not be worthwile for a chip developer or a documentation writer to spend their full time on doing support - but a set amount of time, say four or eight hours a week? That's direct, unfiltered input from the customers where the documentation is either missing, unclear or buggy.
Generic questions ("which combination of chips to choose if I have an USB-C female receptacle and want to provide bidirectional PD, bidirectional DisplayPort and USB3.2 over it") / 1:1 tutoring like "how do I best route a PCI-E differential lane pair", "how to properly calculate trace widths for said lanes given fab house X's stack specifications" can be directed to less specialist / sales staff or to a partner PCB design house.
“At least in my experience it is definitely good for people to spend time directly with customers. I agree it may not be worthwile for a chip developer or a documentation writer to spend their full time on doing support - but a set amount of time, say four or eight hours a week? That's direct, unfiltered input from the customers where the documentation is either missing, unclear or buggy.”
I agree that direct experience with customers is good for many engineers. It is definitely not good for all engineers.
However there is a huge difference between professional customers and hobbyists.
You are now taking about a multi-tiered support organization.
You personally may be willing to spend 200 euros per hour for access to such an organization.
The question is, are there enough customers like you to justify millions of Euros in investment to build such an organization.
Starting from the hourly rate you personally think engineers should be paid gives exactly zero information about the demand, and therefore zero information about whether such a rate is meaningful.
For first year(s?), Broadcom RPi components (GPU) were closed source (opaque binary blob) and need RE work. For a hardware supposed to be "open to hack", it was considered a non-sense. I suspect things have changed regarding RPi situation.
Intel has ME/AMT, and requires an opaque, PK-signed-and-only-intel-and-NSA-have-the-key blob. AMD is the same with PSP.
I'm not up to date, there might be a RISC-V core available today that is blob free, but in 2012 when RasPi was introduced I wasn't aware of anything blobless.
RISC-V is the best example of open hardware, but it also has a lot to do with the software. Take the GPU space, for example - NVIDIA has closed source blobs, but AMD has open source drivers which makes it easier to tinker with.
But why do you trust that the silicon doesn't have any backdoors more than you trust the blob? We know for a fact that Intel puts one into the silicon, and that it takes significant reverse engineering to turn most of it off (it's not clear if all of it can be turned off at all) see e.g. https://hackaday.com/2020/06/16/disable-intels-backdoor-on-m...
we're pretty much there. The new pi 4 compute module breaks out the pcie bus. The official pi4 compute base board routes that to a standard pcie x1 slot instead of USB 3.0 which is a massive win in my book (hello more ethernet/sata/fpga/nvme/etc). It's a baby Arm mobo with pci and I'm a little excited :-)
I have a pi4 compute + base board on pre-order plus I just bought a pcie x1 m.2 M-key card off amazon. I plan to use the SD card (emmc on my model) to boot a kernel and use the m.2 card for storage.
I think the pi foundation finally realizes that the pi has the potential of becoming an affordable and accessible SoM (system on Module) with a huge community behind it.
