As a long-time rPi user and embedded developer, it’s really not about ideological purity (or at least not entirely). There are real ramifications for the lack of open documentation for the GPU interfaces on the Raspberry Pi that make it really hard to use (as in utilize) if not running a mainstream Linux w/ binary blobs and device overlays. The GPU even does the system startup and initial boot loading; it’s not just closed source, it’s also entirely opaque and undocumented (documentation only available for bulk purchasers from Broadcom and under NDA, purchasing Raspberry Pi in bulk doesn’t get you the SoC documentation).

(Unlike typical devices, the CPU doesn’t do system startup and initialize the GPU as an add-on or co-processor, on the Raspberry Pi the situation is more or less reversed.)

I mean, you're not wrong and it is open source at the app layer but it's not like Raspberry Pi is a purely software product. They're a hardware company, acting like a maker friendly, open source device - similar to Arduino (which btw is totally open source, even the bootloader and you can get data sheets for every single component on it), but it falls short with only the top app layer being open source. The middle layer (HAL, drivers, etc.) is all closed source. And hardware is closed source.

It's ok to be closed source IMO, but they should not be marketing themselves like Arduino folks.

Arduino is a for-profit company with open source hardware; Raspberry Pi is a charity with closed-source hardware.

Nothing wrong with either approach. But your comment makes out they're a for-profit company with closed-source hardware acting like the good guys.

Not sure it's fair to label them as just another company when they're not-for-profit and pump all their money into a) product development and b) education programmes.

To be honest, if the Pi was open source hardware, everyone would buy the clones (like they do with the Arduino ones) and the charity side would have much less funding.

> To be honest, if the Pi was open source hardware, everyone would buy the clones (like they do with the Arduino ones) and the charity side would have much less funding.

As opposed to now, when people buy such totally-not-clones as the Banana Pi and Orange Pi? For that matter, Arduino seems to somehow have stayed profitable in spite of getting murdered from every angle by the clones.

>For that matter, Arduino seems to somehow have stayed profitable in spite of getting murdered from every angle by the clones.

The clones are fine for simple stuff. But they really cut every corner possible, so even the chip is counterfeit, which means it doesn't behave like a real Arduino does. Deep sleep will use 1000x as much current on some clones compared to a real Arduino, for example.

You really can't only use clones. You have to develop/test on real Arduino hardware, then deploy to clones. Because the clones aren't reliable in their behavior.

The thing helping the Raspberry Pi fend off clones is their deal with Broadcom, not whether the board, firmware, and boot code are open or closed source. It's easy to copy the board and binary blobs either way. The closed nature of the boot code hurts tinkering without helping sales.

It's true that Broadcom is the reason why most clones are not as good as the Raspberry Pi but it is not because of the boot code. It's because Broadcom has a custom graphics chip that has nothing in common with the official ARM GPUs. Any effort into open sourcing the very popular Raspberry Pi will not help open sourcing other boards that have the way more common Mali GPUs. Raspberry Pis are their own island so to speak.

Furthermore, right now there the open alternatives for Broadcomm's chips just aren't nearly as good (at this price-performance point). They made a compromise.

The first binary blob you boot on a Pi is based on ThreadX, a proprietary OS now bought by Microsoft.

And this binary blob fucks up the thermal control as well.

> It depends on what layer you care about. At the application layer it is completely open.

I'm not down with this injection of skepticism. This is slipperly language trying to make a pretty clearly contrasted situation murky.

Sure, if you just need something to process instructions, maybe the well-defined cpu architecture is enough. But kernels need things like timers to run. They need USB hosts to attach keyboards & mice. They need GPUs to out things to screen. They need power management to not run hot. They need SD(-card) io to access storage.

Yes, you can run any code on an RPi, that is some definition of open. But it should be obvious that for this to be useful & prevalent, a lot more is required, and those layers being locked away, in proprietary systems, that we have to keep reverse-engineering usage of, is a huge detractor from civilization & it's functioning.

> you could claim that there are proprietary processes and supply chains for the hardware and material themselves

> Unless amateurs could build one from scratch you will never be satisfied.

I was not expecting slippery slope to descend quite so quickly! But perhaps you are right!

There is a lot of interest in open source chipmaking these days, and hopefully we indeed do start to see a re-opening of the foundries that lead to such growth & science in the 80's, that created so much progress. Companies like Oracle & IBM certainly seem to have similar desires, to insure that we can satisfy ourselves & learn & grow, first with OpenSPARC in 2005, and OpenPOWER in 2013 certainly indicate that some very big entities in the world see & understand the value of open, through and through. More recently, works like RISC-V & OpenROAD show architectures & processes are once again coming back into focus as a thing that people see the value in opening, in being able to work together in. Google is doing free chip fabrication runs to try to help re-grow this once proud & mighty but clearly ossifying sector that has undergone a massive wave of buy-outs & consolidation. Because we have to keep the knowledge & know-how alive & growing. Because people should be making chips. And too few are these days.

That all said, I think there's a pretty clear cut difference between what you are posting about "proprietary processes and supply chains" versus situations like what we have here, where Broadcom makes chips, then conceals & makes it difficult for anyone but a couple chosen embedded partners to understand or use those chips. It's a bit frustrating that Broadcom continues to use their own proprietary peripherals they've adapted over the decades versus using more off-the-shelf standard-operating peripherals. But it's not necessarily the proprietary bit that makes this so sticky: it's the overarchingly user-hostile attitude of this behemoth, the lengths they seemingly go through to keep amateurs out & away, in contrast to other companies that if not directly support at least don't obstruct upstreaming & open source driver development. I look at the wifi-router world, & Broadcom routers are basically get-what-you-buy now, no ability to customize or change OS. Broadcom used to allow alternate OSes, but since 802.11ac, they have more or less cut off access. This was always proprietary, but at least it was something we could learn about, interface with, but now, it is locked down.

I've heard some of Broadcom's stingeyness with documentation may stem from the risks created by the perverse environment created by IP laws. With a patent troll only one manual away, I can somewhat understand to a degree holding things close to your chest if you want to continue to exist.

I mean it sucks massively, but I can at least understand it. It's part of why I strongly disagree with the "IP" side of semiconductor products, and believe that we really need to treat everything about computing as if it were straight up math. Doing anything else simply ensures that the knowledge will only very slowly percolate outward in the process of becoming a naturally endemic proficiency of the average modern human.

IANAL, but it would seem that the more documentation you release on your patented product the MORE you are protected, since it becomes less likely that they independently discovered your solution.

I think the issue is more one less of Broadcom wanting protection as much as having a chip foundry and selling chips, but not wishing to risk a legion of Non-Practicing Entities combing through their implementations with a fine tooth comb and a portfolio of held semiconductor IP.