Orange Pi 800 Keyboard PC – A Raspberry Pi 400 alternative powered by RK3399
cnx-software.com
cnx-software.com
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
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.
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.
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.
> 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.
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.
I probably need to try to get a RPi of some kind though.
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).
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?
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.
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.
Like these weirdo Broadcom chips in Raspberry Pis?
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.
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.
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.
128GB microSD cards are also around $15, but will likely have worse performance and durability than the SSD.
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.
It's definitely not representative of the best that Linux desktops have to offer now.
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.
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).
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.
Which why one should also not buy Canon's "cinema" cameras (R5 C) that are similarly crippled with micro-HDMI (but astronomically more expensive).
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.
The software is too bad.
It's not worth the problems and incompatibilities.
Once you've spent days trying to get non Raspberry Pi devices to "just work" you'll see things in an entirely new light.
They could, at least, use different colors not to look like such a RPi rip-off.