PINE64
rock64, compile problems "illegal instruction", "memory fault" -> ddr_333Mhz? - Printable Version

+- PINE64 (https://forum.pine64.org)
+-- Forum: ROCK64 (https://forum.pine64.org/forumdisplay.php?fid=85)
+--- Forum: General Discussion on ROCK64 (https://forum.pine64.org/forumdisplay.php?fid=86)
+--- Thread: rock64, compile problems "illegal instruction", "memory fault" -> ddr_333Mhz? (/showthread.php?tid=7387)



rock64, compile problems "illegal instruction", "memory fault" -> ddr_333Mhz? - hunderteins - 04-16-2019

Hello,
  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
try.
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?

TIA,
hunderteins


RE: rock64, compile problems "illegal instruction", "memory fault" -> ddr_333Mhz? - mcerveny - 04-16-2019

Hello.

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").

Code:
# 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/cur_freq:786000000
/sys/class/devfreq/dmc/governor:dmc_ondemand
/sys/class/devfreq/dmc/max_freq:1066000000
/sys/class/devfreq/dmc/min_freq:786000000
/sys/class/devfreq/dmc/polling_interval:50
/sys/class/devfreq/dmc/system_status:0x401
/sys/class/devfreq/dmc/target_freq:786000000
/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



RE: rock64, compile problems "illegal instruction", "memory fault" -> ddr_333Mhz? - hunderteins - 04-16-2019

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/cur_freq:786000000
/sys/class/devfreq/dmc/governor:dmc_ondemand
/sys/class/devfreq/dmc/max_freq:1066000000
/sys/class/devfreq/dmc/min_freq:786000000
/sys/class/devfreq/dmc/polling_interval:50
/sys/class/devfreq/dmc/system_status:0x1
/sys/class/devfreq/dmc/target_freq:786000000
/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

[/quote]

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.

TIA,
hunderteins


RE: rock64, compile problems "illegal instruction", "memory fault" -> ddr_333Mhz? - hunderteins - 04-25-2019

Hello,

  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.


RE: rock64, compile problems "illegal instruction", "memory fault" -> ddr_333Mhz? - mcerveny - 04-25-2019

Year ago there was 400/600 in DMC (you can try older kernels).

Code:
# 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.


RE: rock64, compile problems "illegal instruction", "memory fault" -> ddr_333Mhz? - redfish - 06-22-2019

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:



Code:
wget http://os.archlinuxarm.org/os/rockchip/boot/rock64/idbloader.img


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: https://github.com/ayufan-rock64/rkbin/tree/master/rk33
a3e3ac380f794d50b06bbd76258b982d  rk3328_ddr_333MHz_v1.13.bin
79bfbe6ba1cde99372685a4be273994b  rk3328_miniloader_v2.46.bin


Replace the subimages in the image:


Code:
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):

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

Also attaching this final image to this post.


RE: rock64, compile problems "illegal instruction", "memory fault" -> ddr_333Mhz? - tomarm - 01-14-2020

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.