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.
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.
[1] https://wiki.debian.org/FreedomBox/Hardware/A20-OLinuXino-Li...
[1b] https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXino-...
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.
on the flipside thats still leagues above rpis and you can buy the chips for your own use unlike the broadcom ones
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.
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.
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.
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.
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.