rock64, compile problems "illegal instruction", "memory fault" -> ddr_333Mhz?
  since owning my rock64 (4GB version)  I had always problems compiling larger projects on the device itself.
I tried many things like an other ac-adapter, different micro-sdcards, compiling on USB, different host-images, compiling only on two cores than
one core, gcc-5, 6, 7, swap on,  nothing helped.
The compiler always runs in errors like "illegal instruction" or "memory fault" that were temporal as they disappeared at the next
After playing around with the rockchip boot flow on the rockpro64 I got the idea to check the driver for the external memory interface.
All host-images I tried on the rock64 use the same driverfile "rk3328_ddr_786MHz_v1.13.bin", so I gave the rock64 an other try with
rk3328_ddr_333MHz_v1.13.bin at offset 0x8800 on the boot device.
After reboot I compiled the ayufan-kernel on the device itself with 4 cores on internal sdcard. Worked, no error like before.
Yesterday I took an external USB-HD with the source of palemoon compiled from USB, wrote the objectfiles to the internal sdcard, 4 cores, swap on. It took the whole night, but the build completed successfully. No error like before.

Can someone tell me the negative implications when using the 333MHz-version of this driver?


I think that DDR initialization before uboot can be modified later in linux with DMC+DFI. There are enabled DMC+DFI in (some) ayufan builds.
If enabled you can dynamically set "DDR" speed (set governor,min,max...). I have stability issues with 1066000000 (4K60HDR decoding). Maybe "rk3328_ddr_333MHz_v1.13.bin" allows only lower frequencies (post output "cat /sys/class/devfreq/dmc/available_frequencies").

# grep '' /sys/class/devfreq/dmc/*
/sys/class/devfreq/dmc/available_frequencies:786000000 800000000 850000000 933000000 1066000000
/sys/class/devfreq/dmc/available_governors:dmc_ondemand userspace powersave performance simple_ondemand
/sys/class/devfreq/dmc/trans_stat:   From  :   To
/sys/class/devfreq/dmc/trans_stat:         :7860000008000000008500000009330000001066000000   time(ms)
/sys/class/devfreq/dmc/trans_stat:*786000000:       0       0       0       0       0     97457
/sys/class/devfreq/dmc/trans_stat: 800000000:       0       0       0       0       0         0
/sys/class/devfreq/dmc/trans_stat: 850000000:       0       0       0       0       0         0
/sys/class/devfreq/dmc/trans_stat: 933000000:       0       0       0       0       0         0
/sys/class/devfreq/dmc/trans_stat: 1066000000:       0       0       0       0       0         0
/sys/class/devfreq/dmc/trans_stat:Total transition : 0

# echo 933000000 > /sys/class/devfreq/dmc/max_freq
Thank you for your answer, but it shows basically the same. Problem is, when DMC is enabled, I get kernel oopses even when login with dropbear.

