To those complaining about software instability, lack of support, etc. on anything that is not a Raspberry Pi, here are a few hints:
1. Before purchasing anything, make a list of your hardware needs then find a number of boards that could fulfill them. The (yearly updated) list at Linuxgizmos can help.
2. It is advisable to ignore any software published by the board manufacturer. Unless you spend a lot on LTS hardware (guaranteed, not just labeled as such), many manufacturers will stop releasing/updating their own distro after some time. Just concentrate on the hardware.
3. Now that you have a list, head to armbian.com or dietpi.com and find if your board brand/model is supported. Chances are that it is since those two distributions support a really high number of devices.
It might seem odd but it's not; we don't ask Asus or Supermicro to release an operating system for their mainboards, do we? So why we should expect that from SBC manufacturers when there is perfectly good 3rd party support around?
4. Find the board that is better supported and you're done. Read also the forums, lots of knowledgeable people over there! Also consider making a well deserved donation to the projects for the hard work involved.
For documentation about Allwinner and Rockchip SoCs, some among the most used in low cost boards, refer also to the following pages.
That's still a lot more work than buying a board that has a supported OS...
But really, the onus should be on chip makers to work on standardizing chips more (eg targeting SystemReady on ARM), getting their chips supported in Linux, etc. It's a lot of work to support each slightly-different SoC and relying on the community means it's a slow process and usually results in some headline features (like built-in neural engines or GPUs) never gaining support in general Linux distros.
Or gaining that support like 3 years after a chip is released, meaning it's practically irrelevant at that point unless you just want to futz around with an older board for hobby purposes.
It's not meaningless, but it just rubs me the wrong way seeing how much blood sweat and tears the community puts into these things without much in the way of official help.
You're right though - and it is a mystery to me why these chip makers don't invest heavily in software support. They genuinely seem to not understand the relationship between sales and software support.
Espressif is doing well with its esp32 chips because they have built high quality, reliable, comprehensive software support.
I won't touch any ARM device now unless its Raspberry Pi.
I am somewhat puzzled that it appears to be impossible for any other company to make 100% Raspberry Pi compatible hardware, which would solve the problem.
> You're right though - and it is a mystery to me why these chip makers don't invest heavily in software support. They genuinely seem to not understand the relationship between sales and software support.
I think it's because they target the embedded market. They want to sell not as generic boards but to manufacturers embedding them in their hardware.
This way they can charge not only for the components but also for training on the peculiarities of their chips, documentation access, support etc. I think this is the reason why so much ARM stuff is under NDAs.
Sure these other boards are supported by some distros but nothing beats the raspberry pi community size. This is a huge help trying to get something to work, for examples etc.
> Unless you spend a lot on LTS hardware (guaranteed, not just labeled as such), many manufacturers will stop releasing/updating their own distro after some time. Just concentrate on the hardware.
Raspberry Pi hardware is LTS, even boards like the pi zero are guaranteed to be manufactured for years to come. Raspbian (now RaspberryPiOS) still runs on the very first pi that was released.
> It might seem odd but it's not; we don't ask Asus or Supermicro to release an operating system for their mainboards, do we? So why we should expect that from SBC manufacturers when there is perfectly good 3rd party support around?
This is ignoring the problem that ARM boards are much less open than intel ones. There's a lot of NDA-restricted documentation when it comes to things like graphics chips. You don't install Android on your iPhone. Even when these distros support a board, it doesn't mean you can get every feature of it to work. Even the graphics chip of the pi was considered 'closed' for a long time due to NDAs.
As somebody who just wasted too much of his life trying to figure out a software issue on another RK3399 powered SBC, let me tell you that software documentation/support is worth so much more than features or power. If the software that can run on these are cobbled together semi-proprietary chains of mishmashed crap, these boards will continue to be mediocre at best.
Which! For the record... makes me very sad. There's a reason I bought the board I bought. On paper it seemed great. But the boot process was entirely undocumented and I ran into so many issues with kernel compatibility and featureset for their custom images.
This has not been my experience with rk3399 SBCs. The boot process is not only documented, but entirely blob free (from uboot to tf-a to the kernel).
Recently I even got suspend to ram working on my rk3399 powered pinebook pro, which was one of the few items I had not been able to get working with a mainline stack.
Hardware video decoding does require a recent kernel and gstreamer, but again it is fairly well documented and entirely mainline.
Don't the RPI boards require blobs to boot the GPU, which boots the rest of the board? And hardware video decoding requires paying extra and using a proprietary blob?
That said, this device (and the RPi 400) seem really wacky to me and I doubt I would ever buy one. I would not want to tell my grandparents "sorry printer does not work because arm" and the keyboard is way too sucky for me. Also no track point? That would be great for this form factor.
> Don't the RPI boards require blobs to boot the GPU, which boots the rest of the board? And hardware video decoding requires paying extra and using a proprietary blob?
Yes, Raspberry Pi hardware is stunningly awful and succeeds only through sheer ecosystem size, community dedication, and a company that's willing to ship something that works and try to make the thing reasonable in spite of having built it on completely unreasonable Hardware.
In other words: support. I think it's fairly well known around these parts that the primary appeal of the Raspberry Pi is support and brand recognition. Both are qualities that people are willing to pay for, may that be in dollars or lacking specifications.
Sure, same as any project doing reverse engineering of proprietary blobs. Eventually everything will be done though, especially if more people contribute or fund the work.
This would be a fair point if you were stuck with proprietary software. But this, this is a perfect example of how an open source ecosystem changes the physics. In an open source ecosystem, it doesn't matter how "weirdo" any chain of mishmashed crap might be if it's exactly the same weird crap as a billion other people. Scale means the fundamentals will have already been solved (or, if you're an early adopter, will soon be solved).
> If the software that can run on these are cobbled together semi-proprietary chains of mishmashed crap, these boards will continue to be mediocre at best.
What part of SW needed for RK3399 is that? To me pretty much all from bootloader to kernel is mainline in various projects and FOSS. So far it was fairly straightforward use mainline APIs trying to make cameras work via ISPs, RGA for image rotation, Hnatro for JPEG encoding in HW, etc. etc.
Very few small bugs here and there that can be easily fixed.
I've seen much worse. TRMs are available. Various other PDFs from Rockchip can be found, too (even some obscure ones about camera calibration, and stuff like that).
I have a question regarding "mainline" that I hope someone could help clarify.
What is the difference (in terms of coding, etc.) between mainlining support for a chip into Linux versus pinning it to a specific kernel revision? What makes it easy to bring a chip up on a specific kernel version,but not easy to submit that to the mainline kernel so future versions of the kernel are compatible?
Are there significant changes between kernel versions that require someone to be an active maintainer for the specific chip, making sure changes to the kernel stay compatible with the chip? And thus most manufacturer don't care enough to keep supporting future versions once they get on specific kernel version working?
To have code included in mainline you need to have reasonably sane code in the first place, and then invest some time working with upstream maintainers to address their concerns. On the other hand vendor code dumps are usually haphazardly put together garbage that nobody wants to touch.
Rebasing (possibly shitty) patches from the SBC vendor to a recent kernel can be non trivial in my experience (as someone who have 0 knowledge of the Linux kernel code, so I'm a good baseline to define what's trivial ^^). And yes most vendors are will ship one working kernel source and forget about it forever right after :) even vendors that are not the worse depend on drivers that are provided by the SoC vendor, and might be stuck because rebasing a GPU driver might even be hard for them I guess.
Code will stay compatible (if someone refactors something, they'll update all the drivers), so that's not it. You just need to test your hardware with each new kernel release (every two months), otherwise you may not notice any breakage.
From the reviews I've seen over the years for the Rk3399, even when the software side is all working, it seems to be a bit of a disappointing chip.
My guess with a lot of RK3399 devices popping up is due to a couple of things: 1. The limited supply of budget SoCs due to the chip shortage and 2. Rockchip trying to clear stock for when RK3588 boards finally start to ship. Of course, we'll be back to square one on the software part.
I do see the Jasper Lake mini PCs getting cheaper and cheaper, and I see that as more of a competitor to SBCs as there doesn't seem to be as many stock issues compared to Rpi4's and by the time you buy a Raspberry Pi, SD card, heatsink and power supply it does end up being not much cheaper.
> let me tell you that software documentation/support is worth so much more than features or power.
This is precisely why I left the RPi ecosystem for the Beaglebone ecosystem.
RPi is great for beginners. The moment you leave that level--the support is trash.
The BBB is tougher for beginners. However, everything is documented in datasheets like you expect. When you need to step up and out of the ecosystem, you can.
In my mind this share one of the great drawbacks of the Raspberry Pi 400: The storage solution is terrible and makes the whole thing pointless.
It doesn't matter that much that the regular boards don't have storage beyond the SD card. It's fine for fun little project. If you attach a keyboard, then I honestly expect this thing to be able to function as an entry-level desktop. It might just be me, but both the Raspberry Pi 400 and this Orange Pi 800 needs an M.2 slot. It doesn't need to support NVME, but at least add support for an M.2 SSD.
With the latest firmware, the RPi 4 can boot from an SSD over USB. Still not as nice and convenient as an M.2 drive would be, but it's much nicer than using an SD card.
I have a 400 booting off a USB SSD (a SanDISK 1TB external drive). It works fine, and performance is quite decent (good enough performance of Emacs, TeX, and software builds to suit me).
The other is the ridiculously shitty micro-HDMI ports. Why did they cripple the 400 with this junk?
Micro-HDMI should never, never be used unless the device is so small that a regular HDMI is impossible to implement. Even then... you should probably just make the device bigger.
NVMe drives are surprisingly cheap these days - you can get a 128GB 2230 drive for $15 from several manufacturers. 256GB 2242 drives are around $30. If you have the space for a 2280 drive, you can get larger drives for under $100/TB.
128GB microSD cards are also around $15, but will likely have worse performance and durability than the SSD.
Except that the video will freeze sporadically when she tries watching The Staircase on HBO Max.
After you go to the trouble of figuring which Chromium startup flags will get a minimally watchable streaming experience, she will then complain that the mouse is broken. When you ask her, "What do you mean the mouse is broken? I didn't touch the mouse," she replies, "I mean it doesn't move when I move it."
Then you'll notice that one of your Chromium flags has mysteriously caused sporadic jank for the mouse pointer. And you'll try to explain that it's not broken, there's just some kind of unpredictable latency in the pointer motion.
She'll then reply, "Right, it's broken."
And you'll stand there, defeated, staring into the frozen eyes of Colin Firth for five straight seconds as you finally begin to comprehend that "entry level desktop" doesn't mean what you thought it did.
I think it’s the simplicity of it that is deceptive; the RPi and other alternatives work great in experienced hands. In particular when the user can detect any early sign of an issue or is good enough to quickly diagnose what’s going wrong, fix it in 5 min and forget about it, it looks like a cute trivial little cheap machine that just works fine.
It takes looking at a kid or less experienced users working through a task for 5~10 mon to realize how much the hardware/software has to be flexible and permissive to make the user successful.
> the RPi and other alternatives work great in experienced hands.
I haven't seen a single piece of evidence that anyone can get Chromium to smoothly stream video under Raspian Bullseye (or any other distro for that matter).
The Raspberry Pi OS is just not great. I worked with one lately through an education project and was disappointed by the DE and system defaults in a lot of cases.
It's definitely not representative of the best that Linux desktops have to offer now.
Sure, but flash reliability is not great. SD cards can get hot or jostle, and eMMC can wear out and basically turn the board to ewaste (because replacement of the eMMC later in life of the device is difficult and often not worth it). Beyond that, speeds are much slower than pcie storage.
If you are like me and can't be bothered with setting up a read-only FS for the system partition, in a year or two files on the card inevitably get corrupted to the point that the OS becomes unbootable. That's how frequently I swap/reflash SD card on my home RPi media-server. The speeds aren't great either.
What I do like though is that this has an audio port. I still don't understand why they left that out on the pi 400, the excuse was that there wasn't enough space but there is.
I mean I wouldn't want to splurge for an expensive display with such an underpowered device, so people with unused VGA monitors seems like a good target market for this device.
Just looking at it reminds me of the original "keyboard computers" like the TRS-80, the C64/VIC-20. Just kind of gave me a sense of nostalgia for a second.
The form factor was hugely appealing to computer users in the 1980's, presumably because you could just plug in into the wall socket and television and everything was ready to go. I would imagine that some parents would pick them up for their kids, particularly if they wanted them to use computers for learning rather than media consumption. Some people may pick one up to emulate those vintage home computers. Some may pick them up to develop software for a Pi 4, simply because it's easier to swap a uSD card between a Pi 4 and 400 than it is to connect a keyboard and monitor to an otherwise headless Pi 4.
The RPi 400 seems pretty easy to get. I ordered 2 a couple of weeks ago and got them with no problem. It's any sort of regular RPi 4 board that's unobtainium, except occasionally as a bundle with a ton of stuff you may or may not want/need.
1. Before purchasing anything, make a list of your hardware needs then find a number of boards that could fulfill them. The (yearly updated) list at Linuxgizmos can help.
https://linuxgizmos.com/catalog-of-136-open-spec-community-b...
2. It is advisable to ignore any software published by the board manufacturer. Unless you spend a lot on LTS hardware (guaranteed, not just labeled as such), many manufacturers will stop releasing/updating their own distro after some time. Just concentrate on the hardware.
3. Now that you have a list, head to armbian.com or dietpi.com and find if your board brand/model is supported. Chances are that it is since those two distributions support a really high number of devices. It might seem odd but it's not; we don't ask Asus or Supermicro to release an operating system for their mainboards, do we? So why we should expect that from SBC manufacturers when there is perfectly good 3rd party support around?
https://www.armbian.com/download/?device_support=Supported
https://dietpi.com/#download
4. Find the board that is better supported and you're done. Read also the forums, lots of knowledgeable people over there! Also consider making a well deserved donation to the projects for the hard work involved.
For documentation about Allwinner and Rockchip SoCs, some among the most used in low cost boards, refer also to the following pages.
https://linux-sunxi.org/Main_Page
https://www.rockchip.fr/