Radxa rock-3c stuck at login & no hdmi

[socrates018]

Hello, I just flashed the latest minimal img  from the github releases (Armbian_community_26.2.0-trunk.7_Rock-3c_trixie_current_6.12.58_minimal.img.xz) but I see no output on hdmi and it gets stuck at login, nothing I type works.

[eselarm]

Good that you posted serial console output. A bit more and text (starting at power on when U-Boot starts) would be clearer, but I think the 2 top lines with 'Android' mentioned already indicate what is wrong I think; ROCK3C has SPI-flash where also the bootloader (U-Boot usually) can be stored and this has priority over SD-card bootloader. So it seems older/incompatible Android U-Boot variant in the SPI-flash loads Linux and as you use mainline Linux kernel, this won't work correctly as you see. On my ROCK3A, almost similar SoC I get all sorts of strange crashes/hangs in that situation.

 

So use MaskROM mode to wipe SPI-flash or write a correct U-Boot version to it; see https://docs.radxa.com/en/rock3/rock3c/low-level-dev/3c-maskrom?host_os=Linux_MacOS

 

Other option maybe is to boot with an image that has vendor kernel (I use 6.1.115 on my ROCK3A with legacy U-Boot) so then the board can be operated via serial console and from there write the SPI-flash with dd or flashcp (see /dev/mtd*).

Edited Tuesday at 09:32 AM by eselarm

[socrates018]

Thanks for replying, I hadn't noticed the android thing, I have two sd cards one with the radxa android 14 and the other with the debian bullseye from radxa. I didn't mess with the SPI flash because both work correctly, does android flash the spi when booting, I don't understand how it works with the default debian but not here?  I will try to maskrom mode and update. Btw here is the whole boot sequence in case it helps (I tried an older armbian build here but still the same). 

serial_log.txt

[eselarm]

From the serial_log.txt I can conclude that your SPI-flash must be empty, as it uses the u-boot version that is on the SD-card. So if you also don't have an eMMC attatched, that is now more simple. It is that older legacy based U-Boot, so should work with kernel 6.1.x. But kernellogging level is default set to 1, so I cannot see from the txt file what kernel it is, it might be older 6.1.x, I had lots of trouble with those. At least the 6.1.115 runs very solid on my ROCK3A now; it does all I/O I want: SPI, NVME, SATA (and SD-card as well but slot normally empty). This U-Boot:

 

root@rock3a:~# strings  /dev/mtdblock0 | grep "U-Boot SPL 20"
U-Boot SPL 2017.09-armbian (May 20 2024 - 00:46:51)

 

You can set loglevel to 7 in armbianEnv.txt (or directly on kernel commandline is more generic), then you see much more what is going on, it even might spit out info about crashing itself.

A key thing for ROCK3A is to have proper PSU: Mine is never stable with whatever 5V only PSU, so also not the RPI5 PSU for example. Various U-Boot versions don't support USB-C PD, so I just soldered my own USB-C  cable/connector that I connect to a 12V old car battery or some random 12V PSU that can do 2A or so. Then the onboard DC-DC converter is used to create a stable 5V etc.

 

I don't remember how the ROCK3C should be powered, also not sure if it has own DC-DC converter onboard, so in that case it is just 5V and you are quite dependent on the quality of your PSU. If only an SD-card, it should be fine, but when PCIe is used fort NVME, I think expect freezes.

 

Also think what you want with the ROCK3C; If you want a generic Arm64 Linux computer, you might be better off with 'edge' (both u-boot and kernel). You can't use quite some specific RK35xx features, but should be stable and easier to maintain. You can always compile/build an image yourself.

[socrates018]

