3 ms·

IMO, it comes down to the support and ecosystem. Even though it would be nice to have something more open than Broadcom's chips, the corporate/foundation backin

IMO, it comes down to the support and ecosystem. Even though it would be nice to have something more open than Broadcom's chips, the corporate/foundation backing of the project, and the broad adoption after those first few revisions (coupled with the fact that Pis are still some of the cheapest options around) means that someone can come into the ecosystem blind and not have to spend hours or days just figuring out how to get an OS running on the darn thing. And then the fact that you can still run a supported modern OS on an almost 10 year old board... that doesn't seem to happen with other SBCs (most are basically shelved after a couple years), and you end up running ancient OSes on them or obscure community-driven OSes that break in a hundred different ways.

megous 5y ago
There are a lot of boards that have mainline u-boot/Linux support, don't need neither any wonky 4MiB binary firmware which does who knows what, nor any vendor specific tools to control basic things like HDMI, or CPU frequency, and just work for years with any arm based distro. Personally I think it's just a better marketing.
- floatboth 5y ago
  You don't need vendor specific tools. Especially not on the pi 4 but even before that. The RPi foundation stayed on a 32 bit distro with the proprietary graphics stack forever due to some silly fear of breaking.. something (?) or whatever but mainline linux has been able to manage everything about graphics and display with the vc4 drm/kms driver for ages. CPU frequency has of course been controlled by a mainline kernel driver for ages – heck that's supported in all of the BSD OSes as well.
- michaelt 5y ago
  That wasn't my experience, pre-raspberry-pi. There were projects, sure - but they rarely sold in large volumes. That meant not many paid developers. And if you had a problem you'd be lucky if someone online had even experienced the same problem, let alone found a fix for it. Every chip vendor seemed to have their own kernel fork with their own patches, and didn't much care to get them upstreamed. And of course, their kernel would be ancient - they're selling it for things like automotive infotainment systems which don't give a shit about security. Want to attach, say, a battery-backed RTC to your SBC? I hope you know the difference between a dtc and a dtbi. And even if someone else has been nice enough to get the same part working on their SBC, just because a TI processor needs the line 'dmas = < 0x21 0x1c 0x00 0x21 0x1d 0x00 >;' doesn't mean you can copy that to a Freescale processor and expect it to work. More than once I brought SBCs that came with a connector for a MIPI camera - but no camera available, and no software either. You want a camera? Plug in a USB webcam. And let's be honest: If you want features like wifi and hardware h264 support you're going to be dealing with wonky binary firmware anyway.
  - megous 5y ago
    I'm writing about '2-years-post-raspberry-pi' period when a plenty of "clones" started popping up. I say clones in quotes because they mostly shared just a form factor and started innovating pretty quickly with both form factor and features.
- forty 5y ago
  You can boot your rpi to mainline uboot (it does not remove the wonky firmware though :) ) I feel wonky firmwares are pretty common in the arm world though (and in other worlds too)

megous 5y ago

There are a lot of boards that have mainline u-boot/Linux support, don't need neither any wonky 4MiB binary firmware which does who knows what, nor any vendor specific tools to control basic things like HDMI, or CPU frequency, and just work for years with any arm based distro. Personally I think it's just a better marketing.

floatboth 5y ago
You don't need vendor specific tools. Especially not on the pi 4 but even before that. The RPi foundation stayed on a 32 bit distro with the proprietary graphics stack forever due to some silly fear of breaking.. something (?) or whatever but mainline linux has been able to manage everything about graphics and display with the vc4 drm/kms driver for ages. CPU frequency has of course been controlled by a mainline kernel driver for ages – heck that's supported in all of the BSD OSes as well.
michaelt 5y ago
That wasn't my experience, pre-raspberry-pi. There were projects, sure - but they rarely sold in large volumes. That meant not many paid developers. And if you had a problem you'd be lucky if someone online had even experienced the same problem, let alone found a fix for it. Every chip vendor seemed to have their own kernel fork with their own patches, and didn't much care to get them upstreamed. And of course, their kernel would be ancient - they're selling it for things like automotive infotainment systems which don't give a shit about security. Want to attach, say, a battery-backed RTC to your SBC? I hope you know the difference between a dtc and a dtbi. And even if someone else has been nice enough to get the same part working on their SBC, just because a TI processor needs the line 'dmas = < 0x21 0x1c 0x00 0x21 0x1d 0x00 >;' doesn't mean you can copy that to a Freescale processor and expect it to work. More than once I brought SBCs that came with a connector for a MIPI camera - but no camera available, and no software either. You want a camera? Plug in a USB webcam. And let's be honest: If you want features like wifi and hardware h264 support you're going to be dealing with wonky binary firmware anyway.
- megous 5y ago
  I'm writing about '2-years-post-raspberry-pi' period when a plenty of "clones" started popping up. I say clones in quotes because they mostly shared just a form factor and started innovating pretty quickly with both form factor and features.
forty 5y ago
You can boot your rpi to mainline uboot (it does not remove the wonky firmware though :) ) I feel wonky firmwares are pretty common in the arm world though (and in other worlds too)