"In common with every other ARM-based SoC, using the VideoCore IV 3d graphics core on the Pi requires a block of closed-source binary driver code (a “blob”) which talks to the hardware. In our case, this blob runs on the VPU vector processor of the BCM2835 (the SOC or System On a Chip at the heart of the Raspberry Pi); our existing open-source graphics drivers are a thin shim running on the ARM11, which talks to that blob via a communication driver in the Linux kernel. The lack of true open-source graphics drivers and documentation is widely acknowledged to be a significant problem for Linux on ARM, as it prevents users from fixing driver bugs, adding features and generally understanding what their hardware is doing.
Earlier today, Broadcom announced the release of full documentation for the VideoCore IV graphics core, and a complete source release of the graphics stack under a 3-clause BSD license."
Which is also confusing. What IP would Broadcom be "losing" by not releasing the driver code but still making the specs and implementation documents public? Is it just an out-of-spite decision, something like "I'm not gonna help a potential competitor that much"?
For many companies releasing their code is not something they would usually consider, regardless of whether it offers a competitive advantage or not. It's just not in the culture. They don't see what they have to gain by releasing the code, but they worry that it may create issues if they do.
So basically if you want to convince these companies to open source some of their components "what do you have to lose?" is not good enough, you have to give them an actual incentive. I suspect that outside of places like HN very few people really care about Broadcom's binary blob in the rpi.
The problem with this is there are unknowns. Maybe nothing, but if there is something none of us have even thought of that can be a big loss. It is really hard to get past this fear.
Unfortunately that's not usually a good enough motivation for most companies. To be clear, I'm not arguing that I don't think it would be a good thing for them to release the code (I most certainly would welcome a fully open source rpi), I've just been confronted to this mindset a lot at work. Closed source is the default, releasing anything publicly means going through many hoops and levels of hierarchy. If there's no obvious benefit for the company and you don't have insiders strongly pushing for it it won't happen.
My bet — and IANAL — is that a corporate lawyer looks at the idea and sees no benefit, but an unknown, probably small, increase in potential liability. In that case why would they approve it? They're not evil, particularly, but they are analyzing the situation in terms of risk and benefit. Societal benefit doesn't make their list.
Also, the lawyer can skim-read the technical documentation, and even if they don't really understand it, they can reassure themselves that if there were any legal issues in it they would have noticed them. By contrast, few lawyers can read code, so they can't give themselves the same reassurance with respect to it.
From what I know about the graphics industry, it's not necessarily about losing your IP, it's about exposing your IP for litigation. There are some big patent trolls out there as well as some very well known names who will exercise their legal department, so the natural thing companies tend to do is to keep things closed. Things will become more interesting as more open source SoCs appear...
> What IP would Broadcom be "losing" by not releasing the driver code
what if there's some IP they licensed from another vendor in there somewhere and it's so entangled (or foundational - eg graphics IP, etc) that they can't release it at all?
what if there's some IP that they don't realize is licensed from another vendor and they get in trouble?
what if there isn't, but someone else says there is, function X is too close to our implementation, and it starts a big legal battle? Or what if you run into some patent troll who makes a business out of digging through code to find anything they can sue over?
what if there's some copyleft code some dumbshit engineer copy/pasted and it ends up leveraging the whole codebase open?
etc etc
This is a classic situation of "Broadcom gains nothing in the next quarter or even the next 5 years from releasing the source, only potential (if unlikely) downsides, and the only people who will be outraged are a handful of nerds who are ultimately irrelevant to Broadcom's (not RPi Foundation's) business".
It is a testament to the success of copyleft that people have now embraced that as the default and view proprietary stuff with outright suspicion just as a default, but a proprietary strategy is both legitimate operationally (nobody opens everything) and as a risk-mitigation strategy.
>Earlier today, Broadcom announced the release of full documentation for the VideoCore IV graphics core, and a complete source release of the graphics stack under a 3-clause BSD license."
Does this mean the Raspberry Pi might get suspend to ram support? That would make building a PDA out of eg the Raspberry Pi zero which gets decent battery life feasible.
I honestly feel like building something like a PDA would be easier using a bespoke layout. You can entirely remove stuff you don't need (like, say, the VPU (lol)) and save battery life. You can also optimize for what you're actually going to be using, eg once you've selected the type of display you can just support the type of interface it will use (SPI perhaps), etc.
(* Yes, "easy" is relative. You'll need a few interesting tools and it'll be a tad deer-in-headlights. But you don't need a rocket science degree to even fathom the idea.)
Remember, that's Videocore IV they released, not VI. I'm still in the reacquaintance phase of getting familiar with HW again, and the devil always seems to be in the details.
Unless you meant to make your PDA out of a <4 RPi.
Also worth noting is the VPU is "the boss" on a raspi device and is responsible for bringing up the arm CPU. Without functioning VPU firmware, the arm CPU that linux runs on doesn't even start. Even if you don't care about graphics at all.
I think "need" implies too much. Because, for example, for 100% headless applications the open+free version is already viable. (But in practice everyone wants to debug using the HDMI from time to time, mostly because almost noone has NTSC lying around.)
Also, without looking at the docs of the VPU, I'd guess that most of the blob functionality is needed for advanced vector stuff and whatnot (so it's only needed if you want to implement OpenGL/EGL/WebGL).
No, you can't boot into ARM code without it.
ARM part is disabled power-on, VPU is a general purpose processor really.
Basically, on start-up it loads its start.elf (i.e. boot application compiled for its instruction set) from boot-media, initializes some hardware, then loads ARM boot image into common memory, then starts ARM.
It also exposes some low-level hardware interface via syscall-type "mailbox" interface.
It looks like, per https://github.com/librerpi/lk-overlay#what-features-work , yes you can boot to Linux on a Pi 2 with composite video and ... it doesn't use the word headless anywhere, but I'd be very surprised if you can't just omit video outputs completely.
EDIT: Actually, reading more carefully it looks like there might be more than one blob and it's not 100% clear to me which this replaces, so now I'm less sure that you can boot without any proprietary blobs. I'm not sure that you can't, but I can't tell.
Note that the above is specific for the Pi 3 - the Pi 4, for instance, doesn't have the issue of a ridiculously undersized power connector (2.5W minimum standard for up to 13 W demand !!)
As in, they are trying to reverse engineer the blob bits to make everything completely free?
Is it a legal problem rather than a technical one kind of thing?