ROCK(Pro)64 won't boot with Linux 6.12

Troubleshooting
15

The bootloader update might indeed be the solution: rockchip: rk3399: expand space for decompressed kernel · u-boot/u-boot@ddb3d7e · GitHub

Old memory addresses in MiB:

  • 30 device tree
  • 32.5 (compressed) kernel
  • 96 initramfs
  • 128 decompressed kernel, with a max size of 32 => until 160
  • 144 env file and overlays (we overwrite it). It is not a problem that this overlaps with the decompressed kernel, since this space is only needed before the kernel is decompressed.

So (decompressed) kernel and initamfs both can only be 32 MiB in size.

New memory addresses in MiB:

  • 32 (compressed) kernel
  • 144 env file and overlays
  • 160 decompressed kernel, with a max size of 128 => until 288
  • 288 device tree
  • 289.5 initramfs

So 128 MiB space for the kernel, and the initramfs can reach until the end of the physical RAM size, theoretically.

This change was done just with the last/current U-Boot release. As far as I can see, for 64-bit Rockchip SBCs, Armbian uses latest upstream U-Boot. I’ll verify the new layout is used on my R4S already, or whether it fits regardless.

EDIT: Yeah this is pretty exactly the issue, and should affect all 64-bit Rockchip systems:
New kernel above 32 MiB size:

image
image366×108 1.95 KB

Old kernel:
image

Luckily, we actually only need to raise kernel_comp_size, since the initramfs is small enough and with the old layout, the compressed kernel address comes last (aside of env file address), hence has no real limits. We can set this via /boot/dietpiEnv.txt as well, so no new bootloader needs to be flashed:

G_CONFIG_INJECT 'kernel_comp_size=' 'kernel_comp_size=0x8000000' /boot/dietpiEnv.txt

And that should fix the boot issues.

EDIT2: Ah, hmm, for RK3328 it is still 32 MiB for kernel decompression: u-boot/include/configs/rk3328_common.h at e04d137231f2e9e14708a32448c879125b8e308f · u-boot/u-boot · GitHub
And it does work on my NanoPi R2S and NEO3, which both have this SoC as well. I do remember now this kernel image, despite named vmlinuz (“z” for zip/compressed), is actually not compressed. In that case, the decompression address is not used at all, and the uncompressed kernel fits well between 32.5 MiB and 96 MiB. So wrong track. But still good to keep this in mind, in case it becomes a problem on other SBCs.

1 Like