All,
The official Image of Debian with GUI on the Rock Pi Download page keeps freezing after 10 minutes or so of inactivity.
I unplug the mouse and KB and replug them, no joy. Just the GUI staring back at me,
Is there a setting I’m missing to keep the session live?
-Ron
I found if you disconnect usb and reconnect it will start working again.
This does NOT fix the issue.
I have installed the latest OS version, Debian Bookworm_KDE R2 and the Pi 4C+ still freezes after 10-20 minutes of inactivity. The USB keyboard and mouse are dead. Disconnecting and reconnecting does nothing. I have disabled all power save functions. No screen sleep, no hibernation mode.
Has anyone else had this issue?
I have board version 1.41.
Thanks in advance
Hello, I have the same problem; everything freezes and I can’t wake up the Rock 4C+. If anyone has a solution, I’d be very grateful. I have the latest official version installed.
Same for me! I’m having the same issue with both Armbian and DietPi.
Has anyone found a stable distro for this kind of board, even a headless one without a desktop environment?
distro is not really of interest, you should provide details about versions: kernel and U-Boot to start with. Else it is all ‘me too‘ here in this topic which is 3 years old already.
And make sure you know how to connect and use a USB-TTL serial console/debug cable. Usually even kernel crashes are perfectly visible and you should then post those here as text.
Thanks, that makes sense.
On the currently booting Radxa-based image I have:
Linux 6.1.115-8-rk2501 and U-Boot 2017.09-58-2b46c7f on a ROCK 4C+.
I have now reproduced a full system freeze after several hours on two different boards/SD cards, with HDMI frozen and Ethernet dead, but no useful message in the persistent journal before the freeze.
I will set up a 3.3 V USB-TTL serial console and repeat the test, also with the Armbian image, so I can capture the boot/crash output directly.
OK, those (6.1.115 and 2017.09) are considered ‘legacy‘ at least by me and in Armbian terminology. But they should work, but you might get corner cases where it locks up or crashes. I had this last week on my ROCK3A where I still use the same combo; complete lock-up nothing t all on serial cable, was with (rather complex) write action to SATA HDD. The workaround was to do that same write action from an Intel x86_64 computer with 7.1.8 kernel and using the HDD as LVM block device exported via NBD (or iSCSI would be preferred but had no time to set that up). Earlier the 6.1.115 kernel produced strange ethenet packet drops w.r.t. a MediaTek WiFi stick; Again no issue with a modern mainline kernel.
So maybe have a look at the HW details and see if you would benefit from a mainline based U-Boot and kernel. You will loose some functionality maybe, but if you are lucky it serves you better for what the RockPi4C+ shall do. You might even be able to run standard Debian, as I see:
/usr/lib/modules/7.1.8+deb14.1-arm64/dtb/rockchip/rk3399-rock-4c-plus.dtb
is there in Debian sid/unstable kernel. U-Boot have look for yourself.
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:
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.
I am completely new to Radxa,I have bought a Radxa Rock 4C+ recently and I am looking for Debian software to run that is available as a .deb file but every thing is .image.xz which I do not understand,is the anywhere that I can get a .deb image to put on an SD card or how do I put a .image.xz on an SD card
Install an operating system | Radxa Docs Please refer to this document for instructions.