The Broadcom chip, yes, but the NDA-encumbered firmware has been reduced to such an extent that you can in fact boot this either fully-functional with very few closed blobs, or almost-fully-functional with no closed blobs at all.
All device drivers onwards are just open and can be kept up to date and used in custom kernels all you want. This is the big difference with other SBCs where you can't really use the devices without closed, version-locked drivers and blobs, and there is no incentive for the manufacturer to make a super-thin encumbered shim to give the most leverage and freedom for everyone else to build on top of that.
The popularity didn't arrive before the intent and work was done to make it hackable, it was the other way around. That, in turn, created the mindshare to make community-driven drivers and alternate firmwares for the VideoCore boot stage.
This is also why they kept the BCM lineage as simple as possible across the PI revisions so all the public reverse engineering and hard work wasn't for nothing and was still portable.
None of this can be said about any RockChip, MediaTek or HiSilicon SoC. Those are more of a consume-and-throw-away type of deal, except for maybe the high-end long-life platforms that share IP with Android devices that also happen to have PM-OS or some XDA fanbase to work on it. Even then they usually lack community knowledge and commercial effort to make it worthwhile.
The closest was the TI-based series like the BeagleBone, and that was for precisely the same reason the Pi got a good start. The bad thing about the BeagleBone was that it didn't have a "see something on your monitor out of the box" experience.
There's also the Olimex boards (and related Freedombox project)[1], which can boot with no binary blobs :)
They have an interesting philosophy in their definition of OSHW includes making it easy for others to produce their boards. So not just publishing schematics, but facilitating manufacturing as much as possible.
> Olimex's A20 OLinuXino Lime2 is a fully Open Source Hardware (OSHW) single board computer. This means that the designer is actively helping people using the platform for their own designs, and supports them in adding hardware functionality and production advice. This is a part of freedom that is often overlooked, but very much aligned with the FreedomBox goals.
The issue with the AllWinner Sunxi chips is somewhat similar to the VideoCore booter where an internal ROM is required to boot the CPU; this has been open sourced somewhat recently, but we can't really inspect or change it.
On the other hand, it's not really that much of a big deal since unlike some other chips, it doesn't lock you out of anything, it just does normal basic stuff like making sure the WDT doesn't reset your CPU before you have had a chance to setup the bare minimum of registers and interrupt tables. For me, I'd either have a chip that has a boot vector outside of itself (i.e. some fixed SPI address) or something so small and measurable that it doesn't really matter much (like this BROM).
The big 'next gen' problem we have is somewhat separate but regarding root of trust in hardware it's nearly impossible to make trusted hardware (from a software perspective) without some device specific PKI that is inside the main CPU and cannot be modified from the outside. The big downside is that there is no way to do this after the fact (otherwise a malicious person could do the same), and doing it ahead of time ties it to the hardware vendor or even the chip fab. Sharing things like private keys to whoever buys the chip doesn't work either, as that would make all of the other chips vulnerable as well. PKI-per-chip doesn't work either, as you wouldn't want to maintain a PKI and re-sign everything for evert individual chip.
eFuses seem to be the only other way, or (E)PROM, but those can be attacked using power hacks (i.e. using a ChipWhisperer).
Perhaps a free and open hardware root of trust is just not feasible.
i have olimexs sunxi boards and they have a blob bootloader with no sources so they are not completely covered, only hardware as it mentions. but this is common for arm of course.
on the flipside thats still leagues above rpis and you can buy the chips for your own use unlike the broadcom ones
Thun sunxi family of chips is really badly supported by the manufacturers, but the mainlining effort (as documented at https://linux-sunxi.org/Linux_mainlining_effort) is going pretty well. It's still a bit risky if you don't buy an entire integration package from one of the big vendors and at that point you're NDA'ed so hard you might as well go Broadcom or Qualcomm.
BeagleBones also don't seem to get updated very often. The BeagleBone black is overdue for a version 2 with a faster CPU, double the memory, and double the built-in eMMC; especially at the $50 price point.
The i.MX SoCs seem really nice, it's probably one of the few mainstream ones I haven't personally worked with (only wrote software that targeted it while fully remote).
Most of the fully open designs seem to be limited to a handful of silicon like Freescale PowerPC, a few ARM and MIPS SoCs and RISC-V-based systems which can still have closed Boot ROMs of course (like Intel and AMD x86 CPUs).
At some point I had high hopes there would be a reverse engineering effort for the Marvell Armada chips but that never really went anywhere and a ton of otherwise useful boards are essentially useless nowadays.
I dunno. I've been shipping iMX-based designs for over a decade now and I think it's about as open as you can get. Yeah, there's a blob for GPU and a microcode blob for DMA-based blocks but otherwise I can whip u-boot and a Yocto package and make it do whatever I want. If you need a desktop to make your system fly, I don't know what to tell you.
IMO the people stressing about open designs are the ones that don't want to pay for anything above RPi prices. Like I said: job security.
It's not immune to supply issues as well, but that's because a ton of mid-range automakers use it in their IVI systems. The 7 is a safe haven because it doesn't have the video and camera codecs in hardware.
I keep an eye on RISC-V as well, but until I can get one with a 5-10 year production horizon I'll wait to order eval kits.
Yeah the near-term and long-term RISC-V products haven't materialised yet. Software hasn't matured all that much either.
I was looking at the iMx8 but like you said, anything with automotive or embedded applications in mass produced systems is hard to get. I've seem them used in security devices that do a bit of on-device pre-authentication and even there I'm hearing about supply issues. It was mostly Apalis COM based but they had the benefit of switching between a Tegra and iMx version whenever supply was getting constrained. (or essentially the prices started getting bumped before the next order cycle) I think the lead times for some models became over 36 months at some point (either the imx8 ones or the Tegra ones)... yikes.
Regarding the GPU and DMA blocks: that seems to be the standard at this stage. I guess it's because it's mostly licensed IP and because they need to honour the NDA from their upstream vendor, we're just getting the blobs as a side-effect. Same with the Zinq and some of the Sitara GPU cores they got from PowerVR. Luckily, that last one has gotten a lot of FOSS attention and besides loading some startup firmware or microcode it's largely free.
The whole 'freedom' thing doesn't have to be an ultimate goal here, but it does have the nice side-effect that it opens up the use of mainline source trees, broadly used and well-maintained tools and toolchains etc. instead of just some giant tarball the vendor prepared for a specific kernel and boot loader combination. And if the vendor decides to focus on the next new shiny thing, you can just port/upstream sources as needed to keep your project going, vendor be damned.
I've been using Toradex as well lately because of the pin compatibility. Apalis and Colibri are pretty solid products. Kind of makes me wish the SOM standardization movement hadn't fizzled out because that might have made some of the supply issues less problematic. Or maybe not.
Also, the SODIMM connector is long in the tooth and gives off a shitton of RF radiation especially when you're driving an LCD over the rails. But the alternatives like the Hirose mezz connectors aren't optimal either.
NXP/Freescale's kernel isn't the greatest but at least they try to get close to mainline. TI gets a thumbs up as well.
Oh yeah, the interface definitely leaves a lot to be desired. It's almost like it's getting PC104-legacy-ish at this point. On the other hand, the high density interconnects (even the ones way back from when Motorola and Apple started to make PowerPC daughter boards) are a PITA to work with when you need to do anything except one-off assembly...
Perhaps some form factor with a required low-density power + slow data interface and an optional high-density high-speed data interface would be the sweet spot. But if even something like M.2 standardisation tells us anything, even that is going to be a mess.
I guess we're stuck with foil tape for the time being.
