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).
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.
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.
> 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.
> 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.
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
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.
> 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.
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 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 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.
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.
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.
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.
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’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.
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.
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.
84 comments
[ 4.8 ms ] story [ 139 ms ] threadIs 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.
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.
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.)
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.
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).
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.
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.
Nope, not all is upstreamed, IIRC camera gave me grief, I just installed rasbpian after
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.
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/
https://ubuntu.com/raspberry-pi
[0]https://github.com/T-head-Semi/openc910
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.
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
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.
And Device Tree makes me miss ISA bus and setting jumpers to right IRQ...
So this isn't the same RISC-V CPU as from VisionFive2 and Pine64. It's an Alibaba core I believe[0].
Hopefully this doesn't cause worse fragmentation and slow much needed software and distro support.
My worries previously on HN[1].
[0] https://www.cnx-software.com/2022/10/04/alibaba-t-head-th152...
[1] https://news.ycombinator.com/item?id=34105528#34106450
This interview is now years-old and is now 100% false, as today we have several competitive-to-Cortex-A7 boards available and ready to ship right now.
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.
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.
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.
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.
"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.
Eben Upton's RISC-V knowledge is dated. Both this cpu core and the one in VisionFive2 are quite competitive with A72.
It's becoming very common for people to use these devices as routers, so it makes sense to have two ports - one for wan and the other for lan.
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.
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.
Any more detail on what is being done here? I don’t need to bypass the gfw, just curious
[1]: https://en.wikipedia.org/wiki/Trusted_execution_environment
https://riscv.org/blog/2021/09/risc-v-cryptography-extension...
BTW can the people who downvote me at least give me a reason why am I wrong? Would gladly hear it.
Will be interesting to see.
[1]: https://www.cnx-software.com/2022/10/04/alibaba-t-head-th152...
[2]: https://developer.arm.com/Processors/SecurCore%20SC300
[3]: https://www.st.com/en/secure-mcus/st33j1m5.html
[1] Sipeed LM4A – T-Head TH1520 RISC-V module to power Raspberry Pi 4 competitor and cluster board:
https://www.cnx-software.com/2022/12/14/sipeed-lm4a-t-head-t...
Does not work for me either.
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.
That's impressive in a dev board.
Just like you wouldn't use a full-fledged Raspberry Pi for use cases where a Raspberry Pi Nano or other low-power microcontroller is enough.