Boot gets stuck at "Starting kernel ..." (eMMC + prebuilt binaries)

[hoseinyavarzadeh]

Description
I am attempting to replicate the OpenCCA environment on a Rock5B using the pre-built binaries provided in the systex25 release. While the flashing process completes successfully via rkdeveloptool, the boot process hangs indefinitely at the "Starting kernel ..." stage over UART.

Environment
Host OS: macOS (rkdeveloptool installed manually)

Target Hardware: Rock5B

Power Supply: Anker Nano II via Anker PowerExpand 6-in-1 (as recommended)

Serial Connection: USB-to-TTL adapter (accessed via /dev/tty.usbserial-XXXXX)

Binaries: opencca.tar.gz (systex25)

Steps to Reproduce:

1. Preparation: Download and extract the release package.

wget https://github.com/opencca/opencca-releases/releases/download/opencca/systex25/opencca.tar.gz
tar -xzf opencca.tar.gz
MaskROM Entry: Booted the Rock5B into MaskROM mode (confirmed via rkdeveloptool ld).

2. Flashing:

sudo rkdeveloptool db ./tools/rk3588_spl_loader_v1.08.111.bin
sudo rkdeveloptool wl 0 ./rootfs/opencca-image-rockchip-rock5b-rk3588.img
sudo rkdeveloptool rd

3. Boot: Connect to UART and monitor output during power-on.
   The bootloader initializes, but the output stops completely after the following line: Starting kernel ...

HDMI Output: No signal detected on HDMI.

Serial Logs: See the attached minicom.txt for the full trace prior to the hang.

Questions
Is there any reason that this might happen and boot get stuck at "Starting kernel ..."?

Is the lack of HDMI output expected during the initial kernel phase of OpenCCA, or should there be a console visible?

Are there specific environment variables or boot.scr modifications required when flashing from a macOS host that might differ from the Linux instructions?

Is it possible the SPL loader or the image itself requires a specific firmware version on the SPI flash before writing the rootfs?

Any guidance on debugging this kernel hang would be greatly appreciated.

[hoseinyavarzadeh]

minicom.txt

[abertschi]

Hi,

thanks for reaching out and for the detailed report.

I tried to reproduce your issue on both a ThinkPad running Ubuntu and an Arm M1 MacBook but could not reproduce the behavior you are seeing (with 16 GB RAM model and eMMC 59640 MB). This suggests the issue is likely board-specific.

Based on your attached minicom.txt, I believe the issue is that you are using the 32 GB variant of the Rock 5B:

DRAM: 32 GiB (effective 31.5 GiB)

At the moment, OpenCCA assumes a 16 GB RAM layout.

The TF-A and U-Boot board configurations contain hard-coded DRAM offsets and size limits, and I have not yet implemented dynamic RAM discovery.

Please also see the FAQ entry Q: How can I use more than 4GB of RAM on the Rock 5B?.

I only have access to 16 GB RK3588 models. However, someone else encountered a similar issue on a 32 GB model and resolved it with the following changes:

I managed to resolve the main boot issue on the 32GB Rock 5B by fixing a couple of 16GB-specific lines.

1) 32GB RAM fix (hard-coded offsets/sizes)

In TF-A, I updated the DRAM2 size for 32GB boards:
<tfa repo>/plat/rockchip/rk3588/opencca/rk3588_opencca.h:52
#define ARM_DRAM2_SIZE UL(0x700000000) /* 28GB for 32GB boards */

In U-Boot, I changed the end address from 16GB to 32GB:
<u-boot repo>/board/radxa/rock5b-rk3588/rock5b-rk3588.c:28
.end = 0x7ffffffff, /* Changed from 16GB (0x3ffffffff) to 32GB */

After these changes, the system boots as expected.

Could you try applying the same modifications?

For completeness, I am also attaching my own minicom.txt from a successful boot on a 16 GB board.

Re your other questions:

• No HDMI output is expected during early boot. HDMI is only initialized later.
• No special SPI flash firmware is required beyond what is included in the provided binaries. We all use Linux to build and flash the firmware, but it seems macOS works just fine for flashing, too. I enumerated the rkdeveloptool commands of my eMMC for completeness.
• Best practice for debugging is to build from source (TF-A, RMM, U-Boot, and Linux) and rely on the serial console or a hardware debugger.
• It is also useful to keep a working kernel configuration available in U-Boot. If you build custom kernels, consider using a new LOCALVERSION so multiple kernel entries appear in U-Boot. This allows you to recover if a change breaks boot (LOCALVERSION, deb)
• As an alternative reference, Collabora also provides prebuilt kernel images for the RK3588. CI-Job.

rkdeveloptool.txt
minicom.txt

[hoseinyavarzadeh]

This indeed worked! Thank you for the prompt response.