Segfault with GCC in Armbian [Solved].

[ejolson]

I'm a bit lost, however, how to modify uboot to use the 333 MHz initialization.

It seems patching the SD card was not very difficult.  I downloaded

rk3328_ddr_333MHz_v1.16.bin
rk3328_miniloader_v2.46.bin

Then I followed the instructions on

http://opensource.rock-chips.com/wiki_Boot_option

typed as root

Code:

# mkimage -n rk3328 -T rksd -d rk3328_ddr_333MHz_v1.16.bin idbloader16.img
# cat rk3328_miniloader_v2.46.bin >>idbloader16.img
# dd if=idbloader16.img of=/dev/mmcblk0 seek=64 conv=notrunc
# sync

and then rebooted.

There is a parallel but slightly less helpful thread on the Armbian forum at

https://forum.armbian.com/topic/15082-ro...frequency/

I know it's not so good to run two parallel threads on different boards, but I thought I might need some specific Armbian help with this.  I'll be updating this thread soon with a performance comparison and whether the segmentation faults and kernel oops are gone.  Thanks everyone for the help!

---

I'll be updating this thread soon with a performance comparison and whether the segmentation faults and kernel oops are gone.

Here is a performance comparison between the original 786MHz memory clock and the reduced 333MHz clock when running John McCalpin's stream memory bandwidth benchmark.



The performance reduction for the scale operation was measured to be about 2.26 times which is slightly less than the expected 786/333=2.36 factor loss expected by just dividing out the clocks.

In real world applications much of this performance reduction might be mitigated by cache memory; however, it would seem having a 666MHz setting might be a better compromise between super slow and super unstable.  Does anyone know where something like

rk3328_ddr_666MHz_v1.16.bin

might be found or how to make one?