5 ms·

As someone that has actually shipped RPi-like boards and clones, I'll tell you that it's just part of the job description. They ALL suck, some just suck less t

As someone that has actually shipped RPi-like boards and clones, I'll tell you that it's just part of the job description. They ALL suck, some just suck less than others. Broadcom, Renesas? The worst. ST, NXP, TI? Slightly better than fully sucking. Look to the chipmaker (ST, NXP) and not the board maker (Orange) for a guide in how well things go.

colechristensen 3y ago
But the RPi is broadcom and arguably the best supported. Obviously this is special. From experience I agree with you, the chipmakers suck because they utterly fail to be open source when they're one of the groups that needs it the most. It is to the extent that I would advocate for laws in the theme of right-to-repair to force chip vendors to provide source for necessary code to use their products to consumers. (in this case open source in the narrowest definition, they can keep their copyrights but would be required to distribute source to end users in a form and with a license that makes them usable) If the question is "are any of the SBCs worth the trouble?" and the default answer is no unless I have a really good reason and want to dedicate the time to building the janky software stack (I don't), or they're from a small list of vendors I'd trust won't be a mess (RPi, nvidia, beagle, ... that's it off the top of my head)
- joezydeco 3y ago
  Were the kernel and BSP improvements and ongoing support for RPi produced by Broadcom, or by the user community?
  - colechristensen 3y ago
    There is some sort of close relationship between Broadcom and the raspberry pi foundation which is not entirely clear, they are a bit more than just customers although companies use the “partnership” label to mean just about anything.
    - joezydeco 3y ago
      The relationship is very clear: Upton was a Broadcom FAE that started the RPi Foundation. The secondary story was that he found a use for an orphaned SoC and embarked on an 'educational' quest to make small computers for classrooms. The real question is if Broadcom is devoting internal software resources to improving the ecosystem, or if it's coming from the devoted users. I don't track commits on kernel.org enough to know what's what.
tmchu 3y ago
Please excuse my ignorance here, but are you saying that the board makers have no say on what chip they want to incorporate into their board? And those chips firmware are not open or at least accessible to the board makers?
- joezydeco 3y ago
  What I'm saying is treat the board as a development harness to get your project going. If you have issues with the processor don't take it up with the board maker because they're usually just as clueless. The exception would be boards like RPi or Beagle where the designers are tight with or owned by the chipmakers themselves.
  - jvanderbot 3y ago
    Right, which is what GP was saying: stick to those that are able to support longer than zero time horizon.
    - joezydeco 3y ago
      But the fundamental difference here is that most people buying SBCs are treating them as self-contained COTS compute modules. As someone that has worked with these EVKs for decades, you never treated them as part of your final product. But with the advent of Beagle and RPI, that's where we are now. But when you buy an RPi or Beaglebone as the core of your industrial smelter and expect support for that module comparable to, say, a module from Kontron? You're going to be disappointed.
      - jvanderbot 3y ago
        Support is the S in IOT.
        HeyLaughingBoy 3y ago
        I thought that.... oh, Security is the other S. Got it!
meltedcapacitor 3y ago
Are these vendor kernels good enough to run some sort of hypervisor and pass through devices at the lowest possible level to (updatable) guest kernel(s)? The idea here would be to run things like the TCP stack, USB from the lowest proxy-able level the in USB stack, etc in the guest kernel(s), as well as the entire application level, so as to reduce exposure to vendor kernel bugs and feature freeze leaving it only with minimal SOC-specific nitty gritty. For GPIO the vendor kernel could be used as a PRU of sort, passing messages to the guest kernel for actual processing. Then the vendor kernel is just treated as a BIOS/blob getting in the way as little as practicable, it's very ugly but would allow using all these boards, also same method could possibly be used to recycle obsolete android phones.

colechristensen 3y ago

But the RPi is broadcom and arguably the best supported. Obviously this is special. From experience I agree with you, the chipmakers suck because they utterly fail to be open source when they're one of the groups that needs it the most. It is to the extent that I would advocate for laws in the theme of right-to-repair to force chip vendors to provide source for necessary code to use their products to consumers. (in this case open source in the narrowest definition, they can keep their copyrights but would be required to distribute source to end users in a form and with a license that makes them usable) If the question is "are any of the SBCs worth the trouble?" and the default answer is no unless I have a really good reason and want to dedicate the time to building the janky software stack (I don't), or they're from a small list of vendors I'd trust won't be a mess (RPi, nvidia, beagle, ... that's it off the top of my head)

joezydeco 3y ago
Were the kernel and BSP improvements and ongoing support for RPi produced by Broadcom, or by the user community?
- colechristensen 3y ago
  There is some sort of close relationship between Broadcom and the raspberry pi foundation which is not entirely clear, they are a bit more than just customers although companies use the “partnership” label to mean just about anything.
  - joezydeco 3y ago
    The relationship is very clear: Upton was a Broadcom FAE that started the RPi Foundation. The secondary story was that he found a use for an orphaned SoC and embarked on an 'educational' quest to make small computers for classrooms. The real question is if Broadcom is devoting internal software resources to improving the ecosystem, or if it's coming from the devoted users. I don't track commits on kernel.org enough to know what's what.

tmchu 3y ago

Please excuse my ignorance here, but are you saying that the board makers have no say on what chip they want to incorporate into their board? And those chips firmware are not open or at least accessible to the board makers?

joezydeco 3y ago
What I'm saying is treat the board as a development harness to get your project going. If you have issues with the processor don't take it up with the board maker because they're usually just as clueless. The exception would be boards like RPi or Beagle where the designers are tight with or owned by the chipmakers themselves.
- jvanderbot 3y ago
  Right, which is what GP was saying: stick to those that are able to support longer than zero time horizon.
  - joezydeco 3y ago
    But the fundamental difference here is that most people buying SBCs are treating them as self-contained COTS compute modules. As someone that has worked with these EVKs for decades, you never treated them as part of your final product. But with the advent of Beagle and RPI, that's where we are now. But when you buy an RPi or Beaglebone as the core of your industrial smelter and expect support for that module comparable to, say, a module from Kontron? You're going to be disappointed.
    - jvanderbot 3y ago
      Support is the S in IOT.
      - HeyLaughingBoy 3y ago
        I thought that.... oh, Security is the other S. Got it!

meltedcapacitor 3y ago

Are these vendor kernels good enough to run some sort of hypervisor and pass through devices at the lowest possible level to (updatable) guest kernel(s)? The idea here would be to run things like the TCP stack, USB from the lowest proxy-able level the in USB stack, etc in the guest kernel(s), as well as the entire application level, so as to reduce exposure to vendor kernel bugs and feature freeze leaving it only with minimal SOC-specific nitty gritty. For GPIO the vendor kernel could be used as a PRU of sort, passing messages to the guest kernel for actual processing. Then the vendor kernel is just treated as a BIOS/blob getting in the way as little as practicable, it's very ugly but would allow using all these boards, also same method could possibly be used to recycle obsolete android phones.