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,
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”.
Might be another rt bug? 
Regards,
Robert, did you test “mem” on an rt kernel or regular ?
Ah, ok my bad i missed it. You used a 4.4 regular ( non rt ) kernel.
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@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 ?
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****
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 . . .
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.
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
ioctl(3, PHN_GET_REGS or RTC_AIE_OFF, 0) = 0
close(3) = 0
exit_group(0) = ?
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.
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.
