Hi,
I’ve continued investigating the ROCK 4C+ stability issue and I now have a clearer picture.
With the newer Radxa-based Debian installation using kernel 6.1.115-8-rk2501, I can reproduce apparently random complete system freezes after several hours. When this happens, Ethernet/SSH stops and the local HDMI console freezes as well, requiring a power cycle.
Temperatures remain normal (around 55–60°C), and I reproduced the problem with different boards and different SD cards. Most importantly, one board also froze while completely offline and almost idle, so the issue does not appear to require network traffic or application workload.
I initially tried DietPi and Armbian as possible alternatives, but neither image reached a usable boot on my boards.
I have now connected a USB-TTL serial console directly to the ROCK 4C+ UART. With the working Radxa image the serial console works correctly at 1500000 baud and provides the complete boot log.
Unfortunately, the serial output from the Armbian/DietPi attempts has so far been very limited and not particularly useful. For example, with the Armbian image I get output similar to:
Boo`PL 25. _arH@ia 025
-S3 02-P0@98-@dd34cB5d@ -R440@-di``y
l`@@` bet_rate0B@@Lge freq`N4 p0, @annel 0cNH@pror
C@`@`ror!
C@@LL@H 1: LPDDR4, W=32 Col=...
`p@LF`o boot froHOMngeD`@`to 80p1, 0
Return@LF`N`oot ROM.
I also tried 115200 baud, but that did not produce meaningful output either. Therefore, at the moment I cannot provide a useful Linux/kernel log for the DietPi/Armbian boot failure. It appears that the boot process may be stopping at a very early bootloader/SPL/DDR initialization stage, before Linux itself starts.
In the meantime, I found an old official Radxa Ubuntu Server 20.04 image specifically for the ROCK 4C+ on the legacy Radxa download page:
Radxa ROCK 4 legacy downloads
This image boots correctly and uses:
Linux rock-4c-plus 4.4.194-11-rk3399-rockchip-g1bb08d49cc40
#1 SMP Fri Nov 4 21:33:40 CST 2022
I have now booted three different ROCK 4C+ boards with this Ubuntu 20.04 image and different SD cards. Two are connected through Ethernet/SSH and the third is also being monitored through the serial console. I’m leaving all three essentially idle for a long-duration stability test.
One interesting difference I already noticed is that the old Radxa 4.4 BSP appears to have some board-specific functionality configured correctly. For example, ramoops/pstore is initialized successfully:
console [pstore-1] enabled
pstore: Registered ramoops as persistent store backend
ramoops: attached 0xf0000@0x110000, ecc: 0/0
With the newer 6.1 installation, instead, ramoops fails:
ramoops ramoops: failed to locate DT /reserved-memory resource
ramoops: probe of ramoops failed with error -22
This obviously does not prove that ramoops itself has anything to do with the freezes, but it suggests that there are meaningful differences in the board-specific Device Tree/BSP configuration between the two environments.
So at this point my investigation is moving away from SD cards, networking or application workload and more towards a possible kernel / Device Tree / BSP / power-management difference between the old vendor 4.4 stack and newer kernels.
If these three Ubuntu 20.04 / kernel 4.4 boards remain stable, I’ll report the results here.
I’m also interested in understanding why the current DietPi/Armbian images fail so early on these particular ROCK 4C+ boards, and whether this could be related to bootloader/DDR initialization rather than Linux itself.