9 ms·

No matter any given SBC's hardware platform's apparent attractiveness: Give me mainline Linux support for all included devices/features, or give me (this partic

by c0l0 4y ago

No matter any given SBC's hardware platform's apparent attractiveness: Give me mainline Linux support for all included devices/features, or give me (this particular product's eventual) death. Is there any info on how this make and model fares? The spec sheet speaks of "Debian / OpenWRT / Andriod" (sic!), but two misspellings in three names don't exactly inspire confidence... If I can only ever hope to install some manufacturer-bastardized spin of Ubuntu 14.04 with a heap of custom patches on top, I'll have to forever stick to Raspberry Pis instead, unfortunately.

ilyt 4y ago
Even rPIs don't pass your "mainline" criteria, Raspbian ships with patched kernel and I remember just few months ago having to use it just so stuff like camera works, while on mainline the video stream was giving me, uh, random pieces of working memory... And Device Tree makes me miss ISA bus and setting jumpers to right IRQ...
doubled112 4y ago
I’ll admit I was sticking to Pis because of the community and support, but is mainline support on the Raspberry Pi looking better these days? The Pi4 has been out a while now, and Fedora just added “support” Its in quotes because theres no WiFi, no Bluetooth, and I cannot get it to boot to desktop using their image. Arch Linux ARM has been pushing images that don’t boot on the 400 for over a year now, but if I install the Raspberry Pi kernel in a chroot before first boot it even works. What I’ve found is that if you want it to work you’re stuck on Raspberry Pi OS, a bastardized Debian distro, anyway. Is your experience different? There was a time there was choice and they just worked. Somehow it feels as though it has gone backward and I’m tinkering with some no-name made in China SBC again.
- squarefoot 4y ago
  > What I’ve found is that if you want it to work you’re stuck on Raspberry Pi OS, a bastardized Debian distro, anyway. Ambian, Dietpi, and Alpine all support it, along with many other boards that are not just easier to find these days but also cheaper and sometimes more powerful than the Raspberry Pi. https://www.armbian.com/download/?device_support=Supported https://www.armbian.com/download/?device_support=Supported https://dietpi.com/#downloadinfo https://dietpi.com/#downloadinfo https://alpinelinux.org/downloads/ https://alpinelinux.org/downloads/
- ilyt 4y ago
  Debian Stable ran network/bt/wifi on rPi4, but camera was broken, haven't tried much beyond that.
- swinglock 4y ago
  There's Ubuntu support as well. https://ubuntu.com/raspberry-pi https://ubuntu.com/raspberry-pi
- c0l0 4y ago
  Regarding mainline: No, not really - but I think we're in for a decent future with much-expanded mainline support. The difference between the bastardized stuff from the Pi Foundation and everyone else's is that the former has enough momentum behind it that it's safe to assume it doesn't simply wither away, which makes enough difference for me not to experiment with others that almost certainly will. (I have a small drawer full of SBCs without any remaining software support at home from a past where I did not live/buy by that standard.)
  - rfoo 4y ago
    > the former has enough momentum behind it that it's safe to assume it doesn't simply wither away Given that: - The underlying SoC since RPi 3B (released six years ago) all supports AArch64. - The Pi foundation refused to ship an AArch64 Raspbian image until early this year. - The reason being "armv7 works on every RPi, aarch64 not, we don't have enough resource to maintain two archs". I doubt it has enough momentum.
    - geerlingguy 4y ago
      The Pi Foundation had a 'beta' ARM64 image build since 2020, they finally decided to highlight it on their download pages and installer this year after working through a number of compatibility bugs (none of which I ever ran into, but some would).
- fest 4y ago
  Well, at least with Raspberry Pi, if there is a particular hardware feature, there is at least support for it from Raspbian/RPi foundation. With many SBCs you're on your own if you need something besides "kernel boots, video output works" (e.g video encoding, MIPI input, GPU are often neglected on many SBCs with less momentum behind them).
  - geerlingguy 4y ago
    If only it were that generous... for many boards (especially ones that include newer RockChip SoCs, getting video output would be a wonderful innovation.
- sigjuice 4y ago
  Wifi does work on the Pi 4 with Fedora 37. I tried that just a few hours ago.
- public_defender 4y ago
  Correct me if I'm wrong, but this seems to confuse hardware support (e.g. drivers) for "working out of the box" with a particular distro. I have a CM4. It worked out of the box with RPi OS, but needed some hacking to get working with Alpine. The important thing is that it was possible to pull some configs from RPi OS to set up wifi on Alpine. The drivers were all in both kernels, so I assume they were in upstream, but had no reason to check. I think the point of GP is that some hardware on these SBCs has no open source drivers and you can't get them, which is way different. Also, again maybe I don't understand something, but the RPi OS is not "bastardized" in any special way. The whole point of the Linux ecosystem is that you bastardize things. It's actually good that there is a distro customized for RPi and that it submits some changes upstream but not all, right? I think GP was saying that they didn't want to depend on some weird hacks the manufacturer did to get closed hardware to work, which again is different.
  - ilyt 4y ago
    > The drivers were all in both kernels, so I assume they were in upstream, but had no reason to check. Nope, not all is upstreamed, IIRC camera gave me grief, I just installed rasbpian after
  - rwmj 4y ago
    Fedora ships only upstream kernels, so working out of the box with Fedora is the same as being in the mainline (Linus) kernel.
    - public_defender 4y ago
      > working out of the box with Fedora is the same as being in the mainline (Linus) kernel. That's not right. For example, in my case with wifi the microcode was named incorrectly and one of the other configs needed to be updated, but the drivers were there. Nobody has said what the problem is/is not in Fedora.
      - rwmj 4y ago
        Unless Fedora renamed the microcode blob that's likely to be an upstream problem too.
- jaredhallen 4y ago
  > What I’ve found is that if you want it to work you’re stuck on Raspberry Pi OS, a bastardized Debian distro, anyway. I've been running Ubuntu on my 3b for a few years now. The original image was 20.04, and I recently upgraded to 22.04 using do-release-upgrade without any grief. It has worked pretty painlessly for me.
  - archontes 4y ago
    I'm running ubuntu server on my 3b as well, and other than some initial networking finagling, it's been painless.
Vt71fcAqt7 4y ago
Is there any reason to think this won't be mainlined? The core is even open[0] so I can't think of a reason they wouldn't try to upstream it. [0]https://github.com/T-head-Semi/openc910 https://github.com/T-head-Semi/openc910
- akvadrako 4y ago
  Because it's very rare to have these random SBCs suppored by mainline Linux.
captainmuon 4y ago
A thousand times this. I'm tired of having to reverse engineer the hardware I bought because the SoC vendor sits on their manuals and datasheets like a dragon on a pile of gold. Even if you are making your own SBCs and offering to write the drivers you run against walls. Apparently many embedded vendors don't want their stuff to be used or to work properly.
- amelius 4y ago
  > Apparently many embedded vendors don't want their stuff to be used or to work properly. Can someone please organize an AMA for each of these vendors' product managers? I have the feeling they live in a different world and it could result in interesting discussions.
  - ilyt 4y ago
    From what I've gathered it's the clowns in suits thinking that putting drivers in kernel instead of behind NDA is some kind of "competitive advantage". Other reason is that kernel requires some minimal level of code quality and many of the closed source ones are basically "the minimum to make the customer use case work" Yet another reason is just not wanting to bother with more than bare minimum for chip that will be in market few years and replaced with something newer
    - swinglock 4y ago
      Ironically this seemingly widespread issue makes the opposite even more true. That is, working correctly with Linux without patches would be a differentiator and a competitive advantage.
    - fexecve 4y ago
      > Other reason is that kernel requires some minimal level of code quality and many of the closed source ones are basically "the minimum to make the customer use case work" I think this is the real, actual reason. Having worked in embedded for a long time, the coding horrors are endless and routine. There's no way 99.99% of embedded software would ever pass the kernel's strict code quality standards. It's easier to just ship a "bastardized" (as others here are calling it) patched kernel.
sam_uk 4y ago
Or Yocto https://gitee.com/thead-yocto/documents https://gitee.com/thead-yocto/documents

by c0l0 4y ago

ilyt 4y ago

Even rPIs don't pass your "mainline" criteria, Raspbian ships with patched kernel and I remember just few months ago having to use it just so stuff like camera works, while on mainline the video stream was giving me, uh, random pieces of working memory... And Device Tree makes me miss ISA bus and setting jumpers to right IRQ...

doubled112 4y ago

I’ll admit I was sticking to Pis because of the community and support, but is mainline support on the Raspberry Pi looking better these days? The Pi4 has been out a while now, and Fedora just added “support” Its in quotes because theres no WiFi, no Bluetooth, and I cannot get it to boot to desktop using their image. Arch Linux ARM has been pushing images that don’t boot on the 400 for over a year now, but if I install the Raspberry Pi kernel in a chroot before first boot it even works. What I’ve found is that if you want it to work you’re stuck on Raspberry Pi OS, a bastardized Debian distro, anyway. Is your experience different? There was a time there was choice and they just worked. Somehow it feels as though it has gone backward and I’m tinkering with some no-name made in China SBC again.

squarefoot 4y ago
> What I’ve found is that if you want it to work you’re stuck on Raspberry Pi OS, a bastardized Debian distro, anyway. Ambian, Dietpi, and Alpine all support it, along with many other boards that are not just easier to find these days but also cheaper and sometimes more powerful than the Raspberry Pi. https://www.armbian.com/download/?device_support=Supported https://www.armbian.com/download/?device_support=Supported https://dietpi.com/#downloadinfo https://dietpi.com/#downloadinfo https://alpinelinux.org/downloads/ https://alpinelinux.org/downloads/
ilyt 4y ago
Debian Stable ran network/bt/wifi on rPi4, but camera was broken, haven't tried much beyond that.
swinglock 4y ago
There's Ubuntu support as well. https://ubuntu.com/raspberry-pi https://ubuntu.com/raspberry-pi
c0l0 4y ago
Regarding mainline: No, not really - but I think we're in for a decent future with much-expanded mainline support. The difference between the bastardized stuff from the Pi Foundation and everyone else's is that the former has enough momentum behind it that it's safe to assume it doesn't simply wither away, which makes enough difference for me not to experiment with others that almost certainly will. (I have a small drawer full of SBCs without any remaining software support at home from a past where I did not live/buy by that standard.)
- rfoo 4y ago
  > the former has enough momentum behind it that it's safe to assume it doesn't simply wither away Given that: - The underlying SoC since RPi 3B (released six years ago) all supports AArch64. - The Pi foundation refused to ship an AArch64 Raspbian image until early this year. - The reason being "armv7 works on every RPi, aarch64 not, we don't have enough resource to maintain two archs". I doubt it has enough momentum.
  - geerlingguy 4y ago
    The Pi Foundation had a 'beta' ARM64 image build since 2020, they finally decided to highlight it on their download pages and installer this year after working through a number of compatibility bugs (none of which I ever ran into, but some would).
fest 4y ago
Well, at least with Raspberry Pi, if there is a particular hardware feature, there is at least support for it from Raspbian/RPi foundation. With many SBCs you're on your own if you need something besides "kernel boots, video output works" (e.g video encoding, MIPI input, GPU are often neglected on many SBCs with less momentum behind them).
- geerlingguy 4y ago
  If only it were that generous... for many boards (especially ones that include newer RockChip SoCs, getting video output would be a wonderful innovation.
sigjuice 4y ago
Wifi does work on the Pi 4 with Fedora 37. I tried that just a few hours ago.
public_defender 4y ago
Correct me if I'm wrong, but this seems to confuse hardware support (e.g. drivers) for "working out of the box" with a particular distro. I have a CM4. It worked out of the box with RPi OS, but needed some hacking to get working with Alpine. The important thing is that it was possible to pull some configs from RPi OS to set up wifi on Alpine. The drivers were all in both kernels, so I assume they were in upstream, but had no reason to check. I think the point of GP is that some hardware on these SBCs has no open source drivers and you can't get them, which is way different. Also, again maybe I don't understand something, but the RPi OS is not "bastardized" in any special way. The whole point of the Linux ecosystem is that you bastardize things. It's actually good that there is a distro customized for RPi and that it submits some changes upstream but not all, right? I think GP was saying that they didn't want to depend on some weird hacks the manufacturer did to get closed hardware to work, which again is different.
- ilyt 4y ago
  > The drivers were all in both kernels, so I assume they were in upstream, but had no reason to check. Nope, not all is upstreamed, IIRC camera gave me grief, I just installed rasbpian after
- rwmj 4y ago
  Fedora ships only upstream kernels, so working out of the box with Fedora is the same as being in the mainline (Linus) kernel.
  - public_defender 4y ago
    > working out of the box with Fedora is the same as being in the mainline (Linus) kernel. That's not right. For example, in my case with wifi the microcode was named incorrectly and one of the other configs needed to be updated, but the drivers were there. Nobody has said what the problem is/is not in Fedora.
    - rwmj 4y ago
      Unless Fedora renamed the microcode blob that's likely to be an upstream problem too.
jaredhallen 4y ago
> What I’ve found is that if you want it to work you’re stuck on Raspberry Pi OS, a bastardized Debian distro, anyway. I've been running Ubuntu on my 3b for a few years now. The original image was 20.04, and I recently upgraded to 22.04 using do-release-upgrade without any grief. It has worked pretty painlessly for me.
- archontes 4y ago
  I'm running ubuntu server on my 3b as well, and other than some initial networking finagling, it's been painless.

Vt71fcAqt7 4y ago

Is there any reason to think this won't be mainlined? The core is even open[0] so I can't think of a reason they wouldn't try to upstream it. [0]https://github.com/T-head-Semi/openc910 https://github.com/T-head-Semi/openc910

akvadrako 4y ago
Because it's very rare to have these random SBCs suppored by mainline Linux.

captainmuon 4y ago

A thousand times this. I'm tired of having to reverse engineer the hardware I bought because the SoC vendor sits on their manuals and datasheets like a dragon on a pile of gold. Even if you are making your own SBCs and offering to write the drivers you run against walls. Apparently many embedded vendors don't want their stuff to be used or to work properly.

amelius 4y ago
> Apparently many embedded vendors don't want their stuff to be used or to work properly. Can someone please organize an AMA for each of these vendors' product managers? I have the feeling they live in a different world and it could result in interesting discussions.
- ilyt 4y ago
  From what I've gathered it's the clowns in suits thinking that putting drivers in kernel instead of behind NDA is some kind of "competitive advantage". Other reason is that kernel requires some minimal level of code quality and many of the closed source ones are basically "the minimum to make the customer use case work" Yet another reason is just not wanting to bother with more than bare minimum for chip that will be in market few years and replaced with something newer
  - swinglock 4y ago
    Ironically this seemingly widespread issue makes the opposite even more true. That is, working correctly with Linux without patches would be a differentiator and a competitive advantage.
  - fexecve 4y ago
    > Other reason is that kernel requires some minimal level of code quality and many of the closed source ones are basically "the minimum to make the customer use case work" I think this is the real, actual reason. Having worked in embedded for a long time, the coding horrors are endless and routine. There's no way 99.99% of embedded software would ever pass the kernel's strict code quality standards. It's easier to just ship a "bastardized" (as others here are calling it) patched kernel.

sam_uk 4y ago

Or Yocto https://gitee.com/thead-yocto/documents https://gitee.com/thead-yocto/documents