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.
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 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.
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.
> 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.
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.
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.
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...
I don't know why anybody would ever get the LicheePi Nano instead of the 4A or the regular LicheePi, because these two boards' main selling point is that they're RISC-V which the Nano isn't.
I agree and wish they'd all support NVMe as well (with 2 or 4 free PCIe lanes, maybe to the exclusion of USB 3 ports). That would make them practical for all sorts of things.
I was just reading an interview with Eben Upton about RISC-Vs potential, and his response was that there aren’t any competitive-to-Cortex-A7 chips out there, and the OS support isn’t there. I guess we gotta start somewhere. Looking at the product page through, it seems like the designers are positioning this as a networking peripheral (at least with the expansion board)
There was another interview just last week on the Explaining Computers YouTube channel and he did mention RISC-V again. He said that as long as ARM licensing is not too restrictive and expensive, it is much easier and cheaper to integrate ARM cores into SoC designs as they are currently much more widely supported, and core to core are faster than same-year RISC-V core designs.
Remember that the A72 cores for the Pi 4 are like 7 years old now... the fastest available RISC-V cores are just catching up.
> fastest available RISC-V cores are just catching up.
Not entirely true, as SiFive has had the P550 and P650 for years, and now the P570 and P670. Those should be a lot faster and they're already available to anybody who wants to fill out an online form.
It's too early to say what will happen, really. That being said, nobody is predicting that RISC-V will dethrone Qualcomm or Apple in the next 5 years, but low-end processor adoption isn't always about price. If you're a Chinese manufacturer designing the knockoff 32-bit ARM chips that go into Joe Shmoe's microwave, RISC-V looks a lot more attractive than ARM in the long term.
In the end, my prediction is that it will rely entirely on compiler support and Linux packaging. Seeing as most of that RISC bootstrapping work was carved out by ARM, I'm hopeful that RISC-V will find its footing.
> it is much easier and cheaper to integrate ARM cores into SoC designs
I recall reading that the Pi Zero form factor (or maybe the Pi Zero 2?) was a special SOC package where they put the memory stacked on top of the rest of the chip, which made the form factor work.
I was mistaken. It's not the A7, It's the A72. This is the quote from Eben in Issue 83 (the winter 2022 issue) of Make:Magazine:
"The main things holding RISC-V back in the traditional Raspberry Pi/[Arm] Cortex-A market are a lack of available high-end licensable cores - I don't think I can go out and get anything that's competitive with the Cortex-A72 in Raspberry Pi 4, for example -- and a lack of software maturity in the Linux userland"
I suspect that the 'competitive metric' is a combination of price, performance and manufacturing availability.
"I don't think I can go out and get anything that's competitive with the Cortex-A72 in Raspberry Pi 4, for example -- and a lack of software maturity in the Linux userland"
Eben Upton's RISC-V knowledge is dated. Both this cpu core and the one in VisionFive2 are quite competitive with A72.
Sipeed is a pretty big designer, but with the West/China issues over chips, I wouldn't take a wager on getting your boards without issue.
You should also expect mid-level documentation if you do get them, it'll be Chinese-only support. This is why I stopped buying cheap Chinese electronics. It's great that you can get them for less, but then you spend 5x the time getting it to work properly.
OpenWRT-on-whatever-with-dual-eth-as-a-home-gateway gained a lot of popularity in China during the last two years. Besides the usual hobbyist use cases, it is particularly useful in China as people run VPN or those bizarre transparent proxies on them for getting around GFW. There are enough copy-paste ready tutorials that even "power users" are tempted to try doing so.
Sure, this sounds niche enough to be negligible, but SBCs are always niche products.
Currently the most popular "whatever" is $100 mini PCs, but <$40 SBCs have a significant price advantage.
I don't know the exact reason, but one probable guess is that ethernet has gotten so cheap that it costs next to nothing to add a second port, and you can market that second port as a feature.
If OpenWRT can be built for the board, it can make a tiny, silent gigabit router. Add on an M.2 slot and you could add on WiFi 6 or 6E, or a cellular modem, and do even more networking shenanigans.
It's one of the few use cases where—with the right NIC, which can offload some of the processing from the slower SoC—they can be fairly efficient and actually competitive with classic consumer routers like those from ASUS, Netgear, etc.
I’m pretty sure it is a different thing. I’ve looked into specs for C910 and E902 and couldn’t find any mention about encryption which is a very new thing on Risc-V. A router would have very lackluster VPN performance if it has to rely on raw CPU.
I see the ROMA laptop[1] will be using the same TH1520 processor, and there it says the laptop will have an ARM SC300[2] TEE. It could be a separate chip ala this[3], but given the block diagram on the Sipeed page is for the TH1520 SoC, surely it must be on-chip.
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.