Current State of Power Management in Linux 4.x-ti Kernels for BeagleBone Black

[darren....@gmail.com]

Should power management functions (mem/standby) be working with 4.x TI kernels on the BeagleBone Black for at least some subset of hardware versions? Or was full support intentionally disabled due to hardware related issues?

I've been using 3.14 TI kernels with the rtcwake command (both mem and standby work), but cannot find anything that works on the same hardware with 4.x TI kernels after looking at wkup_m3 and rtc-omap drivers.

[Robert Nelson]

On Tue, May 3, 2016 at 8:10 PM, <darren....@gmail.com> wrote:

Should power management functions (mem/standby) be working with 4.x TI kernels on the BeagleBone Black for at least some subset of hardware versions? Or was full support intentionally disabled due to hardware related issues?

I've been using 3.14 TI kernels with the rtcwake command (both mem and standby work), but cannot find anything that works on the same hardware with 4.x TI kernels after looking at wkup_m3 and rtc-omap drivers.

v4.1.x-ti is the best, but just tested v4.4.x-ti this morning: 

at idle:

  current CPU frequency is 300 MHz (asserted by call to hardware).

  cpufreq stats: 300 MHz:60.64%, 600 MHz:2.75%, 800 MHz:0.00%, 1000 MHz:36.60%  (14)

root@beaglebone:~# uname -r

4.4.8-ti-r22

5v @ 0.15~0.18 Amps on my jumpy power supply...

echo mem > /sys/power/state

5v @ 0.05 Amps

bbb: rev a5a, just a ftdi serial cape attached.

Regards,

--

Robert Nelson
https://rcn-ee.com/

[William Hermans]

root@beaglebone:/home/william# echo mem > /sys/power/state
bash: echo: write error: Invalid argument
root@beaglebone:/home/william# uname -r
4.1.22-ti-rt-r59

Replacing "mem", with "disk" pretends to work, but it does not.

william@beaglebone:~$ time sudo rtcwake -m disk -s 60 && ls
rtcwake: wakeup from "disk" using /dev/rtc0 at Wed May  4 02:52:15 2016

william@eee-pc:~$ sudo screen /dev/ttyUSB0 115200

( serial debug )

[  223.71] Kernel pan

However, /dev/rtc0 *does* work as a rtc timer aside from sleep.

william@beaglebone:~$ zcat /proc/config.gz | grep CONFIG_HOTPLUG_CPU
CONFIG_HOTPLUG_CPU=y

Ok so this is really strange, this being disabled is supposed to be *the* reason for write failure to "mem".

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYijfoUf3rnTAJ-WLX9gQGKQ68Jw-6-ub%2BU3OXaaBRVBBw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Robert Nelson]

On Tue, May 3, 2016 at 9:59 PM, William Hermans <yyr...@gmail.com> wrote:

root@beaglebone:/home/william# echo mem > /sys/power/state
bash: echo: write error: Invalid argument
root@beaglebone:/home/william# uname -r
4.1.22-ti-rt-r59

Replacing "mem", with "disk" pretends to work, but it does not.

Might be another rt bug? ;)

Regards,

[William Hermans]

Robert, did you test "mem" on an rt kernel or regular ?

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYhVzANWEAg%2BNCDHyT9ESTMGiqLSGaQEPTWMiz-LH-or5Q%40mail.gmail.com.

[William Hermans]

Ah, ok my bad i missed it. You used a 4.4 regular ( non rt ) kernel.

[William Hermans]

Yeah I don't know . . . something seems to be terribly broken.
william@beaglebone:~$ uname -r
4.1.22-ti-r59
william@beaglebone:~$ sudo su

root@beaglebone:/home/william# echo mem > /sys/power/state
bash: echo: write error: Invalid argument

Next up, I'm going ot attempt to get it working with the exact same kernel you use Robert.

[William Hermans]

william@beaglebone:~$ uname -r
4.4.8-ti-r22

william@beaglebone:~$ sudo su
root@beaglebone:/home/william# echo mem > /sys/power/state
bash: echo: write error: Invalid argument

Not sure if this is helpful.
root@beaglebone:/home/william# lsmod
Module                  Size  Used by
bnep                   13053  2
rfcomm                 53777  0
bluetooth             409531  10 bnep,rfcomm
rfkill                 18154  2 bluetooth
nfsd                  255636  2

The board is an Element14 RevC. I do have a cicuitco A5A, but I really do not want to mess with it just now . . . Robert would you like me to provide any further  information before I nuke this image ?

[William Hermans]

So . . .

