Comment by Terry_Roll | Hacker News Reader

Comment by Terry_Roll | Hacker News Reader

Parent Full thread

I think this is it. https://www.raspberrypi.com/news/a-birthday-present-from-bro...

The Broadcom Blob

"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."

Ah ok, so Broadcom have said it's ok to write the drivers, but it's a slow slog to actually get a working set of drivers written from scratch?

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"?

Could be a case that Broadcom bought the software blob (in whole or in part) and don't have the rights to release is publicly.

Yea, maybe its a way to get around their legal requirements - "here are the ingredients, but you need to figure out the recipe kinda thing"

i have seen evidence that RPF cant properly modify some of the h264 blobs so they are instead patching the blob at runtime

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.

> what do you have to lose?"

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.

> They don't see what they have to gain by releasing the code, but they worry that it may create issues if they do.

If they don't gain/loose anything but we gain something, I see a net positive for society.

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.

> Societal benefit doesn't make their list.

Then I'm happy I'm not such a lawyer.

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...

It's running on a proprietary RTOS.

> 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.

NSA helped a lot with that last one...

>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.

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.

> Unless you meant to make your PDA out of a <4 RPi.

They did say Raspberry Pi zero. And the pi 3 would IMO be perfectly fine for that use case.

well it also cant selectively turn off cores based on load either so

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.

FWIW, the Allwinner F1C100s is ~$2, 533MHz, has 32MB RAM onboard, and can run mainline recent Linux. It's also this easy* to plonk onto a PCB: https://www.thirtythreeforty.net/posts/2019/12/my-business-c...

(* 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.)

Reply on news.ycombinator.com