Is anyone running DietPi on a Pine64/soquartz?

I’m a new DietPi user, attempting to install and run on an soquartz.
I am testing the soquartz on a Raspberrry Pi CM4 IO Board.

Is anyone successfully running this combination?
I’m failing miserably using install images right off the website.
I’m following the website instructions exactly.

I’ve tried emmc booting and sdcard booting - both fail similarly.
I also tried the bookworm images (website points at buster)
but the boot setup is basically the same & it fails the same way.

I’m far from a booting expert, but it looks from the serial console like
u-boot is running OK, but then it can’t find the /boot partition, and things go downhill from there. It’s never actually finding/loading the vmlinuz.
I end up at what I believe is a u-boot prompt.

Thanks in advance if anyone can help!!

1 Like

Ha! Following up on my own post.

I was researching OS options for my soquartz. Manjaro runs,
but I really don’t like it very much. DietPi sounds like a good fit,
but as I said earlier doesn’t boot.

I ran into James Chambers’ blog from a couple weeks ago:
Pine64 SOQuartz CM4 Alternative Review - James A. Chambers
where he reports EXACTLY the same problem attempting to boot DietPi
on the soquartz as I’m having.

So, it appears that DietPi on Pine64/soquartz is DOA.

I’m pretty much a noob on booting/dts type stuff, unfortunately.
I can experiment if someone wants to give me some debugging ideas…

Thanks for reporting. I’ll try to replicate.

But he reported that Armbian worked which is anyway cleaner and lighter then dietpi.

We use Armbian as base image as well :wink:
And DietPi usually is more lightweight.

Not for Quartz64 boards, we use Peter Geis’ kernel and bootloader builds instead: Peter Geis / quartz64_ci · GitLab

And there is no SOQuartz image from Armbian, only a Quartz64 Model A image… ah, even that one has been removed from the official download server in the meantime, but only provided as community images: Releases · armbian/community · GitHub
And they are at least three times larger than our downloads.

I tried to replicate the issue, and indeed ran into boot issues as well on first attempt, with a Samsung EVO Plus 128 GiB SD card. Then I remembered facing the exact same issue before with this exact SD card:

Tried with an old Kingston 64 GiB SD card, and now it boots fine. So seems to be the Quartz64 boards are a bid picky on the SD card. Did you try another one?

Since there was just a new kernel release by Peter, as well as mainline U-Boot images for all Quartz64 models, I’ll generate new images. Probably the mainline U-Boot can boot from the Samsung EVO as well.

1 Like

ah ok I didn’t know that.

Nice, with mainline U-Boot the SOQuartz boots with the Samsung EVO. @Rick0 could you test this image, please:
Linux v6.1-rc1 included.

EDIT: Boots on all 3 Quartz64 models here :slightly_smiling_face:. SOQuartz with official Model A baseboard, btw.

You provided links to newer Linux firmware for enabling SOQuartz WiFi. In my case the only thing required was adding the .txt file:

curl -sSf '' -o /lib/firmware/brcm/brcmfmac43455-sdio.txt

Can you verify this works in your case as well (without updating/adding the firmware blobs)?

On Model A it should be the same, which was already offered for ROCKPro64:

