September 2025

We have not had the chance to test the Rock 5B+ yet, but it seems that it directly addresses one of the biggest shortcomings of the Rock 5B that we have encountered:

On the 5B, power and firmware flashing both go through the same USB-C port. When connecting the board to a host computer for firmware flashing, this often does not provide enough current for normal system operations.

One workaround was to use a USB-C dock with PD from a power brick while still exposing the data lines for flashing. However, many USB-C docks do not implement USB-C PD correctly. This causes power resets and reboot loops. Radxa hosts a community list of compatible power supplies here.

While the 5B+ uses the same SoC, there are still some changes required to make it work:

• The 5B+ integrates LPDDR5 instead of LPDDR4 RAM, so the 5B+ requires new BL1 firmware blobs that bring up the DRAM before U-Boot SPL (BL2). Radxa probably provides these blobs somewhere.

• There are device tree changes required for U-Boot proper and Linux to make use of the peripherals. A quick search shows a device tree file for the 5B+ already.

• TF-A and RMM are board-agnostic and have a single configuration for the SoC, so this should work right away. To be compatible with as many configurations as possible, we currently limit the addressable RAM to 4GB as we have not implemented dynamic RAM discovery: RMM, TF-A, U-Boot.

A ballpark estimate is that OpenCCA bring-up on the Rock 5B+ will be less work than on other RK3588 derivatives (e.g., Orange5 Plus), but it will still require some tinkering.

We typically order Rock 5B boards from Aliexpress and it takes around 3 weeks until they arrive in Switzerland:

• Board
• Dock
• Power Brick
• eMMC
• Flashing Getting Started

August 2025

Our current implementation of the RK3588 platform limits the memory size exposed to Linux to 4 GB. This way OpenCCA works on all configurations of the RK3588, in particular the 4GB model.

The firmware currently does not support dynamic RAM discovery and assumes 4GB in TF-A, RMM, and Linux, but this is mostly for compatibility and can be changed in the firmware.

Some pointers to change this: RMM, TF-A, U-Boot.

October 2025

We recommend booting from eMMC. Compatible eMMC chips cost around 10 USD:

• Ali Express

The prebuilt image used for the SysTEX evaluation boots from eMMC. In this build, the kernel option OPENCCA_HW_DEBUG=y is enabled, which disables SDMMC and enables the SWD interface. Since both SD and hardware debugging share the same pins you can either do hardware debugging or use SD card at the same time.

You can see the relevant changes here:

• Diff

To fix this, you either:

• boot from eMMC
• or rebuild the kernel with OPENCCA_HW_DEBUG=n, and if needed, adjust the kernel cmd line arguments so the rootfs is loaded from SDMMC instead.

November 2025

I read there is a MOSFET circuit for flashing, do I need this?

The RK3588 connects over ethernet to a flash server (Raspberry Pi). It controls a MOSFET and power circuit to flash new firmware and exposes UART access.

The MOSFET circuit is not strictly necessary. You can flash the firmware manually by pressing the physical button on the SoC. However, if you plan to do this thousands of times (like we did during the initial bring up), it may be worth automating this. We soldered a simple circuit to the board to bypass the physical button, using a MOSFET as a programmable switch controlled via a Raspberry Pi GPIO pin.

You can find plenty of guides online. It is a quick job once you have the parts (MOSFET, 10kΩ, 220Ω resistors) and should be doable in a few minutes of soldering. A google search for “MOSFET as a switch” should give you the gist what to do.