Dietpi installation on Rock4C Plus

Hello everyone,

I tried this image: “DietPi_ROCK4CPlus-ARMv8-Trixie.img” but it doesn’t start working

I downloaded Dietpi Trixie for my Rock4C+ from your website and burned the image to an microSD with BalenaEtcher. Unfortunately, Dietpi doesn’t start working (the screen is black with no signal). When I write an old Dietpi bullseye image on the microSD, the rock works perfectly. I tried using the “apt update,” “upgrade,” and “full-upgrade” commands in the Bullseye version, but after the full-upgrade, Dietpi no longer starts working. The screen is black with no signal, and the Rock’s LED is on but not blinking. I’ve tried this test several times, and the result is the same.

Is the image on your website for SD card or eMMC?

I need to install the operating system to a MicroSD.

Thanks for any help

mod edit: Merged with existing topic.


Creating a bug report/issue

I have searched the existing open and closed issues

Required Information

DietPi_ROCK4CPlus-ARMv8-Trixie

micro SD card: 5 different ones, Sandisk, Intenso, 64 GB and 128 GB

Radxa Rock 4 C plus - two different units, both boot fine with Radxa’s Ubuntu image on the same SD cards

Same result with ALL flashed SD cards:
SBC LED turns on, Ethernet LEDs flash - no monitor image via HDMI connection

@MichaIng can you have a look pls?

The bootloader needs to stay on SD card for this SBC. You can move the rootFS to eMMC or external USB device, but the bootloader needs to stay on the sd card.

Works on eMMC as well. Generally, SD card and eMMC are both probed by SBCs directly. Only USB and NVMe (or SATA) require a bootloader on either SD card or eMMC, or on a dedicated SPI storage.

@aod do you have a UART adapter to check serial console logs? I do not own a ROCK 4 C Plus to test, and difficult to say what the issue is without bootloader output.

And it does not show up on the network, does it? Usually, the LED starts blinking once in kernel stage, but there are exceptions (like weirdly RPi 5 LED stays lid the whole time by default).

And you do not have an eMMC module attached currently, right? Just in case there is some faulty bootloader first stage on it.

… checking Armbian commits, I think this commit was faulty: rock-4se: binman boot scenario with mainline ATF by jclds139 · Pull Request #8449 · armbian/build · GitHub

It is intended for ROCK 4 SE where it switches to ATF and consequently removes DDR and BL31 blobs from the binary. It however enables ATF build for ROCK 4C Plus as well, but without removing the DDR and BL31 blobs. The family config sets correct UBOOT_TARGET_MAP, but the post_family_config___mainline_uboot from the board config overwrites this later, breaking things.

Since using ATF is generally a good idea, I’ll do a test build with post_family_config___mainline_uboot removed from the ROCK 4C Plus config. If this does not work, I’ll revert to Rockchip blobs.

I don’t have an UART adapter.

It does not show up in the network.

No eMMc module either.

I’ll try bookworm images, since I need the SBCs working. Thank you for your quick support!

No point, it uses the same bootloader and kernel. While fixing the Armbian board configs, I recognize those U-Boot packages come with SPI images. Does this board have an SPI storage to boot from USB? :thinking:
I don’t see that on the product page, hence wondering: https://radxa.com/products/rock4/4cp/#techspec

When I received the 4C plus boards in summer, I ran one with a DietPi bookworm image. That was before trixie was released. I wonder what has changed since then.

I don’t think it can boot from USB. I haven’t tried and wouldn’t know which connector to use.

This most likely. As said, I am currently fixing the config. Will ping you once a test build is ready. Will use latest U-Boot directly, with ATF, and without the unnecessary SPI image. Makes sense to go forward when already touching this.

Thanks again!

This hopefully fixes it: rock-4cplus: remove faulty UBOOT_TARGET_MAP override · MichaIng/build@5b9935f · GitHub
U-Boot build: Armbian · MichaIng/DietPi@8027eb3 · GitHub
Image build: DietPi-Build · MichaIng/DietPi@8027eb3 · GitHub
Can be found here once done: Index of /downloads/images/testing

EDIT: Done, @aod please test this image: https://dietpi.com/downloads/images/testing/DietPi_ROCK4CPlus-ARMv8-Trixie.img.xz

Thanks for the support, I will also try to test the image on my Rock4CPlus

You fixed it!

Rock 4C plus is booting with the new image.

Also…..

