7 ms·

Forgive my ignorance, but is this because of proprietary specs for HDMI or the graphics chip or something? As in, they are trying to reverse engineer the blob

Forgive my ignorance, but is this because of proprietary specs for HDMI or the graphics chip or something? 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?

Terry_Roll 5y ago
I think this is it. https://www.raspberrypi.com/news/a-birthday-present-from-broadcom/ 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."
- bennyp101 5y ago
  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?
  - EMIRELADERO 5y ago
    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"?
    - delusional 5y ago
      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.
      - bennyp101 5y ago
        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"
      - cleverca22 5y ago
        i have seen evidence that RPF cant properly modify some of the h264 blobs so they are instead patching the blob at runtime
    - deleted 5y ago
      [deleted]
    - deleted 5y ago
      [deleted]
    - simias 5y ago
      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.
      - bluGill 5y ago
        > 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.
- nukemaster 5y ago
  >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.
  - salawat 5y ago
    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.
    - yjftsjthsd-h 5y ago
      > 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.
  - sitzkrieg 5y ago
    well it also cant selectively turn off cores based on load either so
  - exikyut 5y ago
    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-card-runs-linux/ 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.)
0x0 5y ago
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.
- bennyp101 5y ago
  Oh cool, so its more than /just/ graphics code, theres a whole load of stuff that they would need to implement? I can see why they would want that to be their own - make the pi 100% open - but sounds like a mammoth task! (especially if its only 1 guy doing it?)
  - pas 5y ago
    > need to implement 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).
    - bennyp101 5y ago
      Oh so if it’s just for ssh then you can boot without the raspi-firmware part? Are there images without it?
      - crizzlenizzle 5y ago
        There’s also the serial console one could use
      - SotCodeLaureate 5y ago
        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.

Terry_Roll 5y ago

I think this is it. https://www.raspberrypi.com/news/a-birthday-present-from-broadcom/ 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."

bennyp101 5y ago
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?
- EMIRELADERO 5y ago
  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"?
  - delusional 5y ago
    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.
    - bennyp101 5y ago
      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"
    - cleverca22 5y ago
      i have seen evidence that RPF cant properly modify some of the h264 blobs so they are instead patching the blob at runtime
  - deleted 5y ago
    [deleted]
  - deleted 5y ago
    [deleted]
  - simias 5y ago
    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.
    - bluGill 5y ago
      > 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.
nukemaster 5y ago
>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.
- salawat 5y ago
  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.
  - yjftsjthsd-h 5y ago
    > 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.
- sitzkrieg 5y ago
  well it also cant selectively turn off cores based on load either so
- exikyut 5y ago
  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-card-runs-linux/ 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.)

0x0 5y ago

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.

bennyp101 5y ago
Oh cool, so its more than /just/ graphics code, theres a whole load of stuff that they would need to implement? I can see why they would want that to be their own - make the pi 100% open - but sounds like a mammoth task! (especially if its only 1 guy doing it?)
- pas 5y ago
  > need to implement 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).
  - bennyp101 5y ago
    Oh so if it’s just for ssh then you can boot without the raspi-firmware part? Are there images without it?
    - crizzlenizzle 5y ago
      There’s also the serial console one could use
    - SotCodeLaureate 5y ago
      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.