ARM architectures also suffer from this. You'll be hard pressed to find a board that doesn't require a propriety board support package somewhere in the stack.
Ironically, it is usually the bootloader that is/requires a blob or it is the DTB.
I remember being in middle school and reading Stallman's articles on the dangers of a TPM-oriented push by manufacturers. As cliche as it is, Stallman was right.
The push for platform security is also a push for platform ownership. Tinkering/hacking/your ability as a hardware owner is at ends with corporate security needs and that is a shame.
Most Allwinner chips can run an entirely open-source stack and there's quite a few hobbyist-oriented boards out there based on them. (Technically the ROM bootloader is closed source, but all it does is load your choice of bootloader into RAM and execute it. After that you have full control, including the ability to run code in TrustZone mode and on the supervisor CPU core if one exists.)
IIRC Allwinner does not have public datasheets, and honestly I prefer to have an half-documented half-accessible x86 platform rather than a theoretically fully-accessible ARM one that in practice is 1/10 publicly usable (the cpu alone is not enough to have fun with a platform... especially in the ARM SoC world -- and existing drivers have never replaced a good documentation of the hardware they drive.)
While TrustZone can implement DRM, it is not a closed management engine. If you control the board, you can load your own OS there (but, conversely, if you cannot load your own OS there, you do not control the board).
The boot ROMs on these things are proprietary, though. The vendors I've talked with have been extremely coy about what's in them (got an overview from Marvell once, spent a day looking at code on a projector screen and getting a walkthrough. They could have hidden much).
The boot ROM typically gets out of your way pretty quickly, though. At worst it means you have to deal with some firmware-signing nonsense before chaining into a Linux kernel (or U-Boot); it isn't active in a running system.
I should add that the code we saw may not have been the code that was actually run. It had reset vectors and whatnot, but that's no guarantee there were no hidden ROMs that ran code before the code we reviewed got run. And it's certainly no guarantee there are no hidden hardware-level state machines that unlock . . . things. Things like ignoring X bits in pages, or being able to do some low-bandwidth computation with code embedded at the stenographic level.
I don't really do GPU-intensive stuff on it. It renders webpages & youtube fine, which is probably the most graphical intensive stuff. I'm currently using it mostly for porting MuseScore to arm, mainly using qtcreator for development.
The external hdmi doesn't really work properly...I remember not being able to run external monitor in full screen, or at the same time as the lcd screen.
I just installed and ran glxgears. It gets 250 FPS and a default window size. But I do get an command line error libGL error: unable to load driver: rockchip_dri.so, so I don't think I'm getting GPU.
so jealous... I've tried to replicate that setup on my C201 but kept hitting issues. I might give it another shot some day soon. Does Libreboot make it easier to boot from SD/USB?
Lucky. I have to hunt around for DTBs based on modified Rockchip and Freescale SoCs to update my devices.
I am unwilling to distribute said binaries to make it easier for people with the same hardware as I to update their 3 year old software. That, too, is a shame.
You don't even need a secondary tool. The standard devicetree compiler, dtc, can convert a dtb back into a dts no problem. The dtb format is a pretty basic serialisation of the dts file, so fairly little information is lost (mainly pre-processor stuff like includes and some macros for constants) and you can easily round-trip.
Ironically, it is usually the bootloader that is/requires a blob or it is the DTB.
I remember being in middle school and reading Stallman's articles on the dangers of a TPM-oriented push by manufacturers. As cliche as it is, Stallman was right.
The push for platform security is also a push for platform ownership. Tinkering/hacking/your ability as a hardware owner is at ends with corporate security needs and that is a shame.