Lichee Pi 4A | Hacker News Reader

Lichee Pi 4A

sipeed.com

112 pointssimjue81 comments

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

Oh well better get out the old credit card.

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

I also want to mention the Lichee Pi Nano, though it is much smaller and targeting a different use case: https://www.cnx-software.com/2018/08/17/licheepi-nano-cheap-.... Made an embedded distro Buildroot config for that one some time ago (https://github.com/unframework/licheepi-nano-buildroot).

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.

For some, the physical size is key. Seeed Xiao, Lichee Nano, Beetle, etc fit where e.g. an Arduino Nano won't.

Yes the physical size can be important, and so can the power draw.

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.

This board is based on Sipeed LM4A and it can support up to 16GB RAM and 64GB flash [1].

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

It's nice that it offers 8/16GB of RAM. I could actually use one for work.

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.

Like http://www.orangepi.org/html/hardWare/computerAndMicrocontro... ?

Pretty nice! Except no Wifi / BT when NVMe is used for storage. One of the USB3 ports could be used for wireless comms, of course.

This. Seeing The cluster board made me think "build farm", but without good IO I can't see that being much fun.

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)

> an interview with Eben Upton about RISC-Vs potential

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.

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.

That's old hat. It's called package on package. Used in phones for many years.

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.

"4 / 8 / 16 GB 64bit LPDDR4X-3733"

That's impressive in a dev board.

It's almost enough to build a custom laptop. (It lacks an NVMe or SATA interface though.)

What GPU is it built with? PowerVR?

Imagination something, and it's supposedly 4 times as fast as the one in the Raspberry Pi 4.

Ah cool. Good thing the Imagination PowerVR GPU is getting an open source driver now then.

Does that follow? They might still be shipping a userspace blob or even a closed source kernel driver :-(

Yeah, who knows what they'll ship with. But it is at least theoretically possible to run an open source stack.

I wonder what the board will cost. I'm guessing around 100$ for the 8G variant?

Is the preorder button working for anyone? Clicking it does nothing for me.

Edit: Apparently this is working - https://sipeed.com/licheepi4a/order

Does not work for me either.

This looks like a crowd funding thing. Anyone know the people running it? Are they reputable or might they pocket all the money and disappear?

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.

Does anyone know why the sudden increase in boards with 2 Ethernet ports?

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.

> bizarre transparent proxies

Any more detail on what is being done here? I don’t need to bypass the gfw, just curious

Something like https://github.com/Dreamacro/clash

Thanks!

> Lichee Router 4A

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.

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.

Dual port gigabit ethernet PHYs have become cheap?

Visionfive 2's SoC has 2x GbE, so they have to keep up with the joneses.

Might be because Edgerouters are no longer obtainable by reasonable means.

But those had 4+ ports; I guess you could put a dumb switch on one, but then you've got an additional device. Or maybe it's Good Enough™?

can we get a noscript/basic (x)html page?

Curious to know power consumption too

I can’t wait to get a cluster of 7 of these and run HaikuOS in a crazy modern BeBox.

Dual gigabit ethernet is cool.

It has 2 NICs and an optional router case. So another router board without encryption hardware extensions eh. Why people keep doing this?

The block diagram shows it has a Trusted Execution Environment[1], with AES, SHA etc. So not nothing, or?

[1]: https://en.wikipedia.org/wiki/Trusted_execution_environment

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.

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.

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.

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

It would probably have just fine encryption performance for majority of uses. Hell, wireguard isn't even using AES in the first place

With this particular set of extensions, I would not assume bad cryptography performance.

Reply on news.ycombinator.com