I have an ancient Raspberry first gen as well. Tried to boot that with DietPi, and it also failed. Maybe it’s the same issue?

nope, different SBC, different issue. You might need to open an own separat one for your RPI

Great, thanks for testing. I’ll merge that change into our base Armbian fork branch then and update our images.

The issue was very specific to the ROCK 4C Plus bootloader binary layout due to a mistake at Armbian, so whatever issue you face with the Raspberry Pi, I agree at best open a new issue about it. The benefit of RPi is that even bootloader issues should show up on HDMI.

Thanks for the changes to the bootloader, dietpi now boots without problems.

Has anyone tested the wifi module? …It doesn’t work in my Rock4CPlus. :worried:

In Journalctl’s log I have the (brcmfmac) error -2:

ott 29 23:12:20 DietPi systemd[1]: Starting systemd-rfkill.service - Load/Save RF Kill Switch Status…
ott 29 23:12:20 DietPi kernel:brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob available (err=-2)
ott 29 23:12:20 DietPi kernel: brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Aug 25 2015 18:58:57 version 7.45.69 (r581703) FWID 01-24037f6e
ott 29 23:12:20 DietPi systemd[1]: Reached target bluetooth.target - Bluetooth Support.
ott 29 23:12:20 DietPi systemd[1]: Finished ifupdown-pre.service - Helper to synchronize boot up for ifupdown.
ott 29 23:12:21 DietPi systemd[1]: Started systemd-rfkill.service - Load/Save RF Kill Switch Status.
ott 29 23:12:21 DietPi kernel: Bluetooth: hci0: BCM: chip id 107
ott 29 23:12:21 DietPi kernel: Bluetooth: hci0: BCM: features 0x2f
ott 29 23:12:21 DietPi kernel: Bluetooth: hci0: BCM4345C0
ott 29 23:12:21 DietPi kernel: Bluetooth: hci0: BCM4345C0 (003.001.025) build 0000
ott 29 23:12:21 DietPi kernel: Bluetooth: hci0: BCM: firmware Patch file not found, tried:
ott 29 23:12:21 DietPi kernel: Bluetooth: hci0: BCM: ‘brcm/BCM4345C0.radxa,rock-4c-plus.hcd’
ott 29 23:12:21 DietPi kernel: Bluetooth: hci0: BCM: ‘brcm/BCM4345C0.hcd’
ott 29 23:12:21 DietPi kernel: Bluetooth: hci0: BCM: ‘brcm/BCM.radxa,rock-4c-plus.hcd’
ott 29 23:12:21 DietPi kernel: Bluetooth: hci0: BCM: ‘brcm/BCM.hcd’
ott 29 23:12:21 DietPi systemd[1]: Expecting device sys-subsystem-net-devices-wlan0.device - /sys/subsystem/net/devices/wlan0

What is the symptom you face? And does WiFi work if you disable Bluetooth?

Are there more logs from the brcmfmac driver, particularly which firmware blob it is actually looking for? They are all present in the armbian-firmware package, but it seem to look for the wrong filename:

