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
I left this community in Aug 2019 due to PINE64 refusal to produce/deliver ROCK64-1G version 3 after more than one year of changing statuses to "planning", "evaluating", "releasing", "availability", "estimated availability" and finally "no schedule" Angry. ROCK64 is dead platform without any advantage. Buy Raspberry PI 4 !
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.
I left this community in Aug 2019 due to PINE64 refusal to produce/deliver ROCK64-1G version 3 after more than one year of changing statuses to "planning", "evaluating", "releasing", "availability", "estimated availability" and finally "no schedule" Angry. ROCK64 is dead platform without any advantage. Buy Raspberry PI 4 !
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: 36)
Glad I found this thread and thanks.    I've been suffering this segfault issue since I got the board r64v2 1GB few weeks ago.   I build a lot from source and it's not compiling right using even one core.   I'm booting from SPI in ram from ayufan's repo Aug 2019.    Not sure how to edit the spi or his image but I have to fig it out somehow.  Its not really useable as it sits for much since it's really crippled on stock Arch.    Maybe there's a distro that has this already in their image?  Not that the procedure looks too hard but for others that may come along.   Some easy edit too maybe vs replacement of idbloader.img?

UPDATE: so I used the command grep '' /sys/class/devfreq/dmc/* to find the freq of ayufan's latest rock64 build. It was set to 786000000 with no others available. Set up the rock sdcard with build-essential etc and compiled/tested ninja pkg. Works! Never did on arch or manjaro. Guess he knows the tweaks. Had me stumped and ready to quit on this board. Tough lesson. See if it lasts now.
Still researching this issue.   Manjaro dev says it's a TF-A (trustedfirmware) issue so its not a change they would implement.   Getting rock64 v2 to compile is really a difficult process.

Possibly Related Threads…
Thread Author Replies Views Last Post
  Rock64 No Audio - Solved wbecks 10 9,461 09-05-2020, 02:32 PM
Last Post: WarpLover
Thumbs Up General firmware section for the Rock64? BowerR64 2 172 09-03-2020, 08:43 PM
Last Post: BowerR64
  what is the rock64 good for? munocat 4 1,081 09-02-2020, 08:40 PM
Last Post: BowerR64
  pin connector on rock64 jeanmichel 0 116 08-22-2020, 10:04 AM
Last Post: jeanmichel
  Rock64 random freezes BTB 6 1,458 08-19-2020, 05:59 AM
Last Post: wilsonYan
  Rock64 Real Time Clock nohandlebars 1 322 07-03-2020, 06:47 AM
Last Post: t4_4t
  Got an error message when trying to flash the Rock64 OS ilan 0 305 06-29-2020, 04:53 PM
Last Post: ilan
Big Grin Rock64 as a retro-gaming console: early impressions Luke 53 34,555 06-25-2020, 09:22 AM
Last Post: dagijay
  HDMI noise on Rock64 ab1jx 1 437 06-19-2020, 04:54 PM
Last Post: ab1jx
  Rock64 v3 with Real Time Clock (RTC), how to verify? Enig123 1 393 05-31-2020, 07:31 PM
Last Post: Rocklobster

Forum Jump:

Users browsing this thread: 1 Guest(s)