ioctl(3, RTC_WIE_ON or RTC_WKALM_SET, {enabled=1, pending=0, {tm_sec=56, tm_min=20, tm_hour=5, tm_mday=4, tm_mon=4, tm$
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f0b000
write(1, "rtcwake: wakeup from \"mem\" using"..., 71) = 71
nanosleep({0, 10000000}, NULL)          = 0
sync()                                  = 0
open("/sys/power/state", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f0a000
write(4, "mem\n", 4<EOF>

rtcwake never finishes writing to /sys/power/state, which mean the file is never closed which means I bet the contents are not "mem".

william@beaglebone:~$ cat /sys/power/state
freeze standby mem disk

Uh yeah, that looks borked . . .my first guess, this never gets changed, then rtcwake sees "freeze" and proceeds no further. Thus we're stuck in la la land while the board sleeps forever.

Here is what I think I've noticed so far. Right after the board suspends to memory, I press the reset button on the beaglebone, and nothing happens. But after one minute, the reset button seems to work fine. Maybe I was not pressing the button just right, but I attempted several times before finally the board went into reset.

Darren, do you think you can get an strace of rtcwake from your 3.14.x system ? If you can, then we should be able to compare the differences and probably figure out how to fix this mess. Just remember to use the -o(oh) option with strace to sent stdout to a file.

root@beaglebone:/home/debian# strace -o ./test.txt rtcwake -m mem -s 60

is how I've been running strace .  . .

[William Hermans]

root@eee-pc:/home/william# tail test.txt

sync()                                  = 0
open("/sys/power/state", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0

mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb748f000
write(4, "mem\n", 4)                    = 4
close(4)                                = 0
munmap(0xb748f000, 4096)                = 0
ioctl(3, PHN_GET_REGS or RTC_AIE_OFF, 0) = 0
close(3)                                = 0
exit_group(0)                           = ?

So this is a tail off an strace on an x86 wheezy install I've had for a while.
root@eee-pc:/home/william# cat /sys/power/state
mem disk

As we can see here, the power states are different. However, since this is an x86 system, we have a "proper" acpi setup.
root@eee-pc:/home/william# cat /proc/acpi/wakeup
Device  S-state   Status   Sysfs node
POP4      S4    *disabled  pci:0000:00:1c.0
POP5      S4    *disabled  pci:0000:00:1c.1
USB0      S3    *enabled   pci:0000:00:1d.0
USB1      S3    *enabled   pci:0000:00:1d.1
USB2      S3    *enabled   pci:0000:00:1d.2
EUSB      S3    *enabled   pci:0000:00:1d.7

. . . and I'm not sure how we "fix" this on an ARM system, which pretends to have an ACPI capable BIOS.

[darren....@gmail.com]

I have 2 boards that I've been testing on that give the same results. One is a A5C 2 GB board (?) and the other is a 0C0 4 GB board (Element14). I'm not using any capes, just the bare board.

I've been comparing 3.14 and 4.x code, but have not found any key differences other than code moving around from refactoring. I've tried looking at device tree stuff also, but I don't have the hardware background to fully understand most of that.

In addition to trying rtcwake, I've also tried "echo mem > /sys/power/state" after setting a wakealarm through /sys and also trying to use the serial console as wakeup sources... I get the same frozen system with 4.x TI kernels. BUT, the system does respond to pushing the reset button to reboot from the "frozen" state.

/sys/class/rtc/rtc0/device/power/wakeup <-- 3.14 is enabled

/sys/class/rtc/rtc0/device/power/wakeup <-- 4.x is enabled

When trying a mem sleep on 4.x kernels, user LED's 1 and 3 remain lit in the "frozen" state

strace results for rtcwake on 3.14 TI kernel...

root@beaglebone:~# tail test.txt

sync()                                  = 0

open("/sys/power/state", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 4

fstat64(4, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0

mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f8c000

write(4, "mem\n", 4)                    = 4

close(4)                                = 0

munmap(0xb6f8c000, 4096)                = 0

[William Hermans]

Might be another rt bug? ;)

Regards,

According to Documentation/power/states.txt, "disk" suspends to swap, which we do not have . . .

I'm convinced if I can somehow change /sys/power/state to just "mem", without the system immediately going into suspend

. That I should make progress.

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/b182222c-e834-46bd-8acf-f3058f818285%40googlegroups.com.

[William Hermans]

Anyway, I've been in pitbull mode on this for too long. I've got my own things to do, and I can't spend time screwing around with this for now.

Two things I feel need further investigation.

• First, changing /sys/power/state default value to "mem" only. This may fix things. but I'm not sure.
• Second, I did a little reading about debugging power states, then did the minimalist test that can be done( freezer). The board still hung, and in fact I had to pull the power to get it out of suspend.