6 ms·

The question I have, is: given how maker / oss focused the raspi is, how (and by whom) did they manage to get locked-in and forced to use this proprietary piece

The question I have, is: given how maker / oss focused the raspi is, how (and by whom) did they manage to get locked-in and forced to use this proprietary piece?

nikanj 5y ago
Because frankly the parts available with fully free internals are...not very good. How many people care about the raspi having decent performance vs how many people care about the binary blob?
tinco 5y ago
By the entire industry. There simply doesn't exist a chip that does the things a raspberry pi needs, that is free of proprietary software.
- ndsipa_pomu 5y ago
  RISC-V is probably the closest, but they're going to need to get faster to compete with ARM.
  - klelatti 5y ago
    As it's the GPU that seems to be the issue here is there a RISC-V based SoC with an open source GPU driver? Worth noting too that there is an open source driver for Arm's own Mali GPUs. https://www.collabora.com/news-and-blog/blog/2021/06/11/open-source-opengl-es-3.1-on-mali-gpus-with-panfrost/ https://www.collabora.com/news-and-blog/blog/2021/06/11/open...
    - aseipp 5y ago
      The GPU is not the issue. There are open source OpenGL ES drivers available in upstream Mesa right now, that work with upstream kernel DRM driver, and for RPi4 users there's even a Vulkan driver. It's been pointed out elsewhere but briefly there is a VLIW processor (the "VPU") that is initially in charge of the entire boot sequence before handing off control to the main ARM cores; the bootcode.bin firmware for RPi devices is exactly this code. This includes things like bringing up PLLs and the on-board UART before handing off control to the ARM core where "userspace" code runs. There are many free RISC-V implementations, and several free GPU drivers for various hardware families, but there is no combination of the two in any meaningful sense right now. If I had to guess I'd say ImgTec is probably one of the ones you could expect to pop up in an SoC somewhere, since I doubt ARM or Qualcomm are going to license their GPUs outside their families... ImgTec recently started contributing some code to Mesa but otherwise have historically been pretty hostile. So the immediate speculation doesn't look great at the moment but who knows what could happen.
      - my123 5y ago
        The VPU isn’t a VLIW at all, it’s an interesting RISC. Arm GPUs are also licensable by anybody, they were x86 phones with them back when those were still a thing.
        aseipp 5y ago
        Interesting, thanks for both the corrections. Curious, but do you know if there anyone still using Mali outside the ARM-licensed family at this point? I guess there haven't been many new entries to the mobile market for so long the GPU pairings seem natural, now...
- bo1024 5y ago
  Isn’t it right that there’s barely any hardware at all out there that can run fully foss?
