15 ms·

How is the free firmware for the Raspberry progressing?

346 points by JNRowe 5y ago

ur-whale 5y ago
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.
bennyp101 5y ago
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"?
      - 5y ago
inherently 5y ago
the only problem mentioned was video stuff. does this mean that for a headless server use case it's usable?
- fsflover 5y ago
  No: https://news.ycombinator.com/item?id=31000966 https://news.ycombinator.com/item?id=31000966.
  - yjftsjthsd-h 5y ago
    Yes: https://github.com/librerpi/lk-overlay#what-features-work https://github.com/librerpi/lk-overlay#what-features-work (Albeit, currently only on a Pi 2) 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.
    - cleverca22 5y ago
      lk-overlay contains many different projects using the vc4-stage1, vc4-stage2, and rpi2-test projects together, you can do the entire boot chain (dram init and loading linux) using open source code other projects act as demo's or tests on how to run custom code at various stages, but not actually boot linux on the arm core many of those demos work on the the entire pi model range pi3 support is only broken due to arm side problems, which could be fixed by just using a different bootloader and the https://github.com/librerpi/rpi-open-firmware https://github.com/librerpi/rpi-open-firmware codebase can already boot linux headlessly on both pi2 and pi3, it uses a different arm bootloader
bri3d 5y ago
Another interesting part of the Raspberry Pi VideoCore blob is that it implements DRM for Raspberry Pi products: the Pi Camera V2 has an Atmel ATSHA204A CryptoAuthentication chip on it and uses an HMAC+nonce challenge/response system to authenticate with the VideoCore blob when it goes to bring up the CSI interface. Marcan42 dumped the keys from the VideoCore blob and documented the system a few years ago. According to the Pi Foundation, this is because simple peripherals are too easy to clone and they need to recoup their investment in accessory design. I was reminded of this while I was researching Twitter speculation yesterday that something similar is done for the DSI interface for displays. I wasn't able to substantiate this - the FKMS (FakeKMS/FirmwareKMS) and proprietary Raspberry Pi video drivers, where link negotiation and backlight control is done in the blob, do only support specific displays. However, it's unclear to me if this is due to driver support or an intentional lock-in. The open-source KMS driver (not yet usable on Raspberry Pi 4) where link negotiation and backlight control is done in the kernel, of course supports anything with a driver.
- ChuckNorris89 5y ago
  >According to the Pi Foundation, this is because simple peripherals are too easy to clone and they need to recoup their investment in accessory design. I find this completely fair, but then maybe don't call yourself a "charity" and an "open platform" and just be upfront that you need to lock down your hardware to recoup the investment.
  - sokoloff 5y ago
    I don’t object to the use of “charity” nearly so much as “open platform” in this case. A charity that gives away some things but not other things is still a charity. A platform that is partially closed is not fully open.
    - deleted 5y ago
      [deleted]
    - nmstoker 5y ago
      They've always been pretty clear about which parts that simply couldn't open up, due to restrictions beyond their control.
cf141q5325 5y ago
Shout out again to the interesting perspective on the topic from the IpFire Forum. Some excerpts: >Now, everybody is looking for a cheap ARM board with performance and loads of features. The Raspberry Foundation is a charity that pays probably no tax at all, but somehow is selling lots and lots of boards at an absolutely “amazing” price. >Amazing because nobody else in Europe can compete with them. Paying no taxes helps. The second step is that they have almost completely outsourced their software development. They call it Open Source-ed, but that is not the same. >Over many years, there has never been a release of that piece of hardware that was supported by a mainline kernel. Neither Linux nor any other of the *BSDs. They simply do not care what software runs on it. https://community.ipfire.org/t/arm-sbc-support-discussion/2650 https://community.ipfire.org/t/arm-sbc-support-discussion/26... Post number 4 Earlier discussion https://news.ycombinator.com/item?id=30504615 https://news.ycombinator.com/item?id=30504615
- zozbot234 5y ago
  > Over many years, there has never been a release of that piece of hardware that was supported by a mainline kernel. Neither Linux nor any other of the *BSDs. I think the stuff does get mainline support over time, though? That's no different from what goes on in x86 land, where installing Linux on cutting edge hardware is always painful in some ways and some stuff can even take years to get properly supported. (I'm especially thinking of Intel's mobile platforms from quite a few years back.)
- 542458 5y ago
  The tax complaints don’t really hold water to me. A competitor could spin up a nonprofit if they wanted or pivot to nonprofit status. But they don’t, because the opportunity costs and limitations of being a nonprofit are nontrivial. There are successful competitors, both for and non profit - BBC Micro, Orange Pi, BeagleBone, etc. And re: OSS, I don’t remember anybody complaining that Lenovo (for example) “outsources” their Linux thinkpad OS. The raspberry pi foundation is using open source (and some vendor closed source) software in full compliance with its licenses. The post you linked complains that the code quality of the raspberry pi modifications is “bad” and can’t be integrated into mainline Linux, but that doesn’t make it not open source. “Open source” has no obligation to be high code quality.
