3 ms·
What's wrong with A or B? Obviously documentation would be ideal, but I still think an SoC with freely licensed source code available that talks to peripheral
by bri3d 5y ago
What's wrong with A or B?
Obviously documentation would be ideal, but I still think an SoC with freely licensed source code available that talks to peripheral devices directly qualifies as much more "open" than one where even "open source" drivers are actually just talking to mailboxes to a HAL running in an RTOS.
I think the challenge with the Broadcom stuff is fundamentally architectural - even with more reverse engineering eyes on the scene, you're working with an SoC that's a big proprietary blob running on an obscure architecture (VPU) which is hosting an ARM Linux box, vs. the Rockchip stuff which is a much more traditional model with memory and register mapped peripherals.
- Sirened 5y agoI am also a big Broadcom VideoCore hater (lol), but: >an SoC with freely licensed source code Free as in "GPL". The GPL is incompatible with a slew of other licenses and so being dependent on reading the Linux source for how to write drivers for your own OS is an incredibly perilous legal position should you not license your code under the GPL. Real documentation (for talking to blobs or real hardware) almost allows you to license your code however you please and so it is objectively more free. This, mind you, is not a hypothetical: I am quite literally in this position and have abandoned Rockchip SoCs (despite being all around better tech) because supporting them would possibly violate the project license and the rights of the other contributors. I can, however, support Broadcom SoCs because their documentation is freely available without licensing stipulations despite their non-free blobs. The Rockchip SoCs are free and open only to the extent you either like Linux or can adhere to the GPL, which is frankly a bizarre position to be in when trying to use an SoC.