Yesterday I tried to erase the SPI flash via maskROM mode, I was getting some weird errors that flash is 0 MB or that emmc is installed (It's not) but I think SPI flash is not empty although I tried to erase all with success. I run the latest minimal community (6build again and I enabled level 7 verbose. I still get the android prints and I don't see much change. Typing through UART is not possible but I noticed that with a keyboard Ctrl+Alt+Del restarts it so the keyboard works I just can't type or see. Also HDMI has no ouput so I can't do anything else. I think the 3C has a DC-DC converter but I don't think power is the problem because I used a usb tester and the draw was about 3-4 Watts. The kernel version is 6.12.59 (github releases). I don't know what else to do..

.

 

new.txt

[eselarm]

On 11/24/2025 at 10:46 PM, socrates018 said:

Armbian_community_26.2.0-trunk.7_Rock-3c_trixie_current_6.12.58_minimal.img.xz

I now realize there is no ROCK3C downloadable image on the Armbian homepage as I was going to suggest you to download a 25.8.x image or so. So '26.2.0-trunk.7' is alpha or beta release and that changes per day, now it is .22 I see. You need enough tools and skills and time to get such a community level support SBC running. The images are just generated, you are the tester/checker. I can't really help you as I don't have a ROCK3C and that is definitely needed for such a case.

 

I like the ROCK3C because with a SATA breakout board added, it is a good and cheap replacement for an old x86 PC to drive a SATA HDD/SSD. But the SATA breakout board can only be bought in China and I am in EU. Checking earlier downloaded schematic: No higher input voltage than 5V.

 

Amount of Watts consumed does not say anything about voltage level and or short dips, so it is certainly no 100% proof that power is not a or the problem, but up to yourself to judge. Also the Rx serial path (so ROCK3C signal reception) might fail. As you mention USB keyboard it reacts. I think standard ethernet will be online, so that is another way to control the board, but needs the image manually pre-configured. You can check in your router for hints. 

 

You can build image yourself or use Radxa image, it has KDE Bookworm. You then can merge upgrade that yourself, but as indicated, it is DIY. Also ARM SBC images use 1 kernel only traditionally and you cannot select at boot time. I first changed Armbian boot method to use extlinux instead of boot.scr, so now I can select at least another kernel. If hadn't done that the board would be gathering dust now for a year already. I only used maskROM once just to see if it worked, with CLI tool rkdeveloptool (is default available in Opensuse Tumbleweed, I do not use Windows).

[eselarm]

Note that ROCK3A images are 2 partitions, so 1st is boot and FAT formatted, so you should change verbosity to 7 in armbianEnv.txt, then the log will also contain kernel logs, that might tell what the problem is.

[eselarm]

FYI: I got the trunk.22 image booted, running, configured and rebooted in a CLI based QEMU KVM on my NanoPi-R6C running Trixie with edge 6.18.0-rc kernel.

xzcat Armbian_community_26.2.0-trunk.22_Rock-3c_trixie_current_6.12.59_minimal.img.xz > armimg.img
mkdir -p 1 ; losetup -fP --show armimg.img ; mount /dev/loop0p1 1
cat boot.cmd.qemu-rock3-ext4
load virtio 0:1 ${ramdisk_addr_r} /uInitrd
load virtio 0:1 ${kernel_addr_r} /Image
fdt addr ${fdt_addr}
setenv verbosity "7"
setenv rootfstype "ext4"
setenv rootdev "LABEL=armbi_root"
setenv bootargs "root=${rootdev} rootwait rootfstype=${rootfstype} loglevel=${verbosity}"
booti ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr}
mv ./1/boot.scr ./1/boot.scr.rock3c_bak
mkimage -C none -A arm -T script -d ./boot.cmd.qemu-rock3-ext4 ./1/boot.scr
sync
umount 1 ; losetup -d loop0
ln -sf /usr/lib/u-boot/qemu_arm64/u-boot.bin .
taskset --cpu-list 0-3 qemu-system-aarch64 -M virt -cpu host -enable-kvm -m 2048 -smp 4 \
-bios u-boot.bin \
-drive if=none,file=armimg.img,format=raw,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-netdev bridge,id=hn1 -device virtio-net,netdev=hn1 \
-nographic

It is a quick and dirty modification from something I did a year ago for ROCK3A to test single partition btrfs formatted rootfs (custom compiled U-Boot), so I am not 100% sure if all is correct, but it works.

 

So the trunk.22 image seems to be fine, except that I needed own boot.cmd. I could not get the one in the image to work. At least it showed something like 'failed to load /armbianEnv.txt'; that might be a U-Boot version/variant issue, it is of course not the blob for the rock3c in the image between MBR and bootFAT but a generic Debian Trixie for qemu (U-Boot 2025.01-3 (Apr 08 2025 - 23:07:41 +0000)).