Getting the RK3588 SoC supported in upstream Linux (2023)
kernel-recipes.org
kernel-recipes.org
But yes, I ventured into... building the kernel & image ... and like a lot of these systems it was a nightmare of brittle shell & Python scripts, patches, many steps, and multiple, multiple READMEs. And because of its origin in the world of phone/media-box SoCs, the kernel defaults set up include annoying things like overriden highly-reduced VmMalloc limit (I work on my own DB component that uses VM overcommit at very large sizes) which I can't find the right knob to fix, etc. etc.
But really, this is a very promising board. I hope to see more boards like this that lean into more "PC-class" capabilities than the usual RPi type sytems.
https://taoofmac.com/space/blog/2024/02/10/2000
I managed to get recovery booting but my rootfs didn't finish loading, and I still haven't figured out why. And I am no novice to these things (I currently have around half a dozen RK3588/3588S boards around my desk as I do some advisory work on IoT projects, and right now my strongest recommendations are all Armbian-compatible).
The best mobile platform on Arm with open-source GPU drivers rn is Qualcomm...
ARM GPUs on Linux are truly in a terrible state right now. I hope ARM gets serious about ensuring that upstream supports their GPUs soon after release.
Ironically, Imagination Technologies of PowerVR fame (infamy?) did, with a funded mesa3d driver effort. And embraced RISC-V while at it.
https://newsroom.arm.com/news/arm-expands-open-source-partne...
However, the Mali-G610 (used in the RK3588) is still not supported despite being released in 2021. ARM's "work with Collabora" started before the release of the Mali-G610, so the fact that we're so far from upstream support even after this many years of development seems like a bad sign. I don't understand why future Mali architectures wouldn't also take 4+ years unless ARM really really steps it up.
G610 (and the larger G710) are sort of special since there was a major change to the internal architecture and how work is submitted to the GPUs. Later versions didn't have such a big, breaking change.
They have pretty decent track record in producing these sort of drivers so there is a chance
Questions: A. How the system provided by Orange Pi works on the RK3588? Does it not use all the power/features? B. Why Rockchip only "suggests" how to handle problems instead of fixing it? C. Who and why created the "OEM" linux that has been installed on Orange Pi 5 for selling? C.1. Why the people who created it won't release their work into linux?
The vendor may ship this initially, but often won't work on upstreaming the changes or porting to newer kernels, so you end up with devices stuck running forks of old kernels unless somebody takes the kind of effort discussed here to upstream the changes.
The customer then needs to figure out what they want to do: Take the kernel blob as-is? Get the vendor’s kernel source and try and modify it for their specific needs? Rebase it to a newer kernel? The customer typically wants to just get enough support to ship their product; they’re not in the business of maintaining some other company’s kernel patches. They’ll do it if they have to, but the engineers will grumble about it the entire time.
Thus, getting support landed into Linux upstream is primarily the task of the chip vendor. There’s a good business case for it, as better and widely available software support will help sell the chip. But it’s also incredibly expensive to write all that kernel code and take it through the process of upstreaming. A lot of this stuff won’t meet the standards of the Linux kernel without lots of work.
The ARM SBC market flips this, where you have a bunch of enthusiasts, and then a smaller market of businesses wanting to use them in their products. That can provide enough momentum for a community-driven upstreaming effort.
Can you elaborate on this? I never got the impression that 'the standards of the Linux kernel' were some incredibly high bar.
That's what I've come expect from this space. In general, it's the usual: China, great at hardware... software an afterthought
The datasheet only gets you so far, especially for undocumented hardware quirks, and the vendor is in a much better place to understand what's happening and fix them. It's an active process of reporting bugs, investigating them, and getting fixes merged upstream into the vendor's BSP, at the very least. This requires active maintenance, which means engineers on the vendor side. That's where the support contracts kick in.
Upstreaming to Linux on top of all that means that you actually need to support and validate the set of features your chip claims to support. That means more thorough test and validation, code that meets the standards of the kernel, and more engineers to actively maintain the code. Not to mention the language barrier for Chinese chip vendors.
Of course, any upstreaming efforts are great and I think things are trending in a good direction. Just pointing out that there are reasons things are the way they are. Fabbing a chip that isn't completely buggy and people want to buy is already a small miracle- better software support can always wait until the chip becomes a hit.
https://salsa.debian.org/Mobian-team/devices/kernels/sunxi64...
The diff is 13.4 MiB and is over 200,000 lines long. It includes it's own AES and SHA-256 engine. Trying to polish this up would be close to years, and a good kernel dev is not cheap.
The kind of thing that motivates us when we build systems doesn't necessarily motivate them. The finished software product is, in the end, your problem, not theirs. Software engineers are expensive. The more they can push off and avoid paying them, the better.