lrwxrwxrwx 1 root root   79 Sep 23 05:21 BCM4345C0.amlogic,sm1.hcd -> BCM4345C0_003.001.025.0162.0000_Generic_UART_37_4MHz_wlbga_ref_iLNA_iTR_eLG.hcd
lrwxrwxrwx 1 root root   79 Sep 23 05:21 BCM4345C0.firefly,rk3566-roc-pc.hcd -> BCM4345C0_003.001.025.0162.0000_Generic_UART_37_4MHz_wlbga_ref_iLNA_iTR_eLG.hcd
lrwxrwxrwx 1 root root   79 Sep 23 05:21 BCM4345C0.radxa,zero2.hcd -> BCM4345C0_003.001.025.0162.0000_Generic_UART_37_4MHz_wlbga_ref_iLNA_iTR_eLG.hcd
-rw-rw-r-- 1 root root  57K Sep 23 05:21 BCM4345C0.raspberrypi,4-compute-module.hcd
-rw-rw-r-- 1 root root  56K Sep 23 05:21 BCM4345C0_003.001.025.0162.0000_Generic_UART_37_4MHz_wlbga_ref_iLNA_iTR_eLG.hcd
...
lrwxrwxrwx 1 root root   31 Sep 23 05:21 brcmfmac43455-sdio.amlogic,sm1.bin -> ../cypress/cyfmac43455-sdio.bin
lrwxrwxrwx 1 root root   22 Sep 23 05:21 brcmfmac43455-sdio.amlogic,sm1.txt -> brcmfmac43455-sdio.txt
-rw-rw-r-- 1 root root 472K Sep 23 05:21 brcmfmac43455-sdio.bin
-rw-rw-r-- 1 root root  14K Sep 23 05:21 brcmfmac43455-sdio.clm_blob
lrwxrwxrwx 1 root root   22 Sep 23 05:21 brcmfmac43455-sdio.firefly,rk3566-roc-pc.bin -> brcmfmac43455-sdio.bin
lrwxrwxrwx 1 root root   22 Sep 23 05:21 brcmfmac43455-sdio.firefly,rk3566-roc-pc.txt -> brcmfmac43455-sdio.txt
lrwxrwxrwx 1 root root   22 Sep 23 05:21 brcmfmac43455-sdio.radxa,zero2.bin -> brcmfmac43455-sdio.bin
lrwxrwxrwx 1 root root   22 Sep 23 05:21 brcmfmac43455-sdio.radxa,zero2.txt -> brcmfmac43455-sdio.txt
lrwxrwxrwx 1 root root   22 Sep 23 05:21 brcmfmac43455-sdio.raspberrypi,3-model-b-plus.bin -> brcmfmac43455-sdio.bin
lrwxrwxrwx 1 root root   22 Sep 23 05:21 brcmfmac43455-sdio.raspberrypi,4-compute-module.bin -> brcmfmac43455-sdio.bin
-rw-rw-r-- 1 root root 1.9K Sep 23 05:21 brcmfmac43455-sdio.raspberrypi,4-compute-module.txt
lrwxrwxrwx 1 root root   22 Sep 23 05:21 brcmfmac43455-sdio.raspberrypi,4-model-b.bin -> brcmfmac43455-sdio.bin
-rw-rw-r-- 1 root root 1.9K Sep 23 05:21 brcmfmac43455-sdio.raspberrypi,4-model-b.txt
lrwxrwxrwx 1 root root   22 Sep 23 05:21 brcmfmac43455-sdio.raspberrypi,5-model-b.bin -> brcmfmac43455-sdio.bin
lrwxrwxrwx 1 root root   27 Sep 23 05:21 brcmfmac43455-sdio.raspberrypi,5-model-b.clm_blob -> brcmfmac43455-sdio.clm_blob
lrwxrwxrwx 1 root root   22 Sep 23 05:21 brcmfmac43455-sdio.raspberrypi,5-model-b.txt -> brcmfmac43455-sdio.txt
-rw-rw-r-- 1 root root 1.7K Sep 23 05:21 brcmfmac43455-sdio.txt

So a symlink should solve it. For Bluetooth we see which names it is looking for. Let’s create the more generic one:

sudo ln -s BCM4345C0_003.001.025.0162.0000_Generic_UART_37_4MHz_wlbga_ref_iLNA_iTR_eLG.hcd /lib/firmware/brcm/BCM4345C0.hcd

Just weird that this was no problem earlier. There is no recent change in the device tree, and I do not see something related in driver commits either: Making sure you're not a bot!

Here is the part for (WiFi) firmware detection: Making sure you're not a bot!

BRCMF_FW_CLM_DEF(43455, "brcmfmac43455-sdio");
...
	BRCMF_FW_ENTRY(BRCM_CC_4345_CHIP_ID, 0xFFFFFDC0, 43455),
	BRCMF_FW_ENTRY(BRCM_CC_43454_CHIP_ID, 0x00000040, 43455),
...
	struct brcmf_fw_name fwnames[] = {
		{ ".bin", bus->sdiodev->fw_name },
		{ ".txt", bus->sdiodev->nvram_name },
		{ ".clm_blob", bus->sdiodev->clm_name },
	};

So that existing /lib/firmware/brcm/brcmfmac43455-sdio.* files should be used. But maybe this no txcap_blob available is not related to the 3 common files and probably not even relevant.

EDIT: Other report about using the ROCK 4C+ as WiFi AP: AP on Rock Pi 4C+
Not sure yet whether this means that WiFi in general works there, just AP mode not, or whether AP does not work because WiFi itself does not.

Ok, I didn’t understand le problem :face_with_spiral_eyes:, but I had to reinstall the image on the microSD (perhaps I had done something wrong during the configuration phase)

However the wifi works perfectly and the Dietpi image of Michalng works well

Thank you for the support / help