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!
08/10/2024
Having multiple developers work on pre-merge testing distributes the process and ensures that every contribution is rigorously tested before…
15/08/2024
After rigorous debugging, a new unit testing framework was added to the backend compiler for NVK. This is a walkthrough of the steps taken…
01/08/2024
We're reflecting on the steps taken as we continually seek to improve Linux kernel integration. This will include more detail about the…
27/06/2024
With each board running a mainline-first Linux software stack and tested in a CI loop with the LAVA test framework, the Farm showcased Collabora's…
26/06/2024
WirePlumber 0.5 arrived recently with many new and essential features including the Smart Filter Policy, enabling audio filters to automatically…
12/06/2024
Part 3 of the cmtp-responder series with a focus on USB gadgets explores several new elements including a unified build environment with…
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 (10)
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
Sebastian Reichel:
Mar 04, 2024 at 05:56 PM
Hi,
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
Googulator:
Mar 04, 2024 at 08:49 PM
Just found my old GitHub comment on the topic: https://github.com/Googulator/linux-rk3588-midstream/issues/3#issuecomment-1515033690
Reply to this comment
Reply to this comment
Eugen Hristev:
Mar 06, 2024 at 02:39 PM
Thanks for giving us additional information !
Reply to this comment
Reply to this comment
Jay:
May 18, 2024 at 03:19 AM
Hi Eugen, thanks for providing source code to compile tf-a for rockchip! I am planning to purchase orange pi 5 which has RK3588. Does it mean that I can compile entire software stack from EL3 to ubuntu OS from source code? Could you please provide any information how to compile them from the scratch?
Thanks!
Reply to this comment
Reply to this comment
Eugen Hristev:
May 23, 2024 at 01:06 PM
Hi,
We have a lot of information on how to build U-boot (which includes all the stages of boot you need) here :
https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/upstream_uboot.md?ref_type=heads
and it includes info on how to flash it too.
Reply to this comment
Reply to this comment
Jay:
May 29, 2024 at 11:09 PM
Thanks a lot! I could successfully bootup ubuntu with provided tf-a. I 've used https://github.com/Joshua-Riek/ubuntu-rockchip to generate an flash image with ubuntu.
Although it works well, I was wondering is it possible to just flash the linux kernel without ubuntu package (because this Joshua_riek ubuntu version does not allow me to load custom built kernel).
Reply to this comment
Reply to this comment
Eugen Hristev:
May 30, 2024 at 08:12 AM
Hi,
Uboot is able to load the kernel in many different ways. One of the most used version is extlinux, where you keep a config file and the kernel images (+DTB) in /boot in the root file system. So you don't need to "flash" the kernel but rather just copy the files to the root file system.
You can either remove the media and plug it to a laptop and write the files, or even use Uboot to do so, download them via network and write the files to the media using Uboot itself !
Hope this helps !
Eugen
Reply to this comment
Reply to this comment
jay:
Jun 01, 2024 at 09:56 PM
Thanks a lot! it seems that the u-boot.itb loaded into sd card will automatically locate the kernel image in root file system and boot the kernel.
Could you elaborate a little bit more about how to set up the root file system on sd card?
I can understand that idbloader.img and u-boot.itb should be written into sd card on specific location.
After loading those two into sdcard, how can I dump the rootfile system with kernel image to the SD Card?
Reply to this comment
Reply to this comment
Eugen Hristev:
Jun 04, 2024 at 01:46 PM
There is nothing special about that, you can download any rootfs for the architecture (aarch64) and just `dd` it to the card, or if it's a zip file, create a partition and unzip it there.
If you want to use our debian images that we already build for the rock-5b, have a look here (including instructions on how to flash it ) : https://gitlab.collabora.com/hardware-enablement/rockchip-3588/debian-image-recipes/-/blob/main/README.md?ref_type=heads
Reply to this comment
Reply to this comment
Add a Comment