MarcScott 5y ago
So many comments about Raspberry Pi Foundation being a charity here, and therefore... Let's just be clear, it is a charity and owns Raspberry Pi Limited. The profits from RPL help fund the charitable work done by RPF. It's like complaining that the Bill and Melinda Gates Foundation was funded from profits from Microsoft, and therefore Windows should be FOSS software.
- nocman 5y ago
  > It's like complaining that the Bill and Melinda Gates Foundation was funded from profits from Microsoft, and therefore Windows should be FOSS software. Except that no one confuses Microsoft with the Bill and Melinda Gates Foundation. I'm sure that a lot of people are either unaware of the existence of Raspberry Pi Limited, or don't know the distinction between it and the Raspberry Pi Foundation. I'm not saying Raspberry Pi Limited should not exist, or should not sell hardware. I'm just saying that it is understandable that some would be unaware of and perhaps surprised its existence and the distinction between it and the Foundation.
blippage 5y ago
One things I'd like to see come out of RISC-V is a kind of microcontroller/microprocessor hybrid. Hobbyists are doing amazing things with the RP2040 PIO system (I haven't been able to wrap my head around it personally), including HDMI/VGA output and ethernet control. All out of a tiny microcontroller, and by (above-) average Joes in the street. What this proves is that you don't need expensive secret IP to get the job done. You may not do it spectacularly, but you can can do it. Now imagine a gussy-upped system like this; a system that approaches being a microprocessor, probably not as powerful, that has something like PIO where some of them are dedicated to specific hardware. You could maybe store the drivers in a ROM, if you like. So you'd have some kind of BIOS system. Want to produce a tone? Just push a value into a register. Write directly to the display buffer. No OS required, although a DOS equivalent would be nice. Not necessarily Linux, though. Voila, you'd have some kind of real-time system that needs no OS unless you wanted it. The system would be very easy to understand, and a great educational tool. It would also be a Maker's dream. An 80's system bought into the 21st century. No binary blobs or any of that nonsense. You'll know you've done it right when Doom has been ported to it (no joke intended). I don't care if it doesn't run Firefox or if the graphics system seems a bit dated. Don't try to out-compete Intel, see what you can do to carve out a niche. Just my 2c.

346 points by JNRowe 5y ago

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.

bennyp101 5y ago

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"?
    - 5y ago

inherently 5y ago

the only problem mentioned was video stuff. does this mean that for a headless server use case it's usable?

fsflover 5y ago
No: https://news.ycombinator.com/item?id=31000966 https://news.ycombinator.com/item?id=31000966.
- yjftsjthsd-h 5y ago
  Yes: https://github.com/librerpi/lk-overlay#what-features-work https://github.com/librerpi/lk-overlay#what-features-work (Albeit, currently only on a Pi 2) 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.
  - cleverca22 5y ago
    lk-overlay contains many different projects using the vc4-stage1, vc4-stage2, and rpi2-test projects together, you can do the entire boot chain (dram init and loading linux) using open source code other projects act as demo's or tests on how to run custom code at various stages, but not actually boot linux on the arm core many of those demos work on the the entire pi model range pi3 support is only broken due to arm side problems, which could be fixed by just using a different bootloader and the https://github.com/librerpi/rpi-open-firmware https://github.com/librerpi/rpi-open-firmware codebase can already boot linux headlessly on both pi2 and pi3, it uses a different arm bootloader

bri3d 5y ago

Another interesting part of the Raspberry Pi VideoCore blob is that it implements DRM for Raspberry Pi products: the Pi Camera V2 has an Atmel ATSHA204A CryptoAuthentication chip on it and uses an HMAC+nonce challenge/response system to authenticate with the VideoCore blob when it goes to bring up the CSI interface. Marcan42 dumped the keys from the VideoCore blob and documented the system a few years ago. According to the Pi Foundation, this is because simple peripherals are too easy to clone and they need to recoup their investment in accessory design. I was reminded of this while I was researching Twitter speculation yesterday that something similar is done for the DSI interface for displays. I wasn't able to substantiate this - the FKMS (FakeKMS/FirmwareKMS) and proprietary Raspberry Pi video drivers, where link negotiation and backlight control is done in the blob, do only support specific displays. However, it's unclear to me if this is due to driver support or an intentional lock-in. The open-source KMS driver (not yet usable on Raspberry Pi 4) where link negotiation and backlight control is done in the kernel, of course supports anything with a driver.