- garaetjjte 5y ago
  If running without blobs is your priority, various Allwinner or Rockchip SoCs would be much better choice. (they run with upstream kernel, and aren't GPU with ARM core added as an afterthought)
- she46BiOmUerPVj 5y ago
  beaglebone
- megous 5y ago
  Not true at all. Pinephone runs on a SoC with no binary blobs user has to install. And the SoC can do all the stuff my Rpi 2b does, and more (has a proper audio codec, for one, real gigabit ethernet, working suspend to ram, etc.), does suspend to ram, accelerated video decoding, and has much more open documentation... Rpi 2b's soc is pretty terrible usability wise comapred to A64.
- squarefoot 5y ago
  It is actually the other way around since a lot of other boards use no proprietary blobs, either out of the box or can be easily adapted to do that. The RPi Foundation are without doubt good at making hardware, but they're even better at letting users believe they're the only player in that field.
mschuster91 5y ago
That's because the idea for the RPi came from Eben Upton, who worked at Broadcom at the time - and no one else had better chips or (and here it gets crucial) would make them available at the low quantities that were initially expected without serious up-front money to get access to technical documentation and experience. Creating a computing platform is - no matter the CPU vendor - one hell of an effort, often involving bunches of binary blobs of questionable quality, NDAs, buggy, outdated or plain lacking documentation and lots of money. The more effort you can save yourself (such as by using a product you already have experience with), the better.
- joezydeco 5y ago
  RPi1 was also built around a surplus SoC that was originally targeted for a set-top video player platform but failed to get any buyers.
Crosseye_Jack 5y ago
Ben Upton worked for Broadcom during the time of the creation of the Pi. Broadcom gave them a sweetheart deal on the processors, they took it. The Pi was initially created as a cheap way to get kids into computer science, they didn’t foresee the closed off parts of the processor being an issue towards that goal. They just wanted a cheap computer for kids to learn on that wouldn’t be the end of the world if they broke it. I mean who is gonna want to run an Open Source VideoCore? THEN, us “grown up” geeks came along and was like “OHHHH, a cheap Linux SBC… Yes Please…” and brought out the initial run on day one. So ever since then they were kinda stuck with Broadcom unless they wanted to redo a ton with another manufacturer. To Bens and Raspberry Pis credit, they have managed to get Broadcom more open than they were, Initially we didn’t even have a data sheet for the processor. Edit: Pre-coffee brain even more prone to typos then when I’m caffeinated…
- 3np 5y ago
  There must be more to it than that, considering all the generational change otherwise.
  - wronglebowski 5y ago
    I disagree, pioneering SBCs on a non-profit budget means this one hitch on binary blobs is a very low priority for them. Working with the same vendor consistently to iterate on a very similar design each time is ideal.
    - 3np 5y ago
      Well, that right there does count as "more to it"
  - Crosseye_Jack 5y ago
    > considering all the generational change otherwise Sorry, my brain is not fully in gear yet. Do you mean the changes between the generations of the Pi?
- mattl 5y ago
nazgulsenpai 5y ago
As I understand it, it was a SoC that was already in production by Broadcom for set top boxes so using an "off the shelf" SoC would reduce the time/cost required to bring the original Pi to market. I imagine there would be less risk to the manufacturer in this case since, if the Pi proved a failure and didn't move the expected units, the SoC could be repurposed for STBs.
nukemaster 5y ago
My understanding was the raspberry pi was supposed to be the modern zx80: cheap above all else to make it easy for kids to get a computer.
- q-oscillator 5y ago
  And it pretty much is, especially the older versions of the Pi. It just has a large number of uses beyond education.
rkangel 5y ago
The Raspberry Pi was basically only possible because of the Broadcom SoC. It is a capable chip, with approximately the right set of functionality for an SBC and at a good price (because it was already manufactured in volume). It was only available for something like the Raspberry Pi because Eben Upton worked for Broadcom and so could get to buy the chips and buy them at volume pricing - normally you'd have to have an established buyer relationship and be able to guarantee to buy far more than the Pi team was able to or expecting. It's also worth remembering that originally the Pi wasn't maker/OSS focused - the goal was to have a computer cheap enough to be used for computing education in schools. In effect a modern day successor to the BBC Micro. In the context of the goals and constraints the "minor" binary blob required to make it run was irrelevant. Even more so as basically every other similar SoC has exactly the same issue. The Broadcom parts presumably continue to remain competitive for their capability level and so they keep getting used but now thanks to the success of the Pi there is the will and capability of going full OSS.

The question I have, is: given how maker / oss focused the raspi is, how (and by whom) did they manage to get locked-in and forced to use this proprietary piece?

nikanj 5y ago

Because frankly the parts available with fully free internals are...not very good. How many people care about the raspi having decent performance vs how many people care about the binary blob?

tinco 5y ago

By the entire industry. There simply doesn't exist a chip that does the things a raspberry pi needs, that is free of proprietary software.

ndsipa_pomu 5y ago
RISC-V is probably the closest, but they're going to need to get faster to compete with ARM.
- klelatti 5y ago
  As it's the GPU that seems to be the issue here is there a RISC-V based SoC with an open source GPU driver? Worth noting too that there is an open source driver for Arm's own Mali GPUs. https://www.collabora.com/news-and-blog/blog/2021/06/11/open-source-opengl-es-3.1-on-mali-gpus-with-panfrost/ https://www.collabora.com/news-and-blog/blog/2021/06/11/open...
  - aseipp 5y ago
    The GPU is not the issue. There are open source OpenGL ES drivers available in upstream Mesa right now, that work with upstream kernel DRM driver, and for RPi4 users there's even a Vulkan driver. It's been pointed out elsewhere but briefly there is a VLIW processor (the "VPU") that is initially in charge of the entire boot sequence before handing off control to the main ARM cores; the bootcode.bin firmware for RPi devices is exactly this code. This includes things like bringing up PLLs and the on-board UART before handing off control to the ARM core where "userspace" code runs. There are many free RISC-V implementations, and several free GPU drivers for various hardware families, but there is no combination of the two in any meaningful sense right now. If I had to guess I'd say ImgTec is probably one of the ones you could expect to pop up in an SoC somewhere, since I doubt ARM or Qualcomm are going to license their GPUs outside their families... ImgTec recently started contributing some code to Mesa but otherwise have historically been pretty hostile. So the immediate speculation doesn't look great at the moment but who knows what could happen.
    - my123 5y ago
      The VPU isn’t a VLIW at all, it’s an interesting RISC. Arm GPUs are also licensable by anybody, they were x86 phones with them back when those were still a thing.
      - aseipp 5y ago
        Interesting, thanks for both the corrections. Curious, but do you know if there anyone still using Mali outside the ARM-licensed family at this point? I guess there haven't been many new entries to the mobile market for so long the GPU pairings seem natural, now...
bo1024 5y ago
Isn’t it right that there’s barely any hardware at all out there that can run fully foss?
garaetjjte 5y ago
If running without blobs is your priority, various Allwinner or Rockchip SoCs would be much better choice. (they run with upstream kernel, and aren't GPU with ARM core added as an afterthought)
she46BiOmUerPVj 5y ago
beaglebone
megous 5y ago
Not true at all. Pinephone runs on a SoC with no binary blobs user has to install. And the SoC can do all the stuff my Rpi 2b does, and more (has a proper audio codec, for one, real gigabit ethernet, working suspend to ram, etc.), does suspend to ram, accelerated video decoding, and has much more open documentation... Rpi 2b's soc is pretty terrible usability wise comapred to A64.
squarefoot 5y ago
It is actually the other way around since a lot of other boards use no proprietary blobs, either out of the box or can be easily adapted to do that. The RPi Foundation are without doubt good at making hardware, but they're even better at letting users believe they're the only player in that field.

mschuster91 5y ago

That's because the idea for the RPi came from Eben Upton, who worked at Broadcom at the time - and no one else had better chips or (and here it gets crucial) would make them available at the low quantities that were initially expected without serious up-front money to get access to technical documentation and experience. Creating a computing platform is - no matter the CPU vendor - one hell of an effort, often involving bunches of binary blobs of questionable quality, NDAs, buggy, outdated or plain lacking documentation and lots of money. The more effort you can save yourself (such as by using a product you already have experience with), the better.

joezydeco 5y ago
RPi1 was also built around a surplus SoC that was originally targeted for a set-top video player platform but failed to get any buyers.

Crosseye_Jack 5y ago

Ben Upton worked for Broadcom during the time of the creation of the Pi. Broadcom gave them a sweetheart deal on the processors, they took it. The Pi was initially created as a cheap way to get kids into computer science, they didn’t foresee the closed off parts of the processor being an issue towards that goal. They just wanted a cheap computer for kids to learn on that wouldn’t be the end of the world if they broke it. I mean who is gonna want to run an Open Source VideoCore? THEN, us “grown up” geeks came along and was like “OHHHH, a cheap Linux SBC… Yes Please…” and brought out the initial run on day one. So ever since then they were kinda stuck with Broadcom unless they wanted to redo a ton with another manufacturer. To Bens and Raspberry Pis credit, they have managed to get Broadcom more open than they were, Initially we didn’t even have a data sheet for the processor. Edit: Pre-coffee brain even more prone to typos then when I’m caffeinated…

3np 5y ago
There must be more to it than that, considering all the generational change otherwise.
- wronglebowski 5y ago
  I disagree, pioneering SBCs on a non-profit budget means this one hitch on binary blobs is a very low priority for them. Working with the same vendor consistently to iterate on a very similar design each time is ideal.
  - 3np 5y ago
    Well, that right there does count as "more to it"
- Crosseye_Jack 5y ago
  > considering all the generational change otherwise Sorry, my brain is not fully in gear yet. Do you mean the changes between the generations of the Pi?
mattl 5y ago

nazgulsenpai 5y ago

As I understand it, it was a SoC that was already in production by Broadcom for set top boxes so using an "off the shelf" SoC would reduce the time/cost required to bring the original Pi to market. I imagine there would be less risk to the manufacturer in this case since, if the Pi proved a failure and didn't move the expected units, the SoC could be repurposed for STBs.

nukemaster 5y ago

My understanding was the raspberry pi was supposed to be the modern zx80: cheap above all else to make it easy for kids to get a computer.

q-oscillator 5y ago
And it pretty much is, especially the older versions of the Pi. It just has a large number of uses beyond education.

rkangel 5y ago

The Raspberry Pi was basically only possible because of the Broadcom SoC. It is a capable chip, with approximately the right set of functionality for an SBC and at a good price (because it was already manufactured in volume). It was only available for something like the Raspberry Pi because Eben Upton worked for Broadcom and so could get to buy the chips and buy them at volume pricing - normally you'd have to have an established buyer relationship and be able to guarantee to buy far more than the Pi team was able to or expecting. It's also worth remembering that originally the Pi wasn't maker/OSS focused - the goal was to have a computer cheap enough to be used for computing education in schools. In effect a modern day successor to the BBC Micro. In the context of the goals and constraints the "minor" binary blob required to make it run was irrelevant. Even more so as basically every other similar SoC has exactly the same issue. The Broadcom parts presumably continue to remain competitive for their capability level and so they keep getting used but now thanks to the success of the Pi there is the will and capability of going full OSS.