Segfault with GCC in Armbian [Solved].

[ejolson]

To continue this story of over and under clocking memory for stability.  Here is a graph showing the relative memory bandwidth of the Rock64  with different memory clock speeds.



Again both of the Rock64 single-board computers I have seem stable with the memory clock set to 400 MHz. Since the errors at 786 MHz are intermittent, my guess is the memory could still go a little faster, perhaps 600 MHz or even 666 MHz.

Does anyone know how to make uboot files which initialize the memory at 600 or 666 MHz?

[tomarm]

I don't. But I do thank you ejolson for delving into this issue some of us have. Our boards should have been replaced free imo but this thread may offer us hope in getting ours /mine to compile pkgs properly. Some care about other uses like a smooth desktop, games, video and this would help them too. I'll test whatever you get done just leave us instruction steps please.

[hexdump]

i have just successfully created my own custom ddr.bin with 666mhz mem freq following the idea from here:

  https://forum.libreelec.tv/thread/10140-...post132388

by simply changing the freq values in the ddr.bin with a hex editor - in my case i used it for a rk3328 tv box,
but i think it will work the same way for the rock64 too ... here are my notes about it:

  https://github.com/hexdump0815/u-boot-mi...mhz.readme

good luck and best wishes - hexdump

[stelabentley]

This is a followup post to to confirm that the Rock64 board that was experiencing segmentation faults with the default 786 MHz memory clock on Armbian is now stable with the uboot-initialized 333 MHz setting.

On a selection of computational benchmarks performance is about 77 percent of the original setting;

for compilations with gcc more than 80 percent of the original performance is retained with the added advantage that the system doesn't crash and the compiler doesn't create segmentation faults.

I understand, but did not verify, that setting the memory clocks to 333 MHz has a noticeable affect on video playback.

As far as I'm concerned this problem is solved and I'll try to mark it as such. Although one out of the two Rock64 single-board computers I have required this configuration change, based on posts appearing on this forum, my suspicion is a much less than 50 percent--perhaps closer to 10 or 20 percent--of systems in use actually exhibit this problem.

Even so, I would favor a note on the wiki support page for the Rock64 explaining how to work around system instability by reducing the DDR RAM memory clock.
______________________
Optics 4 birding