[Volunteer needed]Too high DRAM clock speed MAY be causing you random crashes/freezes

[devrtz]

Hello all,

after having faced crashes on the latest (yet to be publicly released) debian+phosh image,
which troubled only me and none of the other team members, I have found out that the issue
had only occured after the patch increasing dram frequency had been incorporated.
pmOS had this patch for a while now and I remember when first getting the pinephone it also crashed on me.
At that time I thought that the build may not have been mature yet, but now it dawned on me that this was probably
also related to dram frequency.

So I have built a few different uboot images with varying frequencies (from 492MHz to 624Mhz) to see how high I can go,
while still having a reliable system.
I figured I can't be the only one having this problem, maybe someone else had the same problem without realizing what exactly the problem was, so thats why I'm calling for willing volunteers to try out different clock speeds and see if they have any problems.

TL;DR:
Had problems with crashes; turns out it had to do with dram clock speeds
Feel free to download my u-boot binaries or built them yourself and please report your findings.
Personally I had a stable system with 588MHz, but not with 600MHz!

LAST UPDATE: 26.07.2020
Flashable binaries (should work on all distros?)

https://fortysixandtwo.eu/upload/pinepho...pl-492.bin
https://fortysixandtwo.eu/upload/pinepho...pl-504.bin
https://fortysixandtwo.eu/upload/pinepho...pl-516.bin
https://fortysixandtwo.eu/upload/pinepho...pl-528.bin
https://fortysixandtwo.eu/upload/pinepho...pl-540.bin
https://fortysixandtwo.eu/upload/pinepho...pl-552.bin
https://fortysixandtwo.eu/upload/pinepho...pl-564.bin
https://fortysixandtwo.eu/upload/pinepho...pl-576.bin
https://fortysixandtwo.eu/upload/pinepho...pl-588.bin
https://fortysixandtwo.eu/upload/pinepho...pl-600.bin
https://fortysixandtwo.eu/upload/pinepho...pl-612.bin
https://fortysixandtwo.eu/upload/pinepho...pl-624.bin

Flashing the u-boot binaries onto your device (as root) - make sure to use the correct device (jumpdrive exposes both eMMC and the SD):

Code:

# dd if=u-boot-sunxi-with-spl-XXX.bin of=/dev/sdX bs=8k seek=1

This should work independent of which distro you are currently using.


Debian packages

https://fortysixandtwo.eu/upload/pinepho..._arm64.deb
https://fortysixandtwo.eu/upload/pinepho..._arm64.deb
https://fortysixandtwo.eu/upload/pinepho..._arm64.deb
https://fortysixandtwo.eu/upload/pinepho..._arm64.deb
https://fortysixandtwo.eu/upload/pinepho..._arm64.deb
https://fortysixandtwo.eu/upload/pinepho..._arm64.deb
https://fortysixandtwo.eu/upload/pinepho..._arm64.deb
https://fortysixandtwo.eu/upload/pinepho..._arm64.deb
https://fortysixandtwo.eu/upload/pinepho..._arm64.deb
https://fortysixandtwo.eu/upload/pinepho..._arm64.deb
https://fortysixandtwo.eu/upload/pinepho..._arm64.deb
https://fortysixandtwo.eu/upload/pinepho..._arm64.deb

As a debian package it will only work on debian based distros.

To install it you should

• download the .deb
  
• install with dpkg -i
  
• run u-boot-install-pinephone
  

I am interested to see whether this issue is widespread or if I just had bad luck in the silicon lottery


PS: From the datasheet it seems that the ram should be usable up to 800MHz?

[nas]

Is there a way to confirm that the dram frequency has changed? I've flashed 624.bin but no crashes as yet - is there a particular activity that triggers it?

[devrtz]

I am not sure how to confirm/check the current clock speed. Most tools I've found don't give any meaningful data on arm64.
In my case I: phosh was crashing often within 30s of booting (display would go dark until it was started again).

For testing I would suggest running "known good" apps (those that haven't crashed under regular operation), the more memory they consume the more likely a crash would be if you are suffering from this problem. It is like overclocking your regular computer until it becomes unstable

Myself I had my phone running a two hours on 588MHz until it crashed/froze on me.
Now with 576MHz it has been running smoothly for ~10 hours.

(@Mods: Is there a way to change my vote on the poll?)

[nas]

I quickly tried the other frequencies too and ran a youtube video while loading up a bunch of apps until phosh started to slow down - still no crash though. I'll go back to 624 and leave it on overnight to see what happens.

[dukla2000]

OK - still testing 624 but so far no problems.

To try get some reading on the speed I have run tinymembench (v0.4.9) at each step, starting from the 'stock' setting (whatever that was, presumably close to 552 based on the results.) In all cases CPU governor was set to performance, and tinymembench was aborted after the standard memcpy/standard memset results (as otherwise it runs for too long.) The exception to this (aborting) is at 624 it ran to completion fine.

Results (all numbers MB/s to nearest round number):

PHP Code:

Mem speed   memcpy   memset
 stock     1078    3729
  552      1074    3716
  588      1121    3849
  600      1135    3930
  612      1160    3972
  624      1182    4006 


PS - have run sbc-bench to complete as well at 624. Apart from tinymembench the 7-Zip benchmark probably hits memory reasonably hard: results at stock memory speed 2964,2955,2961. Results at 624 3077, 3074, 3082.

[Boern]

Only problem with 624 I had was that it wouldn't wake up from standby. Currently testing 612. Looks good so far.

[dukla2000]

I voted 624 but have had the day from hell with my phone! Last night everything I threw at 624 was no problem.

This morning started with a hang on Firefox (I figured a proper suspend may have dug over my stable platform?) Anyway, soon reverted to 612 which promptly hung starting telegram-desktop, so reverted 600. It had some issue waking from suspend - the type your pin then go straight back to the lock screen party trick. So reverted to 552. And even that has been more problematic than usual.

It may well be my carrier (Virgin UK) is completely useless as that seems to cause numerous side effects on my pinephone. For sure Firefox-esr and telegram-desktop seem to be the applications I use that normally have problems (e.g. crashing phosh so black screen for a while then re-do PIN etc) but today, even at 552, they have been worse! Made me wonder if there was any other bits in the u-boots you linked in OP?

In short - I now am uncertain to claim stability at any speed!

[Boern]

I went to 552 because I just can't wake up properly from standby, I get just a black screen. But I get that even with 552. Is the stock u-boot somewhere in the filesystem? If not, I'll reflash to mobian soon anyways.

[nas]

612 seems has been fine for an couple days so far. 624 froze the screen whilst downloading a package.

[dukla2000]

... I just can't wake up properly from standby, I get just a black screen ...

I find this really temperamental as well. Sometimes a single click works. Sometimes a longer (say 2 second) push. Sometimes a single click lights backlight but no screen, second click puts out backlight, then a push gets the PIN screen up. And sometimes can only do the 6 second admission of failure!

I'll reflash to mobian soon anyways.

ditto