ChuckNorris89 5y ago
>According to the Pi Foundation, this is because simple peripherals are too easy to clone and they need to recoup their investment in accessory design. I find this completely fair, but then maybe don't call yourself a "charity" and an "open platform" and just be upfront that you need to lock down your hardware to recoup the investment.
- sokoloff 5y ago
  I don’t object to the use of “charity” nearly so much as “open platform” in this case. A charity that gives away some things but not other things is still a charity. A platform that is partially closed is not fully open.
  - deleted 5y ago
    [deleted]
  - nmstoker 5y ago
    They've always been pretty clear about which parts that simply couldn't open up, due to restrictions beyond their control.

cf141q5325 5y ago

Shout out again to the interesting perspective on the topic from the IpFire Forum. Some excerpts: >Now, everybody is looking for a cheap ARM board with performance and loads of features. The Raspberry Foundation is a charity that pays probably no tax at all, but somehow is selling lots and lots of boards at an absolutely “amazing” price. >Amazing because nobody else in Europe can compete with them. Paying no taxes helps. The second step is that they have almost completely outsourced their software development. They call it Open Source-ed, but that is not the same. >Over many years, there has never been a release of that piece of hardware that was supported by a mainline kernel. Neither Linux nor any other of the *BSDs. They simply do not care what software runs on it. https://community.ipfire.org/t/arm-sbc-support-discussion/2650 https://community.ipfire.org/t/arm-sbc-support-discussion/26... Post number 4 Earlier discussion https://news.ycombinator.com/item?id=30504615 https://news.ycombinator.com/item?id=30504615

zozbot234 5y ago
> Over many years, there has never been a release of that piece of hardware that was supported by a mainline kernel. Neither Linux nor any other of the *BSDs. I think the stuff does get mainline support over time, though? That's no different from what goes on in x86 land, where installing Linux on cutting edge hardware is always painful in some ways and some stuff can even take years to get properly supported. (I'm especially thinking of Intel's mobile platforms from quite a few years back.)
542458 5y ago
The tax complaints don’t really hold water to me. A competitor could spin up a nonprofit if they wanted or pivot to nonprofit status. But they don’t, because the opportunity costs and limitations of being a nonprofit are nontrivial. There are successful competitors, both for and non profit - BBC Micro, Orange Pi, BeagleBone, etc. And re: OSS, I don’t remember anybody complaining that Lenovo (for example) “outsources” their Linux thinkpad OS. The raspberry pi foundation is using open source (and some vendor closed source) software in full compliance with its licenses. The post you linked complains that the code quality of the raspberry pi modifications is “bad” and can’t be integrated into mainline Linux, but that doesn’t make it not open source. “Open source” has no obligation to be high code quality.

MarcScott 5y ago

So many comments about Raspberry Pi Foundation being a charity here, and therefore... Let's just be clear, it is a charity and owns Raspberry Pi Limited. The profits from RPL help fund the charitable work done by RPF. It's like complaining that the Bill and Melinda Gates Foundation was funded from profits from Microsoft, and therefore Windows should be FOSS software.

nocman 5y ago
> It's like complaining that the Bill and Melinda Gates Foundation was funded from profits from Microsoft, and therefore Windows should be FOSS software. Except that no one confuses Microsoft with the Bill and Melinda Gates Foundation. I'm sure that a lot of people are either unaware of the existence of Raspberry Pi Limited, or don't know the distinction between it and the Raspberry Pi Foundation. I'm not saying Raspberry Pi Limited should not exist, or should not sell hardware. I'm just saying that it is understandable that some would be unaware of and perhaps surprised its existence and the distinction between it and the Foundation.

blippage 5y ago

One things I'd like to see come out of RISC-V is a kind of microcontroller/microprocessor hybrid. Hobbyists are doing amazing things with the RP2040 PIO system (I haven't been able to wrap my head around it personally), including HDMI/VGA output and ethernet control. All out of a tiny microcontroller, and by (above-) average Joes in the street. What this proves is that you don't need expensive secret IP to get the job done. You may not do it spectacularly, but you can can do it. Now imagine a gussy-upped system like this; a system that approaches being a microprocessor, probably not as powerful, that has something like PIO where some of them are dedicated to specific hardware. You could maybe store the drivers in a ROM, if you like. So you'd have some kind of BIOS system. Want to produce a tone? Just push a value into a register. Write directly to the display buffer. No OS required, although a DOS equivalent would be nice. Not necessarily Linux, though. Voila, you'd have some kind of real-time system that needs no OS unless you wanted it. The system would be very easy to understand, and a great educational tool. It would also be a Maker's dream. An 80's system bought into the 21st century. No binary blobs or any of that nonsense. You'll know you've done it right when Doom has been ported to it (no joke intended). I don't care if it doesn't run Firefox or if the graphics system seems a bit dated. Don't try to out-compete Intel, see what you can do to carve out a niche. Just my 2c.