We're hiring!

Almost a fully open-source boot chain for Rockchip's RK3588!

Eugen Hristev avatar

Eugen Hristev
February 21, 2024

Share this post:

Reading time:

Now included in our Debian images & available via our GitLab, you can build a complete, working BL31 (Boot Loader stage 3.1), and replace the closed binary blob with an open-source binary that anyone can compile.

In resuming our efforts in getting Rockchip's RK3588 supported upstream, we can see that recently the boot-chain has improved in the sense that the open-source BL31 (Boot Loader stage 3.1) from TF-A is now included in our Debian images, which are published on our GitLab. Previously, to build U-Boot, the stage 2 SPL (Secondary Program Loader) and stage 3 U-Boot proper, it was mandatory to include a closed-source DDR training binary blob and also a pre-built BL31 blob from the vendor.

TF-A is the Trusted-Firmware for Cortex-A cores (which are also the types of cores used by the RK3588). Currently this project is the defacto standard trusted firmware for ARM SoCs, but it does not support the RK3588. However Rockchip have sent a few patches to the TF-A project here to support this product. We had the chance to look at these patches, try them out, and put them together in a dedicated repository on our RK3588 enablement effort's page. From TF-A we can now build a complete working BL31 and replace the closed binary blob with an open-source binary that we can compile ourselves.

Here is a log of RK3588 booting using the open-source TF-A BL31 stage:

  U-Boot SPL 2024.01-g5557bfdc (Jan 21 2024 - 02:43:56 +0000) 
  Trying to boot from MMC2
  ## Checking hash(es) for config config-1 ... OK 
  ## Checking hash(es) for Image atf-1 ... sha256+ OK 
  ## Checking hash(es) for Image u-boot ... sha256+ OK 
  ## Checking hash(es) for Image fdt-1 ... sha256+ OK 
  ## Checking hash(es) for Image atf-2 ... sha256+ OK 
  NOTICE:  BL31: v2.10.0  (release):002d8e8 
  NOTICE:  BL31: Built : 02:43:49, Jan 21 2024

This is an excellent step towards making the boot chain completely open, more reliable, and easier to tweak. Previously, closed source binary blobs were opaque, nobody (except Rockchip) knew what the software was doing and nobody (except Rockchip) could apply bug fixes, updates, or changes. With this new possibility, we can solve issues, improve security , provide new features, and much more due to the fact that everyone has access and can review the code in TF-A.

There are still some missing parts and the most important that is remaining right now is the DDR training blob, which is still closed source.

At the moment of writing this article, we have identified a few differences from the binary blob previously used, which we can highlight as following:

There could be more issues that are unknown at the moment and users should be aware of it.

As always, our Notes repository holds all the information and a tutorial on how to build and flash the bootloader images on boards like the Radxa's Rock-5B here. If you are keen on trying prebuilt images, our Debian recipes repository builds them every day with the latest development and you can download them directly from here!

Comments (4)

  1. Googulator:
    Mar 04, 2024 at 11:42 AM

    Unfortunately gitlab.collabora.com doesn't allow open registration or commenting, so I'm posting here:

    https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/issues/7 says:
    "SCMI firmware takes frequency request and modifies it according to whatever it deems sensible based on silicon quality / temperature (?) / voltage and is probably making use of the PVTM IP internally."

    I've done some analysis on how SCMI works, and it's not really using PVTM, nor does it explicitly "modify" anything. What it actually uses is PVTPLL, which is basically a ring oscillator built out of the same silicon components that comprise the CPU cores themselves. By the physics of ring oscillators, with a constrant ring length, PVTPLL will generate a clock frequency that varies depending on silicon quality and voltage. The idea then is that there exists some ideal ring length, above which no matter how the input voltage varies, the generated clock will be just barely slow enough for the core not to experience overclock instability.

    SCMI configures the ring length for each PVTPLL oscillator, using a translation table from the clock frequency constants submitted by cpufreq - however, what actually determines the clock that will be set is the voltage provided to the core (higher voltages cause the PVTPLL ring to oscillate faster).

    It's possible to modify the device tree to feed CRU clocks to the cores, instead of the PVTPLL ones, which enables direct control over the cores - unfortunately, this results in instability even at frequencies below what PVTPLL sets (at least on the Rock 5B), probably because voltage sag under load no longer causes the clock frequency to also sag in sync, resulting in undervolt/overclock conditions in the cores when loaded.

    Reply to this comment

    Reply to this comment

    1. Sebastian Reichel:
      Mar 04, 2024 at 05:56 PM


      Thanks for your research and detailed report. It's very much appreciated. I've added your information in the Gitlab issue. Greetings,

      -- Sebastian

      Reply to this comment

      Reply to this comment

Add a Comment

Allowed tags: <b><i><br>Add a new comment:

Search the newsroom

Latest Blog Posts

Automatic regression handling and reporting for the Linux Kernel


In continuation with our series about Kernel Integration we'll go into more detail about how regression detection, processing, and tracking…

Almost a fully open-source boot chain for Rockchip's RK3588!


Now included in our Debian images & available via our GitLab, you can build a complete, working BL31 (Boot Loader stage 3.1), and replace…

What's the latest with WirePlumber?


Back in 2022, after a series of issues were found in its design, I made the call to rework some of WirePlumber's fundamentals in order to…

DRM-CI: A GitLab-CI pipeline for Linux kernel testing


Continuing our Kernel Integration series, we're excited to introduce DRM-CI, a groundbreaking solution that enables developers to test their…

Persian Rug, Part 4 - The limitations of proxies


This is the fourth and final part in a series on persian-rug, a Rust crate for interconnected objects. We've touched on the two big limitations:…

How to share code between Vulkan and Gallium


One of the key high-level challenges of building Mesa drivers these days is figuring out how to best share code between a Vulkan driver…

Open Since 2005 logo

We use cookies on this website to ensure that you get the best experience. By continuing to use this website you are consenting to the use of these cookies. To find out more please follow this link.

Collabora Ltd © 2005-2024. All rights reserved. Privacy Notice. Sitemap.