4 ms·

Very cool - hope this becomes a template for other companies as to how to properly handle open sourcing the various important parts of the stack in the future.

Very cool - hope this becomes a template for other companies as to how to properly handle open sourcing the various important parts of the stack in the future. Seems like this is a very smart move by Broadcom - as demonstrated by the community response, which is mostly positive.

zanny 13y ago
Intel / AMD should be the template - actually hiring FOSS hackers to make you a proper driver for whole-stack support. It is nice that they released an older chips driver code, it is better than nothing (and better than just programming manuals) but we have companies like Qualcomm with the Atheros driver, Intel with their wifi, gpu, and ethernet drivers, and AMD with their chipsets, gpus, etc all contributing engineers in the kernel to make foss drivers, and we shouldn't give any company too much credit for doing any less than the same.
hrjet 13y ago
It is nice, but a little late for many people. Couple of years back when I was investigating the RaPi for building a video recorder, the lack of open video drivers prevented me (and apparently many in the forums) from integrating camera modules. I ended up using the TI boards, which have open source stacks since a long time now.
- beagle3 13y ago
  The RPi video core driver might not be fully open, but it has a usable camera API and video compression API. Which boards are those? I didn't find a single board that had an open video driver - not Allwinner based ones, not Beagle Bone Black (no encoding/decoding hardware at all).
  - hrjet 13y ago
    I am not familiar with Beagle Bone, but if it doesn't have encoding/decoding hardware, how did you expect a driver for it? The APIs in RPi that you mention are high-level APIs. Before Broadcom open-sourced the implementation (which they called IDL I think), it was not possible for RPI users to interface a custom camera module with RPi (without signing NDAs with Broadcom). After some investigation, I went with LeopardBoard. I haven't progressed far on the project [1], but AFAIK, it and other boards had completely open stacks. [1] I am stuck with a simple issue: Not able to get the right serial cable to connect to the board.
    - beagle3 13y ago
      I did not expect drivers for Beagle Bone, but I preemptively responded to "But BeagleBone is better" responses, which I've gotten every single time when discussing RasPi limitations. > it was not possible for RPI users to interface a custom camera module with RPi That's correct. But the RPi's camera modules (standard and noir) are very well supported (even if source is not all open), and they work very well - reasonable quality 5MP@15fps, FullHD@30FPS, 720p@60fps, with access to the encoding/decoding pipeline that allows you to e.g. insert an overlay before h264 encoding the original stream (in fact, that's the most cost effective way to add overlays to an already encoded 1080p h264 video even if you don't connect a camera). I find that it's pretty hard to beat RPi on price, support, functionality/price, community, openness etc. in general - to the point that if the RPi is not the right solution for a project, it is unlikely that any of its competitors (low power sub $100 cpu+gpu+network on a small form factor) is.
baldfat 13y ago
Quote "Very cool - hope this becomes a template for other companies as to how to properly handle open sourcing the various important parts of the stack in the future." I DON'T it was A) Not a driver (They should have made the driver and released it B) Use the actual chipset not one removed chipset and have people hack on it for money.

zanny 13y ago

Intel / AMD should be the template - actually hiring FOSS hackers to make you a proper driver for whole-stack support. It is nice that they released an older chips driver code, it is better than nothing (and better than just programming manuals) but we have companies like Qualcomm with the Atheros driver, Intel with their wifi, gpu, and ethernet drivers, and AMD with their chipsets, gpus, etc all contributing engineers in the kernel to make foss drivers, and we shouldn't give any company too much credit for doing any less than the same.

hrjet 13y ago

It is nice, but a little late for many people. Couple of years back when I was investigating the RaPi for building a video recorder, the lack of open video drivers prevented me (and apparently many in the forums) from integrating camera modules. I ended up using the TI boards, which have open source stacks since a long time now.

beagle3 13y ago
The RPi video core driver might not be fully open, but it has a usable camera API and video compression API. Which boards are those? I didn't find a single board that had an open video driver - not Allwinner based ones, not Beagle Bone Black (no encoding/decoding hardware at all).
- hrjet 13y ago
  I am not familiar with Beagle Bone, but if it doesn't have encoding/decoding hardware, how did you expect a driver for it? The APIs in RPi that you mention are high-level APIs. Before Broadcom open-sourced the implementation (which they called IDL I think), it was not possible for RPI users to interface a custom camera module with RPi (without signing NDAs with Broadcom). After some investigation, I went with LeopardBoard. I haven't progressed far on the project [1], but AFAIK, it and other boards had completely open stacks. [1] I am stuck with a simple issue: Not able to get the right serial cable to connect to the board.
  - beagle3 13y ago
    I did not expect drivers for Beagle Bone, but I preemptively responded to "But BeagleBone is better" responses, which I've gotten every single time when discussing RasPi limitations. > it was not possible for RPI users to interface a custom camera module with RPi That's correct. But the RPi's camera modules (standard and noir) are very well supported (even if source is not all open), and they work very well - reasonable quality 5MP@15fps, FullHD@30FPS, 720p@60fps, with access to the encoding/decoding pipeline that allows you to e.g. insert an overlay before h264 encoding the original stream (in fact, that's the most cost effective way to add overlays to an already encoded 1080p h264 video even if you don't connect a camera). I find that it's pretty hard to beat RPi on price, support, functionality/price, community, openness etc. in general - to the point that if the RPi is not the right solution for a project, it is unlikely that any of its competitors (low power sub $100 cpu+gpu+network on a small form factor) is.

baldfat 13y ago

Quote "Very cool - hope this becomes a template for other companies as to how to properly handle open sourcing the various important parts of the stack in the future." I DON'T it was A) Not a driver (They should have made the driver and released it B) Use the actual chipset not one removed chipset and have people hack on it for money.