Sebastian Reichel
December 20, 2024
Share this post:
Reading time:
The Rockchip RK3588 upstream support has progressed a lot over the last few years. As 2024 comes to a close, it is a great time to have a look at the recent changes, work in progress, and the current state in general. Note that open source software is a community effort and not all work has been done by Collabora. This blog post will cover everyone's work just like in our RK3588 upstream status matrix.
At the start of this year the 6.7 kernel was released. This version finally had the necessary bits to have network support on the Radxa ROCK 5B. Apparently Ethernet support for the Rockchip RK3588 had been merged much earlier, but some boards - including the ROCK 5B - decided to ignore the chip's Ethernet functionality and instead went for a PCIe-based network card to get 2.5 Gigabit Ethernet (native Ethernet only supports 1 Gigabit). Even though the RK3588 uses a DesignWare-based PCIe controller, which has been well supported by the mainline kernel for many years, enabling PCIe took some time. PCIe requires interrupt messages from devices to be translated into proper interrupts, and the RK3588 has a Generic Interrupt Controller (GIC), which supports doing this operation, but its platform integration requires some quirks, and discussing them with all involved parties took time.
Later on the 6.8 kernel release happened. In this version we managed to enable the first of three USB3 controllers. The specific instance could be enabled first because it uses the same PHY as some of the PCIe controllers. Apart from that, Andy Yan from Rockchip was active and enabled basic support for the display controller VOP (video output controller), which is needed for any display-related support such as HDMI, DisplayPort, or DSI. At this point Cristian Ciocaltea was already busy cleaning up the HDMI output driver and getting it ready for upstream.
In the 6.9 kernel release, the first bits of Cristian's work landed upstream: The HDMI PHY is handled in a separate driver and got initial basic support. For actually supporting HDMI displays, that just leaves the HDMI controller itself. Unfortunately that is a lot more complex than the PHY and it has not yet landed.
Following that in 6.10 - still without display support - the chip's GPU got support, allowing 3D accelerated graphics. A whole team at Collabora lead by Erik Faye-Lund and Boris Brezillon worked on the driver for the Mali G610, which is the embedded GPU in the RK3588. Details about the kernel driver can be found in a prior blog post about Panthor; their XDC talk also covers the userspace side. Apart from that, Sebastian Reichel finished upstreaming the USBDP PHY, which is used by the other two USB3 controllers. Thus with 6.10, all USB ports can be used. Aside from USB, the PHY can also handle DisplayPort (mostly intended for USB-C AltMode), but the necessary infrastructure for that has not yet been upstreamed. Also, it's worth mentioning that support for the Rock 5B's USB-C port was not enabled in 6.10 because of the complicated USB-PD setup involved.
Finally in 6.11, CPU frequency scaling arrived for Rockchip's flagship. Alexey Charkov used the Thermal ADC support we upstreamed last year and combined it with the generic cpufreq driver from the Linux kernel and restructured the devicetrees to introduce support for RK3588J, which uses different operating point data than the normal RK3588. It's worth mentioning, that the downstream Kernel from Rockchip is using a more advanced frequency scaling method involving data like the silicon quality. This will be needed to get maximum CPU performance without sacrificing system stability and is something left for the future.
Last but not least, in 6.12 support for a few more accelerators landed: first, the RGA2 block was enabled for usage via Video for Linux 2 by Jianfeng Liu. RGA2 can be used for accelerated 2D graphics operations like scaling, rotation, or alpha blending. Sebastian Reichel finished the work from Emmanuel Gil Peyrot and Jianfeng Liu to enable one of the VEPU121 blocks for JPEG encoding and the VDPU121, which allows hardware-accelerated decoding of VP8, MPEG2, and H264.
While the release will only happen in 2025, the big thing for 6.13 will be HDMI display support. Cristian finally managed to land support for the HDMI controller, which was the last missing piece of the puzzle. For now it's quite limited in its functionality. Work is ongoing to provide more features. The next step is support for more clock rates, which allows more display modes. Right now many display resolutions might not work properly. Afterward, we also plan to provide upstream support for audio and CEC.
Apart from HDMI output, we are also working on the hardware's HDMI capture feature. Shreeya Patel and Dmitrii Osipenko are busy getting a V4L2 driver for it upstream and being fully compliant according to the v4l2-compliance checks. We expect this to land sometime in 2025.
Since the beginning of the year, Heiko Stübner has also been working on a series enabling MIPI DSI support and just recently sent the first versions out for review to the mailing lists.
Last but not least, Detlev Casanova is working on VDPU381 H264 support when he is not busy with the RK3576. That work is currently blocked, requiring analysis of how the IOMMU should be handled. Apart from that, the work is currently missing multi-core support. The hardware has two cores, which can be used to have more bandwidth. The problem is that the scheduling should happen in the kernel and that is missing a scheduler for V4L2 codecs.
One of the big surprises in 2024 was Tomeu Vizoso sending an initial fully open source kernel and Mesa driver based on reverse engineered information for the neural processor unit included in the RK3588. Hopefully this will also land next year.
Not only was the Linux kernel further developed, some things also happened in the earlier steps of the boot process. In U-Boot most of the SoC support already landed last year. One missing bit was support for the USB-PD handling. Some Rockchip boards require early USB-PD handling, and thus the U-Boot version from Rockchip contains some code to handle it. After a heavy rework from Sebastian Reichel, this also landed in the U-Boot master branch but will only arrive in the 2025.01 release.
Other than that, Rockchip provided an open source version for the Trusted Firmware-A (TF-A), which got merged and should become part of the v2.12 release. On the boot side that just leaves the DDR memory training a closed source binary.
All in all this was a great year for improving the RK3588 upstream support and the outlook looks even better!
07/01/2025
A testament to its long standing community interest and devote volunteers, FOSDEM will be celebrating its 25th anniversary this year. Join…
20/12/2024
The Rockchip RK3588 upstream support has progressed a lot over the last few years. As 2024 comes to a close, it is a great time to have…
09/12/2024
Collabora will be at NeurIPs this week to dive into the latest academic findings in machine learning and research advancements that are…
Whether writing a line of code or shaping a longer-term strategic software development plan, we'll help you navigate the ever-evolving world of Open Source.
한국어 버전의 Collabora.com 보기
Acesse Collabora.com em Português
Comments (21)
Heiko Stuebner:
Dec 20, 2024 at 08:40 PM
Just two additions :-)
For DSI support I'm hopefully this will land in 6.14 and for the broader landscape, RK3588 support in OP-TEE was merge some days ago (https://github.com/OP-TEE/optee_os/pull/7059)
Reply to this comment
Reply to this comment
Sebastian Reichel:
Dec 20, 2024 at 10:59 PM
That's great news. Thanks for the update!
Reply to this comment
Reply to this comment
Dav:
Dec 21, 2024 at 03:46 AM
How can I use Vulkan to play game on emulators on Linux on my orange pi 5? Right now I can only get LLVMpipe. And it's super slow. I use http://joshua-riek.github.io ubuntu.
Thanks in advance
Reply to this comment
Reply to this comment
stuartiannaylor:
Dec 22, 2024 at 02:32 PM
The image you are using is not mainline but the Rockchip BSP and Joshua has had a burn out with the brick wall of Rockchip who supposedly are not supporting opensource anymore.
It would be really cool if someone from collabora could provide a Debian or Ubuntu image that incorporates the latest additions on each kernel release.
I am unsure why an image isn't provided by someone else to users who would struggle with gathering the uboot, kernel and root system and build system, but doesn't seem to be.
Various images of the Rockchip BSP exist, but as Joshua has demonstrated some really great images that the BSP is a whole lot of work.
A few times I have wanted to test a few things on mainline but my interest hasn't stretched to getting into building one.
Reply to this comment
Reply to this comment
Joshua:
Dec 22, 2024 at 04:11 PM
I don't think Collabora needs pressure from amateurs who destroyed Joshua. They know very well what is their job and what they need to do.
Reply to this comment
Reply to this comment
Sebastian Reichel:
Dec 22, 2024 at 04:42 PM
Hi,
For the Rockchip vendor kernel tree and userspace I can't tell you what is needed to get Vulkan running. For an upstream based system Vulkan is still being worked on, but partially supported. I asked our panfrost team to have a look at this comment and see if they can add anything helpful. It may take a bit considering Christmas and new year being just around the corner. Until then you should be able to find some information in the XDC talked linked in the article.
Please be aware that Rockchip continues to send RK3588 kernel patches upstream themself. For example they have send an updated series for eDP support just a few days ago ( https://lore.kernel.org/linux-rockchip/20241219080604.1423600-1-damon.ding@rock-chips.com/ ). This kind of contradicts with your statement, that they are no longer supporting open source. But of course they do what seems sensible from a business point of view and as their chips are being bought, business is running fine. If you want your message to reach them - tell it to your board vendor. That is their direct customer.
We actually do generate a Debian image for the Radxa Rock 5B with a kernel containing the latest rc1 kernel release candidate together with a couple of patches we are currently working on upstreaming. More details can be found on the following page:
https://gitlab.collabora.com/hardware-enablement/rockchip-3588/debian-image-recipes
Note, that this image is mostly meant for development, evaluation and testing. We do not offer any public production level images.
Greetings,
-- Sebastian
Reply to this comment
Reply to this comment
Piotr Oniszczuk:
Dec 24, 2024 at 10:33 AM
FYI: If you are interested with ArchLinux (and e.g. Endeavour OS) on rk3588 - you may look on https://github.com/warpme/miniarch?tab=readme-ov-file#miniarch Currently I''m offering mainline 6.12.6 with additional patches (to mainline) enabling: hdmi0, hdmi1, hdmi audio, cec, h264 & hevc video decoders (some hevc content not works well yet).
Reply to this comment
Reply to this comment
stuartiannaylor:
Dec 24, 2024 at 07:38 PM
Apols Piotr as forgot as had seen your thread on the Radxa site.
That is great as just for testing a few things a ready image and Arch is a fave is a great convienient option.
Merry Xmas & Thnx
Reply to this comment
Reply to this comment
JFL:
Jan 04, 2025 at 02:43 PM
Hi Piotr Oniszczuk,
Just installed MiniArch EndeavourOS with Gnome Desktop Environment. Tried to stream Youtube video with Firefox (had installed "enhanced-h264ify" and allow only h264 format) but I don't think there is vpu hardware acceleration.
How do get Firefox or Chromium or mpv to have vpu hardware acceleration? Any other packages needed to be installed?
Reply to this comment
Reply to this comment
stuartiannaylor:
Dec 23, 2024 at 02:40 PM
https://www.cnx-software.com/2024/12/21/rockchip-rk3588-mainline-linux-support-current-status-and-future-work-for-2025/
It was just what I read, but yeah a test image that is purely for that is a great addition. Thanks Seb.
PS dunno what "Rockchip does not consider RK3588 to be an “open-source” SoC anymore" in the above article is about...
Reply to this comment
Reply to this comment
q4a:
Jan 03, 2025 at 09:58 AM
Is there any news/progress about Rock 5B HDMI audio output?
Looks like it was in working state 9 months ago:
https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/tree/rk3588-hdmi-audio
It needs rework or just merge to upstream?
Reply to this comment
Reply to this comment
Sebastian Reichel:
Jan 03, 2025 at 03:14 PM
Hi,
As briefly mentioned in the outlook HDMI audio support is on our agenda. There is some recent work from Dmitry Baryshkov (Linaro), adding a HDMI codec framework, which is already at PATCHv10 ( https://lore.kernel.org/all/20241224-drm-bridge-hdmi-connector-v10-0-dc89577cd438@linaro.org/ ). It makes sense to base the RK3588 HDMI audio support on that. Additionally we found some minor problems, which are currently being fixed before sending everything upstream. Note, that the branch you found is a simple port of the downstream code. The code in that branch has not yet been prepared for mainline integration.
Greetings,
-- Sebastian
Reply to this comment
Reply to this comment
boogie:
Jan 04, 2025 at 08:25 PM
VPU parts are mainly not done or half done, h264 decoder is running single core, the 2nd core is not working. Half the speed what chip can do. I think same for HEVC either half implemented or none...
VP9 is missing
AFBC compression which is mandatory for 8k is not supported.
RGA3 rasterer is not implemented.
I am also skipping AVS and JPEG decoders as well and a total of very capable 2 encoders...
Basically media processing is very very poor in mainline, thats why i will not switch.
Reply to this comment
Reply to this comment
Gabriel Beddoes:
Jan 10, 2025 at 09:23 PM
Hi masters, sorry to chime in, I'm only a noob. I realized long time ago your organization is the one to follow regarding rk3588 development, and I'm amazed by the efforts. I'm personally waiting for my NanoPC T6 to become my full fledged home lab, so I'm specifically cheering the iommu improvements. But I'm not here to press.
Most of the times talented people like you lacks the cheer of others like me, and I think it's the most basic thing that has to happen. So I'm here to tell you that this SOCs would be totally useless, without your endeavours. Big power on paper, and then let's wait for some reasonable people to make it useful, cause otherwise they're only expensive stupid toys with no function.
Big times folks. You're amazing.
Just a little question: how can a mere mortal like me install your very exciting kernels? Do I have to compile it, or there is a more easy way to experiment with the new features? Armbian has them already installed? Or is there a how-to guide to upgrade on a basic distro like Ubuntu or Debian?
Anyhow, I repeat, you fly really high. I wish the material life is treating you all very well.
My regards, Gabriel.
Reply to this comment
Reply to this comment
Sebastian Reichel:
Jan 10, 2025 at 10:00 PM
Hello Gabriel,
We are working on enabling these features in the mainline kernel, which is used as a basis by the standard Linux distributions like Debian or Ubuntu. For Armbian you can choose between two different kernel flavors: Either the vendor kernel (v6.1 right now) or something close to mainline (v6.12 right now). The mainline version is basically only possible because of this work and should contain all the patches up to the kernel version used by Armbian (so 6.12 right now). I suppose they will update to 6.13 once it has officially been released (we are currently at 6.13-rc6, so the final release should happen within the next 2-3 weeks). We do not generate any images for the NanoPC T6, so if you want to use the latest work-in-progress development kernel, you will have to compile things yourself.
Greetings,
-- Sebastian
Reply to this comment
Reply to this comment
Piotr Oniszczuk:
Jan 11, 2025 at 10:25 AM
You may try basic functionality on mainline 6.12.9 with https://github.com/warpme/miniarch/releases/download/v20241118/MiniArch-20240715-6.12.2-board-rk3588.nanopc_t6_lts-SD-Image.img.xz
Reply to this comment
Reply to this comment
Levi Marvin:
Jan 12, 2025 at 11:03 AM
Thanks a lot to the Collabora and all open-source sponsors! It is important to support the HDMI display, I hope it can be worked in 2025. I have tried to compile AOSP 14 (AP2A) use my custom device tree, no Rockchip components, using U-Boot 2025.01-rc2, ATF 2.11, OPTEE 4.2.0, Linux 6.13-rc1 (panthor+mesa24), however, badly, the display can not work. And the boot progress is stuck at starting some Android process. (SurfaceFlinger can report the correct GPU information, and there are correct GPU devices, DRM devices, framebuffers). however, there is no signal to the HDMI Monitor(1280x720@60hz). The board I used is LubanCat 5 v1. (And adapted kernel device tree to the mainline kernel and its format like the device tree of Radax 5B). I hope we will have that day the HDMI display is fully supported and open-sourced (Also for HDMI display on Android).
Reply to this comment
Reply to this comment
Sebastian Reichel:
Jan 13, 2025 at 08:06 PM
Hello Levi,
We are actively working on improving the upstream HDMI support of the RK3588. A 6.13-rc1 kernel should already give you basic support as long as you enable the right kernel configuration options and have a correct DT for it. The main issue are a bunch of resolutions not properly being supported because of the clock setup I'm not sure if 1280x720@60 is among those resolutions. Be assured, that fixing the clocking problems is on a high priority :) Looking through your software versions you might consider switch to upstream ATF 2.12, which contains the needed RK3588 patches. I can't comment much on your Android issues.
Greetings,
-- Sebastian
Reply to this comment
Reply to this comment
stuartiannaylor:
Jan 13, 2025 at 10:15 PM
The work being done is just great and many thanks.
Thing start to get really interesting with 6.13 and likely will be having a nosey at the images Piotr supplies on Arch
Thanks Seb and all.
Reply to this comment
Reply to this comment
Marcin Juszkiewicz:
Jan 17, 2025 at 07:36 PM
Tried to build upstream TF-A 2.12.0 for RK3588 and failed:
$ git log -1
commit 4ec2948fe3f65dba2f19e691e702f7de2949179c (HEAD, tag: v2.12.0, tag: v2.12, collabora-rk3588/rk3588, collabora-rk3588/master, rk3588)
Merge: 8f6e40f86 07a6a6544
Author: Govindraj Raja
Date: Wed Nov 20 23:30:24 2024 +0100
Merge "docs(changelog): changelog for v2.12 release" into integration
$ git clean -dfx
$ CROSS_COMPILE=aarch64-linux-gnu- make PLAT=rk3588 bl31
make: Nothing to be done for 'bl31'.
What I am doing wrong? In meantime I use NanoPC-T6 with rkbin BL31 but would like to switch to open one.
Reply to this comment
Reply to this comment
Sebastian Reichel:
Jan 17, 2025 at 08:37 PM
Hello Marcin,
This is a weird problem, which I cannot reproduce. Your steps work for me locally and also in our CI ( https://gitlab.collabora.com/hardware-enablement/rockchip-3588/u-boot/-/blob/rk3588/.gitlab-ci.yml?ref_type=heads#L32 ). Normally it even works when you just do `make PLAT=rk3588 bl31` without specifying the CROSS_COMPILE environment variable, since the build infrastructure defaults to the aarch64-linux-gnu- cross build prefix. Do you see any interesting information when running make with --debug as argument? Is anything getting build when you run make without specifying PLAT=rk3588 (that will not build a bl31 for rk3588, but should build something for a clean TF-A git repo)?
FWIW our TF-A repository is an exact copy of the upstream TrustedFirmware-A project without any local changes, since everything landed in v2.12. I suppose common Linux distributions will start building the TF-A binaries for rk3588 soon. For example as far as I can see Debian will start offering rk3588 BL31 binaries in its arm-trusted-firmware package with the next upload.
Greetings,
-- Sebastian
Reply to this comment
Reply to this comment
Add a Comment