Orange Pi5 kernel

^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  1) ========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  2) How to get s2ram working
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  3) ========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  4) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  5) 2006 Linus Torvalds
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  6) 2006 Pavel Machek
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  7) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  8) 1) Check suspend.sf.net, program s2ram there has long whitelist of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  9)    "known ok" machines, along with tricks to use on each one.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) 2) If that does not help, try reading tricks.txt and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12)    video.txt. Perhaps problem is as simple as broken module, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13)    simple module unload can fix it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) 3) You can use Linus' TRACE_RESUME infrastructure, described below.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) Using TRACE_RESUME
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) ~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) I've been working at making the machines I have able to STR, and almost
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) always it's a driver that is buggy. Thank God for the suspend/resume
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) debugging - the thing that Chuck tried to disable. That's often the _only_
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) way to debug these things, and it's actually pretty powerful (but
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) time-consuming - having to insert TRACE_RESUME() markers into the device
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) driver that doesn't resume and recompile and reboot).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) Anyway, the way to debug this for people who are interested (have a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) machine that doesn't boot) is:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30)  - enable PM_DEBUG, and PM_TRACE
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32)  - use a script like this::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) 	#!/bin/sh
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) 	sync
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) 	echo 1 > /sys/power/pm_trace
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) 	echo mem > /sys/power/state
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39)    to suspend
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41)  - if it doesn't come back up (which is usually the problem), reboot by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42)    holding the power button down, and look at the dmesg output for things
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43)    like::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) 	Magic number: 4:156:725
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) 	hash matches drivers/base/power/resume.c:28
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) 	hash matches device 0000:01:00.0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49)    which means that the last trace event was just before trying to resume
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50)    device 0000:01:00.0. Then figure out what driver is controlling that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51)    device (lspci and /sys/devices/pci* is your friend), and see if you can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52)    fix it, disable it, or trace into its resume function.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54)    If no device matches the hash (or any matches appear to be false positives),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55)    the culprit may be a device from a loadable kernel module that is not loaded
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56)    until after the hash is checked. You can check the hash against the current
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57)    devices again after more modules are loaded using sysfs::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) 	cat /sys/power/pm_trace_dev_match
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) For example, the above happens to be the VGA device on my EVO, which I
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) used to run with "radeonfb" (it's an ATI Radeon mobility). It turns out
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) that "radeonfb" simply cannot resume that device - it tries to set the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) PLL's, and it just _hangs_. Using the regular VGA console and letting X
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) resume it instead works fine.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) NOTE
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) ====
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) pm_trace uses the system's Real Time Clock (RTC) to save the magic number.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) Reason for this is that the RTC is the only reliably available piece of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) hardware during resume operations where a value can be set that will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) survive a reboot.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) pm_trace is not compatible with asynchronous suspend, so it turns
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) asynchronous suspend off (which may work around timing or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) ordering-sensitive bugs).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) Consequence is that after a resume (even if it is successful) your system
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) clock will have a value corresponding to the magic number instead of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) correct date/time! It is therefore advisable to use a program like ntp-date
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) or rdate to reset the correct date/time from an external time source when
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) using this trace option.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) As the clock keeps ticking it is also essential that the reboot is done
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) quickly after the resume failure. The trace option does not use the seconds
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) or the low order bits of the minutes of the RTC, but a too long delay will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) corrupt the magic value.