+- PINE64 (https://forum.pine64.org)
+-- Forum: PinePhone (https://forum.pine64.org/forumdisplay.php?fid=120)
+--- Forum: PinePhone Hardware (https://forum.pine64.org/forumdisplay.php?fid=122)
+--- Thread: [Volunteer needed]Too high DRAM clock speed MAY be causing you random crashes/freezes (/showthread.php?tid=9832)
RE: [Volunteer needed]Too high DRAM clock speed MAY be causing you random crashes/freezes - gotomech - 05-19-2020
So, maybe I'm dumb and doing this wrong, but can I just replace the u-boot bin file in /usr/share/u-boot on the sd card with the new bin file and it just works when I boot from the sd card?
Cause I have a bad black screen issue and figured I'd try this, but mine happens live and usually after I touch the touchscreen. So, I don't know if it's this issue, but I'm trying to test it and see. So I'm not sure if I need to run the dd script or if the file getting replaced will do the job.
Thanks for the help!
RE: [Volunteer needed]Too high DRAM clock speed MAY be causing you random crashes/freezes - dukla2000 - 05-19-2020
(05-19-2020, 01:05 PM)gotomech Wrote: So I'm not sure if I need to run the dd script or if the file getting replaced will do the job.
You need to dd the file - it is being written to an area of disk that is accessed during the boot process.
RE: [Volunteer needed]Too high DRAM clock speed MAY be causing you random crashes/freezes - gotomech - 05-19-2020
(05-19-2020, 02:08 PM)dukla2000 Wrote:(05-19-2020, 01:05 PM)gotomech Wrote: So I'm not sure if I need to run the dd script or if the file getting replaced will do the job.
You need to dd the file - it is being written to an area of disk that is accessed during the boot process.
Thank you! I did that and it seems to have worked. Sadly, didn't seem to solve my problem, even on the slowest speed of RAM.
RE: [Volunteer needed]Too high DRAM clock speed MAY be causing you random crashes/freezes - dejvino - 05-20-2020
Thank you for this thread, devrtz!
I couldn't reliably boot any of the recently released images (pmos, mobian, ubports); it would just crash at random a few moments after UI would show up. Usually somewhere in a kernel lock or when handling memory. A month or two back everything was fine. Actually the older images still work fine today. This explains why! Now I can use the phone again.
588 MHz works fine on my BH. 600 MHz crashed after several minutes, 612 and 624 crashed within seconds after a login prompt shows on the serial term.
RE: [Volunteer needed]Too high DRAM clock speed MAY be causing you random crashes/freezes - devrtz - 05-20-2020
You are very welcome (:
@Djhg2000
I'm still trying to figure out how to u-boot can be used to set command line arguments for the kernel (for memset).
Haven't found the location yet where this could be done.
After giving this some thought, maybe it is a better idea to leave u-boot as it is, and instead build the kernel with
the necessary command line baked into it.
RE: [Volunteer needed]Too high DRAM clock speed MAY be causing you random crashes/freezes - dukla2000 - 05-20-2020
(05-20-2020, 03:05 PM)devrtz Wrote: You are very welcome (:
@Djhg2000
I'm still trying to figure out how to u-boot can be used to set command line arguments for the kernel (for memset).
Haven't found the location yet where this could be done.
After giving this some thought, maybe it is a better idea to leave u-boot as it is, and instead build the kernel with
the necessary command line baked into it.
On my RockPro64, in the days when I compiled kernels for it you would get an additional option in extlinux.conf - if selected then it boots directly into memtest. It is probably the purest test but I think the "problem" is not so subtle and I can now easily reproduce by installing memtester which will run as an application.
If I boot my BraveHeart with stock Mobian, or patched with your 600 or even 588 u-boots then the following in a King's Cross terminal session will quickly fail
Code:
echo performance |sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
sudo memtester 1G 1memtester will try use 1Gb of memory and run for 1 pass, which takes about 30 minutes to successful completion (it says OK or done or similar). If your system is unstable typically phosh crashes and after entering your PIN your terminal session has vanished.
I passed this sequence (indeed even memtester 1G 4 which ran for about 2 hours) at 576 but still feel my phone is not 100% stable.
RE: [Volunteer needed]Too high DRAM clock speed MAY be causing you random crashes/freezes - Djhg2000 - 05-21-2020
(05-20-2020, 03:05 PM)devrtz Wrote: You are very welcome (:
@Djhg2000
I'm still trying to figure out how to u-boot can be used to set command line arguments for the kernel (for memset).
Haven't found the location yet where this could be done.
After giving this some thought, maybe it is a better idea to leave u-boot as it is, and instead build the kernel with
the necessary command line baked into it.
Sorry for the delay, I've been having a rough few weeks (unfortunately ending with a funeral yesterday) so I've had other things to attend to and I've been feeling awful in general. None of this is directly related to the coronavirus, but I've been unable to get much of anything done.
This seems to be a cheat-sheet on how to configure the cmdline which U-boot passes on to the kernel: https://docs.embeddedarm.com/U-boot_cmdline
From what I gather I think we can set this from the serial port on boot, so I think the proof of concept would be to enter the interactive U-boot console with the headphone jack serial port and changing the "cmdline_append" environment variable. Just remember to read it out first so that you don't lose whatever the proper cmdline is. Then it should be one of the boot commands ("booti"?) to boot the predefined kernel image. I'm not too familiar with U-boot though so this might all be completely wrong because I've misread the documentation.
I haven't gotten to work on the script yet, but I've decided to release the script version first and figure out how to make an app out of it later. One obvious problem is that I don't actually have a broken stick of RAM with me (self isolating away from home) to be 100% sure the script works. I can't overclock the RAM on my workstation until I get small errors so I'll need someone else to test it, preferably on a real phone.
The interim solution might be to instead run "memtester" (probably available in the repo), but keep in mind it works by reserving a chunk of memory at an arbitrary offset (where the Linux kernel decides it fits). It won't test the whole memory and it won't return reliable offsets but it might be able to separate out the worst cases which barely boot.
Edit: Clarify first paragraph.
Edit 2: I forgot we're working with a Debian-like system. The "grep -i memtest /boot/config-$(uname -r)" command should return "CONFIG_MEMTEST=y" if memtest is enabled in the currently running kernel.
RE: [Volunteer needed]Too high DRAM clock speed MAY be causing you random crashes/freezes - wibble - 05-22-2020
I take it the uboot doesn't yet have a screen driver or button mappings, so we can't use it for the boot menu as the openmoko used to. I'll have to see if I can find enough bits to make the serial cable.
http://wiki.openmoko.org/wiki/U-Boot_commands
http://wiki.openmoko.org/wiki/U-Boot_environment
RE: [Volunteer needed]Too high DRAM clock speed MAY be causing you random crashes/freezes - Djhg2000 - 05-23-2020
Alright, an early test version is now available at https://pastebin.com/LRukGNup . I'll probably put this up on Github when it's been through sufficient testing and memtest support is ironed out in the bootloader/kernel. Dependencies are bash, sed and, unless you provide the logfile location, dmesg.
Note that this is just parsing the output from the Linux memtest, without memtest activated in the kernel (both compiled in and specified on the cmdline) this won't do anything. I'd recommend "memtest=17" on the cmdline but the script makes no assumptions on how many patterns you use. Further instructions in the script header.
I couldn't get a log sample from a system with bad memory so the entire error handling section is made from reverse engineering of the Linux source code. If you have a kernel log from a system with bad memory I'd greatly appreciate if you could provide real error messages.
RE: [Volunteer needed]Too high DRAM clock speed MAY be causing you random crashes/freezes - dukla2000 - 05-23-2020
(05-23-2020, 01:16 PM)Djhg2000 Wrote: ...
I couldn't get a log sample from a system with bad memory so the entire error handling section is made from reverse engineering of the Linux source code. If you have a kernel log from a system with bad memory I'd greatly appreciate if you could provide real error messages.
But how do I get memtest to execute on boot?
I added memtest=17 in /boot/boot.cmd
Code:
$ cat /boot/boot.cmd
if test ${mmc_bootdev} -eq 0 ; then
echo "Booting from SD";
setenv linux_mmcdev 0;
else
echo "Booting from eMMC";
setenv linux_mmcdev 2;
fi;
setenv bootargs console=ttyS0,115200 no_console_suspend panic=10 consoleblank=0 loglevel=7 root=/dev/mmcblk${linux_mmcdev}p1 ro splash memtest=17 plymouth.ignore-serial-consoles vt.global_cursor_default=0
...but clearly that isn't what is being used at boot
Code:
$ uname -a
Linux DuklaPP 5.6-pinephone #5.6.0+pinephone6 SMP PREEMPT Fri May 15 23:20:03 CEST 2020 aarch64 GNU/Linux
chris@DuklaPP:~$ grep -i memtest /boot/config-$(uname -r)
CONFIG_MEMTEST=y
chris@DuklaPP:~$ ./mem.sh
No memtest output found in kernel log, wrong boot option?
$ dmesg | grep Kernel
[ 0.000000] Kernel command line: console=ttyS0,115200 no_console_suspend panic=10 consoleblank=0 loglevel=7 root=/dev/mmcblk2p1 ro splash plymouth.ignore-serial-consoles vt.global_cursor_default=0
...