On Model B it is a different chip, requiring brcmfmac43456-sdio firmware, which isn’t shipped by any Debian firmware package (yet), also not in Linux upstream repo, hence I took it from Armbian, who took it from LibreELEC: update `brcm` `fmac43456-sdio` firmware for Radxa Zero/Zero2 (from Li… · armbian/firmware@30d86fc · GitHub

So all WiFi firmware is now included without any package conflicts :slightly_smiling_face:.

Hello. I’m stealing this thread to share logs from booting DietPi on SOQuartz on the SOQuartz Model A Baseboard. Gets stuck. First boot after flashing the SD stops quite early. Second attempt (and upcoming attempts) the boot goes a bit further but stops. See logs from serial output:

First attempt:

DDR Version V1.13 20220218
BW=32 Col=10 Bk=8 CS0 Row=17 CS=1 Die BW=16 Size=4096MB
tdqss: cs0 dqs0: 24ps, dqs1: -72ps, dqs2: -24ps, dqs3: -72ps,

change to: 324MHz
PHY drv:clk:36,ca:36,DQ:29,odt:0
vrefinner:24%, vrefout:41%
dram drv:40,odt:0
clk skew:0x60

change to: 528MHz
PHY drv:clk:36,ca:36,DQ:29,odt:0
vrefinner:24%, vrefout:41%
dram drv:40,odt:0
clk skew:0x58

change to: 780MHz
PHY drv:clk:36,ca:36,DQ:29,odt:0
vrefinner:24%, vrefout:41%
dram drv:40,odt:0
clk skew:0x58

change to: 1560MHz(final freq)
PHY drv:clk:36,ca:36,DQ:29,odt:60
vrefinner:16%, vrefout:22%
dram drv:40,odt:80
clk skew:0x12
cs 0:
the read training result:
DQS0:0x30, DQS1:0x30, DQS2:0x34, DQS3:0x2e,
min  : 0xe  0xe  0x6  0x2  0x6  0x5  0xe  0xa , 0x6  0x2  0x2  0x2  0x8  0xd 0x12  0xc ,
       0xe  0xb  0xb  0x9  0x7  0x2  0x8  0x8 , 0x2  0x2  0x7  0x2  0x9  0x6  0x3  0x2 ,
mid  :0x26 0x28 0x20 0x1c 0x1f 0x20 0x26 0x25 ,0x1f 0x1c 0x1b 0x1d 0x21 0x29 0x2c 0x26 ,
      0x27 0x26 0x26 0x25 0x22 0x1d 0x23 0x23 ,0x1c 0x1c 0x22 0x1d 0x23 0x22 0x1e 0x1d ,
max  :0x3f 0x43 0x3a 0x37 0x38 0x3b 0x3f 0x40 ,0x39 0x37 0x35 0x39 0x3b 0x46 0x46 0x41 ,
      0x41 0x41 0x42 0x41 0x3e 0x39 0x3f 0x3f ,0x37 0x36 0x3d 0x38 0x3e 0x3e 0x39 0x39 ,
range:0x31 0x35 0x34 0x35 0x32 0x36 0x31 0x36 ,0x33 0x35 0x33 0x37 0x33 0x39 0x34 0x35 ,
      0x33 0x36 0x37 0x38 0x37 0x37 0x37 0x37 ,0x35 0x34 0x36 0x36 0x35 0x38 0x36 0x37 ,
the write training result:
DQS0:0x16, DQS1:0x4, DQS2:0xe, DQS3:0x4,
min  :0x66 0x69 0x60 0x5c 0x5e 0x5e 0x66 0x67 0x6a ,0x4b 0x48 0x48 0x49 0x4e 0x55 0x56 0x53 0x4e ,
      0x53 0x52 0x53 0x51 0x4d 0x4a 0x4e 0x51 0x50 ,0x43 0x44 0x4b 0x46 0x4b 0x48 0x47 0x48 0x49 ,
mid  :0x80 0x82 0x7a 0x76 0x77 0x78 0x7f 0x80 0x82 ,0x67 0x61 0x61 0x62 0x69 0x70 0x6f 0x6d 0x68 ,
      0x6f 0x6e 0x6e 0x6e 0x69 0x62 0x68 0x6b 0x6b ,0x5d 0x5f 0x67 0x60 0x67 0x64 0x60 0x61 0x62 ,
max  :0x9a 0x9b 0x94 0x91 0x91 0x93 0x99 0x99 0x9b ,0x83 0x7b 0x7b 0x7c 0x84 0x8b 0x89 0x88 0x83 ,
      0x8b 0x8b 0x89 0x8b 0x86 0x7b 0x83 0x86 0x87 ,0x77 0x7a 0x83 0x7b 0x83 0x80 0x7a 0x7b 0x7b ,
range:0x34 0x32 0x34 0x35 0x33 0x35 0x33 0x32 0x31 ,0x38 0x33 0x33 0x33 0x36 0x36 0x33 0x35 0x35 ,
      0x38 0x39 0x36 0x3a 0x39 0x31 0x35 0x35 0x37 ,0x34 0x36 0x38 0x35 0x38 0x38 0x33 0x33 0x32 ,
CA Training result:
cs:0 min  :0x3b 0x38 0x32 0x32 0x37 0x2d 0x38 ,0x3d 0x36 0x38 0x33 0x38 0x2f 0x3b ,
cs:0 mid  :0x78 0x7a 0x6e 0x74 0x73 0x6e 0x64 ,0x79 0x75 0x76 0x73 0x74 0x6e 0x68 ,
cs:0 max  :0xb5 0xbd 0xab 0xb6 0xaf 0xaf 0x91 ,0xb5 0xb5 0xb4 0xb3 0xb1 0xae 0x95 ,
cs:0 range:0x7a 0x85 0x79 0x84 0x78 0x82 0x59 ,0x78 0x7f 0x7c 0x80 0x79 0x7f 0x5a ,
rockchip_sdram_size fdc20208 10000201
rank 1 cs0_col 10 bk 3 cs0_row 17 bw 2 row_3_4 0
SDRAM base=0, size=100000000

U-Boot SPL 2022.04-rc2 (Nov 09 2022 - 00:02:16 +0000)
saradc@fe720000: Can't update Vdd. Error: -38saradc@fe720000: Can't update Vss. Error: -38powerdomain init.
rockchip_sdhci_probe clk set rate fail!
Trying to boot from MMC1
mmc_load_image_raw_sector: mmc block read error
Trying to boot from MMC1
mmc_load_image_raw_sector: mmc block read error
Trying to boot from MMC2
mmc_load_image_raw_sector: mmc block read error
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

After reset (pastebin)

Using SD Sandisk Extreme 64GB. Sucessfully boots Manjaro and Armbian on the same SD although fails to flash the bcm43455, can still connect to wifi with nmcli on Armbian.

I’m available to test any new developments

Nasty that it’s so picky on the SD card. With mainline U-Boot it did accept one of my cards which didn’t work before and for OP it helped as well.

The Armbian image is actually for Quartz64 Model A. Since Armbian ships a custom (WiFi etc) firmware package with 3rd party firmware included, this might include a working bcm43455 firmware as well, as opposed to the Debian firmware packages.

Obviously the bootloader works on SOQuartz as well, which is good to know. Are there any other issues with the Armbian image?

What do you mean with “fails to flash the bcm43455”? It’s just a binary firmware file that needs to be present, no flashing required.

Your assumption about “flashing” is correct, firmware file/blob.

serial output from start
dmesg output

As seen in dmesg, armbian still has some issues with bcm4345

I think the firmware fallback error is normal, if the firmware blobs do not have the long very device specific name. If the more generic fallback exists, it’s fine. AFAIK, it’s the same with our images.

I see they use the legacy vendor U-Boot, which worked worse in our case. I will test this with my Samsung EVO SD card which did not work with the vendor U-Boot build we used.

Are there probably device trees for the other Quartz64 models as well?

ls -l /boot/dtb/rockchip

If so, I guess only /boot/extlinux/extlinux.conf needs to be edited to load the correct device tree.

The kernel is older than ours, but as all features enabled one usually expects.

Yup, it’s (firmware fallback error) present in all three distros I’ve tried so far.

There are device tree binaries for the Quartz64 A and B present in this armbian build.


px30-engicam-px30-core-ctouch2.dtb rk3399-leez-p710.dtb
px30-engicam-px30-core-ctouch2-of10.dtb rk3399-nanopc-t4.dtb
px30-engicam-px30-core-edimm2.2.dtb rk3399-nanopi-m4b.dtb
px30-evb.dtb rk3399-nanopi-m4.dtb
rk3308-evb.dtb rk3399-nanopi-neo4.dtb
rk3308-roc-cc.dtb rk3399-nanopi-r4s.dtb
rk3318-a95x-z2.dtb rk3399-orangepi.dtb
rk3326-odroid-go2.dtb rk3399-pinebook-pro.dtb
rk3328-a1.dtb rk3399pro-rock-pi-n10.dtb
rk3328-evb.dtb rk3399-puma-haikou.dtb
rk3328-nanopi-r2s.dtb rk3399-rock960.dtb
rk3328-roc-cc.dtb rk3399-rock-pi-4a.dtb
rk3328-rock64.dtb rk3399-rock-pi-4a-plus.dtb
rk3328-rock-pi-e.dtb rk3399-rock-pi-4b.dtb
rk3328-roc-pc.dtb rk3399-rock-pi-4b-plus.dtb
rk3368-evb-act8846.dtb rk3399-rock-pi-4c.dtb
rk3368-geekbox.dtb rk3399-rockpro64.dtb
rk3368-lion-haikou.dtb rk3399-rockpro64-v2.dtb
rk3368-orion-r68-meta.dtb rk3399-roc-pc.dtb
rk3368-px5-evb.dtb rk3399-roc-pc-mezzanine.dtb
rk3368-r88.dtb rk3399-roc-pc-plus.dtb
rk3399-evb.dtb rk3399-sapphire.dtb
rk3399-ficus.dtb rk3399-sapphire-excavator.dtb
rk3399-firefly.dtb rk3566-firefly-roc-pc.dtb
rk3399-gru-bob.dtb rk3566-pinenote-v1.1.dtb
rk3399-gru-kevin.dtb rk3566-pinenote-v1.2.dtb
rk3399-gru-scarlet-dumo.dtb rk3566-quartz64-a.dtb
rk3399-gru-scarlet-inx.dtb rk3566-quartz64-b.dtb
rk3399-gru-scarlet-kd.dtb rk3566-roc-pc.dtb
rk3399-hugsun-x99.dtb rk3566-soquartz-cm4.dtb
rk3399-khadas-edge-captain.dtb rk3568-bpi-r2-pro.dtb
rk3399-khadas-edge.dtb rk3568-evb1-v10.dtb
rk3399-khadas-edge-v.dtb rk3568-firefly-roc-pc.dtb
rk3399-kobol-helios64.dtb rk3568-rock-3a.dtb

1 Like

Hello again.

I have tried booting from emmc with the latest image (8.13?) for SoQuartz. Still stuck, although seems to get a bit further than before. Here is some serial output

I added related issues to next release’s milestone: Issues · MichaIng/DietPi · GitHub

It is not a bootloader issue in your case, but a system instability. It seems to crash at some point when the kernel was loaded already and init system runs. Check temperatures, voltage (PSU), physical connection/contacts of power cables, eMMC, the compute module itself etc, just to rule this out. Probably Peter’s kernel gives some more stress on the system.

Thanks for the quick response.

The compute module doesn’t seem to halt completely. The activity LED keeps flashing. I have a heat sink on the CPU and it doesn’t get much hotter than body temperature.
I supply 12V with a PSU capable of 3A, I have not measured power consumption. On the baseboard I get the following measures:
12V ( at the 4 pin XH-connector): 12.13V
5V: 5.088V
3.3V: 3.36V

By the by, seems like Kernel 6.2 includes dts/i for SoQuartz + Baseboards.

Have now tried with a new Armbian build (featuring kernel 6.2_rc4) and works pretty good! Even HDMI works. Seems like the HW is not the cause for the problem described in my previous post.

You mean mainline kernel support? Good to know. But before using this kernel, we should wait for it being officially released (out of RC state).

Our kernel however is patched for this already, and as said, it boots very well on my SOQuartz on official baseboard. Only other idea I have is that you have a newer hardware revision which is not fully supported by this kernel, e.g. should run on different CPU clocks/voltage and we over/underdrive it so that it does not run stable.

1 Like


I have V1.1-20210823 compared to your’s V1.1_20220711, so the date is different but the the major/minor version numbers haven’t changed :thinking:.

You seem to have an onboard eMMC. I have an eMMC slot only, but in your case it seems to be soldiered fixed onto the CM. I didn’t know that this is the case when choosing the “optional eMMC module”. However, is that eMMC empty? Probably it actually boots from eMMC, at least the bootloader, and has issues with this, not sure. So if possible, try to erase the first 16 MiB MiB or so of the eMMC to assure there is nothing on it it could boot from.