solved Rock64 Focal Fossa Memory Frequency

[ejolson]

Armbianmonitor:

http://ix.io/2vVT

I have two Rock64 single-board computers running Focal Fossa.  One is stable and the other gets segmentation faults when compiling and sometimes a kernel oops.  After some searching, my understanding is this can be fixed by slowing down the memory speed by installing rk3328_ddr_333MHz_v1.13.bin from the ayufan-rock64 GitHub repository into uboot along with possibly rk3328_miniloader_v2.46.bin as well.

 

Unfortunately, I'm clueless how to do this.  I'm running the latest Armbian Focal Fossa Server from August 19 with the 5.7.17 kernel.  Do I need to build a new image or can I patch an existing SD card?

 

I'm sorry if I there is already a thread on this.  I searched and could not find enough information that would allow me to proceed on my own.

Edited September 12, 2020 by Werner
Removed redundant "solved" suffix

[Igor]

25 minutes ago, ejolson said:

One is stable and the other gets segmentation faults

 

Throwing failed board away is much cheaper then facing potential and highly possible hw design failure.

[ejolson]

37 minutes ago, Igor said:

 

Throwing failed board away is much cheaper then facing potential and highly possible hw design failure.

 

My understanding is that this is a common problem with the Rock64 v2 boards and simply the result of some optimistic overclocking that should never have been done in the first place.  While such overclocking appears to be necessary to meet the minimum performance needed for playing back certain high-definition video, my usage for the Rock64 is not watching television but for it to function as a computer.

 

This is essentially a new board that sat in storage for six months due to certain shelter at home rules.  As returning it is not an option, I would instead like to reduce the memory frequency to a rate that runs reliably.  I was having difficulty converting the instructions I read for Arch Linux to Armbian and thought I'd ask here.  Before adding some more waste to the landfill, I'd like to give the 333 MHz option a thorough test.

 

I understand your reluctance to assist.  It must be irritating to continually deal with manufacturers that cut corners in unexpected ways with later revisions of their hardware.  Any guidance how to get started rebuilding the uboot initialization code for Armbian with the desired memory frequency would be appreciated.

[ejolson]

It seems patching the SD card is 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

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

 

I'll report back later how much slower everything is later and whether the segmentation faults and kernel oops are gone.  Thanks for all your work on Armbian!

[ejolson]

40 minutes ago, ejolson said:

I'll report back later how much slower everything is later and whether the segmentation faults and kernel oops are gone.  Thanks for all your work on Armbian!

 

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 600MHz setting might be a better compromise between super slow and super unstable.

 

At any rate, I'll be performing some stress tests over the next few days to determine whether the system is really stable now.  For reference, I also have a thread running on the Pine64 forum

 

https://forum.pine64.org/showthread.php?tid=11209&pid=76363#pid76363

 

and will update both as resolved as soon as I verify the system is now stable.

[ejolson]

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.

 

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 here required this configuration change, based on posts appearing on the Pine 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 Armbian support page for the Rock64 explaining how to work around system instability by reducing the DDR RAM memory clock.

[ejolson]

I found the file

 

rk3328_ddr_400MHz_v1.16.bin

 

at https://github.com/rockchip-linux/rkbin/...r/bin/rk33 which mitigates the performance loss a little bit compared to the 333 MHz setting.  Stability still seems fine.

[Igor]

4 hours ago, ejolson said:

I would favor a note on the Armbian support page for the Rock64 explaining how to work around system instability by reducing the DDR RAM memory clock.

 

Since we probably don't want to down-clock them all, this would be the way to go. I made a short note with a link to this thread.

 

Thanks.

[Christian_]

On 9/5/2020 at 7:06 AM, ejolson said:

I found the file

 

rk3328_ddr_400MHz_v1.16.bin

 

at https://github.com/rockchip-linux/rkbin/...r/bin/rk33 which mitigates the performance loss a little bit compared to the 333 MHz setting.  Stability still seems fine.

Link is broken because cut and paste from pine64 forum probably. Correct link is https://github.com/rockchip-linux/rkbin/tree/master/bin/rk33

[iav]

Currently I not see file rk3328_miniloader_v2.46.bin at https://github.com/rockchip-linux/rkbin/tree/master/bin/rk33

What is current replacement?

[pando85]

On 9/5/2020 at 9:48 AM, Igor said:

 

Since we probably don't want to down-clock them all, this would be the way to go. I made a short note with a link to this thread.

 

Thanks.

I see this as a common topic, I have 6 of this board and all of them suffer from time to time this problem. It would be good to add this to the image.

[RTE]

Since this is the thread linked on the Rock64 page with "In case you face stability issues, check this", I'm posting my issue experience and different workaround here.

 

After getting pretty consistent freezing even while idle on my 1GB Rock64 board I flashed the SPI to enable USB boot and switched to booting from external SSD drive rather than SD card and it has completely cleared up my freezing issues while also giving a huge performance/storage boost.

 

The board has been able achieve a stable uptime of over 60 days, now only intentionally going down for power losses or updates. Reverting back to booting from SD card immediately brings back the random freezing issues and occurs with multiple known good high quality cards from Samsung & Sandisk. I've maintained this no-SD card / USB boot stability through several upgrades since July 2020, current stable set up is Focal 5.9.14-rockchip64.

 

I don't know if there is a relationship between the higher memory speed and SD card access causing the issue as I never tried under-clocking the memory or if this is a separate issue altogether, but for those experiencing stability issues this might fix it for you as well while adding some performance rather than taking it away.

 

Ref:

Ayufan SPI flash to enable USB boot - https://github.com/ayufan-rock64/linux-build/blob/master/recipes/flash-spi.md

 

Edited January 29, 2021 by rope trick effect

[clach04]

Super dumb question, how do I check the current clock speed of the memory? dmesg, /sys, etc?

 

I have a few rock64 (v2) boards. One running Armbian fine, the other and old Ayufan OMV (need to move that to Armbian).

 

I had a board sometimes go unstable (when accessing NTFS filesystem, more details https://forum.pine64.org/showthread.php?tid=13393) so I swapped it out with another board but I keep thinking I could use the board for something and wondering if it was memory clock related.

 

I'd like to check what I have in both systems before trying to change it (and to help keep track later once its changed!)

 

Thanks!

[clach04]

@ejolson Do you have a technique for determining the current clock speed of the memory?

 

Thanks!