Hacker News Reader

Comment by c0l0 | Hacker News Reader

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.

View on HN

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.

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.)

> 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.

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).

> 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://dietpi.com/#downloadinfo

https://alpinelinux.org/downloads/

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.

> 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

Fedora ships only upstream kernels, so working out of the box with Fedora is the same as being in the mainline (Linus) kernel.

> 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.

Unless Fedora renamed the microcode blob that's likely to be an upstream problem too.

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).

If only it were that generous... for many boards (especially ones that include newer RockChip SoCs, getting video output would be a wonderful innovation.

> 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.

I'm running ubuntu server on my 3b as well, and other than some initial networking finagling, it's been painless.

Wifi does work on the Pi 4 with Fedora 37. I tried that just a few hours ago.

There's Ubuntu support as well.

https://ubuntu.com/raspberry-pi

Debian Stable ran network/bt/wifi on rPi4, but camera was broken, haven't tried much beyond that.

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.

> 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.

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

> 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.

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.

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

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...

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

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

Reply on news.ycombinator.com