[quote pid='45731' dateline='1555417705']
$ grep '' /sys/class/devfreq/dmc/*
/sys/class/devfreq/dmc/available_frequencies:786000000 800000000 850000000 933000000 1066000000
/sys/class/devfreq/dmc/available_governors:dmc_ondemand powersave simple_ondemand
/sys/class/devfreq/dmc/trans_stat:   From  :   To
/sys/class/devfreq/dmc/trans_stat:         :7860000008000000008500000009330000001066000000   time(ms)
/sys/class/devfreq/dmc/trans_stat:*786000000:       0       0       0       0       0     45925
/sys/class/devfreq/dmc/trans_stat: 800000000:       0       0       0       0       0         0
/sys/class/devfreq/dmc/trans_stat: 850000000:       0       0       0       0       0         0
/sys/class/devfreq/dmc/trans_stat: 933000000:       0       0       0       0       0         0
/sys/class/devfreq/dmc/trans_stat: 1066000000:       0       0       0       0       0         0
/sys/class/devfreq/dmc/trans_stat:Total transition : 0


I think these frequencies are set in arch/arm64/boot/dts/rockchip/rk3328.dtsi as dmc_opp_table. And 768Mhz is just to much.
I'll try my luck with 400Mhz and 600Mhz. It seems a trade off between stability and memory bandwidth.

Funny thing is, on my rockpro64 the target_freq is 400Mhz.


  400 and 600 Mhz are not working with dfi/dmc in rk3328-rock64.dts.
Patching  them into rk3328_ddr_333MHz_v1.13.bin  will give me some obscure 928 Mhz frequence,
that won't reboot stable.

786 Mhz (sic!) boots, but will give me segfaults or illegal instruction when compiling.

333Mhz is shown in grep '' /sys/class/devfreq/dmc/* as 332000000 and is stable compiling.

But I found a negative implication:  Playing hevc in 720p forces framedropping in mpv.

So either compiling stable or viewing fluid videos.
Year ago there was 400/600 in DMC (you can try older kernels).

# cat /sys/class/devfreq/dmc/available_frequencies
400000000 600000000 786000000 800000000 850000000 933000000 1066000000

Never mind. I suppose that you have some fault in your PCB (like "PCB delamination"), memory/rk3328 chip and/or BGA soldering problems. Memory bus is very sensitive to impedance quality. Do you have another RK64 to compare results ? What do you compile (something equals like linux kernel?) ? I have only 1GB versions to test.
Thank you for this thread. Changing the boot image to 333Mhz fixed the "internal compiler error" that was sporadically happening when building software in parallel. This is on Rock64 ver2.

For Arch Linux ARM (boots from SD card, not eMMC), this is the concrete steps:

Get the original image:


md5sum idbloader.img
a903e86cc8fa81ae0f0e79915c7dc758  idbloader.img

This image contains rk3328_ddr_786MHz v1.06 and rk3328_miniloader v2.43 and one other image at the front, which I couldn't identify. Next, replace both the ddr init image (to change frequency to 333MHz and to update to latest version) and the miniloader (just to update to latest).

Download these files from ayufan Github:
a3e3ac380f794d50b06bbd76258b982d  rk3328_ddr_333MHz_v1.13.bin
79bfbe6ba1cde99372685a4be273994b  rk3328_miniloader_v2.46.bin

Replace the subimages in the image:

dd if=rk3328_ddr_333MHz_v1.13.bin seek=$((0x800)) conv=notrunc of=idbloader.img
dd if=rk3328_miniloader_v2.46.bin seek=$((0x6800)) conv=notrunc of=idbloader.img

Write the modified image to SD card (replace X with your device name):

 sudo dd if=idbloader.img of=/dev/sdX seek=64 conv=notrunc

Also attaching this final image to this post.

Attached Files
.gz   idbloader-ddr-333-mhz-v1.13-miniloader-v2.46.img.gz (Size: 40.31 KB / Downloads: 0)

Possibly Related Threads...
Thread Author Replies Views Last Post
  Another non-booting ROCK64 SuburbanDad 13 416 06-19-2019, 01:48 AM
Last Post: mcerveny
  Plastic storage box for Rock64 matwey 1 52 06-18-2019, 10:56 PM
Last Post: tllim
  Rock64 v2 network issues alephnull 1 111 06-07-2019, 03:30 PM
Last Post: alephnull
  Rock64 v3 - POE P1V 1 126 06-07-2019, 12:24 AM
Last Post: tllim
  Rock64 v3 and SD-Cards Humberg 11 1,546 06-06-2019, 12:48 AM
Last Post: igorp
  Download RetroPie for your Rock64 CiniCraft 3 639 06-01-2019, 08:02 PM
Last Post: x79ftw
Sad Bad first experience with rock64. Performs worse than my pi :( ekg 9 1,314 05-24-2019, 09:42 AM
Last Post: thatchunkylad1989
  Rock64 hangs without trace szus 12 1,147 05-14-2019, 01:59 AM
Last Post: petesobs
  Python GPIO Library for the Rock64 (R64.GPIO) Leapo 32 12,123 05-12-2019, 02:46 PM
Last Post: tllim
  Rock64 LCD compatibility for linux. AmroIb 0 112 05-04-2019, 09:09 PM
Last Post: AmroIb

Forum Jump:

Users browsing this thread: 1 Guest(s)