3 ms·
rpi is one of the most closed SBCs there is. Even basic materials necessary to write OSes and drivers for the device, namely datasheets and register manuals for
by hlandau 6y ago
rpi is one of the most closed SBCs there is. Even basic materials necessary to write OSes and drivers for the device, namely datasheets and register manuals for the SoC have never been published. Unlike every other SBC I'm aware of they don't even publish full schematics. The "schematics" on their website are abridged (try and find the USB ports on them).
Arguments that Broadcom is forcing their hand on this simply don't add up. It's not Broadcom that's stopping them from publishing even basic schematics of the board; that was their decision. Sure, they'd never be able to open the chip itself, but nobody is particularly asking them to (it's not like people have fabs in their garages).
Moreover it's pretty clear at this point that Broadcom is making SoCs custom-order for rpi at this point; see their original announcement on the rpi4, which makes it quite clear they were involved in the design process. Based on what I know about Broadcom's MO, it's simply not plausible that with that amount of money on the table, release of datasheets and register manuals couldn't be negotiated; it seems clear it's not a priority for rpi.org.
And as mentioned, rpi boards include vendor-lockin DRM in their binary blob boot firmware designed to prevent people from using third-party camera boards.
Not only is this unacceptable in itself, it also means rpi is actively depending on this boot firmware remaining closed, else people could easily remove this antifeature. People have been hoping for years that the firmware blobs required to boot the boards will eventually be opened, and pointed to some vague noises in this direction which were made by rpi.org years ago, but the fact that they're now relying on the fact of it being closed to enforce DRM causes me to find this increasingly unlikely.
- avian 6y ago> Arguments that Broadcom is forcing their hand on this simply don't add up. I have worked with much more mundane integrated circuits where the manufacturer required you to sign an NDA before getting any kind of design support from them. One of the terms of the NDA was not publishing the schematic of the device using their product. I don't see why Broadcom wouldn't do something similar for their SoCs.
- hlandau 6y agoA few things. Broadcom is notorious for demanding NDAs for their datasheets, completely pointlessly. I've also heard of companies demanding their parts be redacted on schematics if published, even more ridiculously, though as far as I know Broadcom isn't one of them (I've seen public schematics with Broadcom parts). Still, from what I've heard of Broadcom specifically, they're pathologically secretive with their documentation unless some star customer dangles enough money in front of them. rpi.org certainly fits that description. So I don't really buy this excuse for rpi here. In reality, I suspect it's more the fact that rpi.org was started by ex-Broadcom engineers and they brought their culture of secrecy with them.
- avian 6y agoThese things can be completely irrational in my experience. One part I was working with had a driver upstreamed in the Linux kernel, you could buy off-the-shelf devices for cheap that had it on the PCB and I even found a company that was apparently selling a complete set of layer-by-layer die shots of that part for around $1000. Yet the chips weren't sold by any distributor. To even just get engineering samples from the manufacturer you had to sign this draconian NDA that covered everything from software to hardware docs even remotely connected to their part. Even after signing the NDA they wouldn't disclose full datasheet for e.g. what some registers did. For some things the comments in the Linux kernel turned out to be more informative than anything we got through official channels. But if they're the only source of parts you have to use, you have to dance by their rules. Ruin the relationship by breaching the NDA and you might just as well bury the product you spent a year developing.
- deleted 6y ago[deleted]