2009-04-03 11:11:41 Power management can't wakeup
Adam Dershowitz (UNITED STATES)
Message: 72123
I am using the ez-kit 527, and was trying to do some stuff with power management. I read:
http://docs.blackfin.uclinux.org/doku.php?id=power_management_support
and followed the instructions. For the EZKit I changed the GPIO number to 16 for the first button. I can get it to go to sleep. But if I can't get it to wake up.
I also enabled rtcwake, and after the set time, instead of waking up, the board reboots. While, if I just enble gpio:
/sys/devices/platform/gpio-keys.0/power> echo enabled > wakeup
and then put it to sleep
echo standby > /sys/power/state I can't get it to wakeup at all. The only thing I can do that that point is hit the reset button to cause a reboot.
Any suggestions would be appreciated.
Thanks,
--Adam
QuoteReplyEditDelete
2009-04-06 00:37:18 Re: Power management can't wakeup
Mike Frysinger (UNITED STATES)
Message: 72194
what version of software exactly are you using (u-boot and kernel) ? suspend support was not in the last (2008R1.5) release.
QuoteReplyEditDelete
2009-04-06 11:35:53 Re: Power management can't wakeup
Adam Dershowitz (UNITED STATES)
Message: 72264
I am using trunk-svn-7715 version of the kernel. But I am still using 2008R1.5 of u-boot. I figured that once u-boot loaded the kernel that the version really didn't matter, so I had not bothered to update it.
It sounds, from your question, like this mismatch could cause a problem. I will upgrade u-boot and see what happens.
Thanks,
QuoteReplyEditDelete
2009-04-06 13:26:00 Re: Power management can't wakeup
Adam Dershowitz (UNITED STATES)
Message: 72271
I built uboot 2009-01, and booted that (i didn't flash, just booted from memory) and then if I boot linux (trunk-SVN-7715) all seems fine....but no luck with power management.
Again, if I use rtcwake, it seems to go to sleep, and then wakeup, but reboots soon after the wakeup:
root:/> rtcwake -s 5
wakeup from "standby" at Wed Aug 18 20:34:16 2032
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.00 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
PHY: 0:03 - Link is Down
Restarting tasks ... done.
rto/: >PHY: 0:03 - Link is Up - 100/Full
(5-10 second delay then boots to U-boot)
And if I do it instead to enable gpio wakup, it again seems to go to sleep, but when I push a button to wakeup, I get a kernel panic on wakeup:
root:/> cd /sys/devices/platform/gpio-keys.0/power
root:/sys/devices/platform/gpio-keys.0/power> echo enabled > wakeup
root:/sys/devices/platform/gpio-keys.0/power> echo standby > /sys/power/state
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.00 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
Restarting tasks ... done.
oo:ts/syd/vecisep/alftro/mpgoik-ye.s/0opew>rNULL pointer access
Kernel OOPS in progress
Deferred Exception context
No Valid process in current context
return address: [0x000d0aec]; contents of:
0x000d0ac0: 001e 1803 9138 0040 0c02 102a 0c03 326b
0x000d0ad0: 1821 0000 0000 0000 af2a aeec acab b32f
0x000d0ae0: 0c42 1b9d 0000 0000 0000 0031 [a050] 67f8
0x000d0af0: b050 60f8 0801 a052 1803 9138 0040 0c02
SEQUENCER STATUS: Not tainted
SEQSTAT: 00060027 IPEND: c030 SYSCFG: 0006
EXCAUSE : 0x27
interrupts disabled
physical IVG5 asserted : <0xffa00acc> { _evt_ivhw + 0x0 }
physical IVG14 asserted : <0xffa008dc> { _evt14_softirq + 0x0 }
physical IVG15 asserted : <0xffa00c1c> { _evt_system_call + 0x0 }
logical irq 6 mapped : <0xffa00308> { _timer_interrupt + 0x0 }
logical irq 21 mapped : <0x000bb668> { _bfin_rtc_interrupt + 0x0 }
logical irq 31 mapped : <0x000a572c> { _bfin_serial_dma_rx_int + 0x0 }
logical irq 32 mapped : <0x000a5a2c> { _bfin_serial_dma_tx_int + 0x0 }
logical irq 35 mapped : <0x000ae5b8> { _bfin_mac_interrupt + 0x0 }
logical irq 87 mapped : <0x000b9ad0> { _gpio_keys_isr + 0x0 }
RETE: <0x00000000> { _do_one_initcall + 0xfffff000 }
RETN: <0x00191e10> /* kernel dynamic memory */
RETX: <0x00000480> /* Maybe fixed code section */
RETS: <0x000dc95e> { _dst_rcu_free + 0x2a }
PC : <0x000d0aec> { _dst_destroy + 0xe4 }
DCPLB_FAULT_ADDR: <0x00000004> /* Maybe null pointer? */
ICPLB_FAULT_ADDR: <0x000d0aec> { _dst_destroy + 0xe4 }
PROCESSOR STATE:
R0 : 03eeec60 R1 : 0000ffff R2 : 0000000a R3 : 001767c8
R4 : 0000000a R5 : 00000100 R6 : 00000008 R7 : 00000000
P0 : 00d37c00 P1 : 03eeec60 P2 : 00000001 P3 : 00000000
P4 : 00000000 P5 : 03eeec60 FP : 0017e910 SP : 00191d34
LB0: 0009b9fc LT0: 0009b9a4 LC0: 00000000
LB1: 0000de2e LT1: 0000de18 LC1: 00000000
B0 : 00000000 L0 : 00000000 M0 : 00000020 I0 : ffffffff
B1 : 00000000 L1 : 00000000 M1 : 00000000 I1 : ffffffff
B2 : 03eebdcc L2 : 00000000 M2 : 00000000 I2 : ffffffff
B3 : 00000000 L3 : 00000000 M3 : 00000000 I3 : ffffffff
A0.w: 003d08c9 A0.x: 00000000 A1.w: 00000906 A1.x: 00000000
USP : 00192000 ASTAT: 02003005
Hardware Trace:
0 Target : <0x00004a40> { _trap_c + 0x0 }
Source : <0xffa0058a> { _exception_to_level5 + 0x9e } CALL pcrel
1 Target : <0xffa004ec> { _exception_to_level5 + 0x0 }
Source : <0xffa003be> { _bfin_return_from_exception + 0x6 } RTX
2 Target : <0xffa003b8> { _bfin_return_from_exception + 0x0 }
Source : <0xffa00446> { _ex_trap_c + 0x66 } JUMP.S
3 Target : <0xffa003e0> { _ex_trap_c + 0x0 }
Source : <0xffa00616> { _trap + 0x2a } JUMP (P4)
4 Target : <0xffa005ec> { _trap + 0x0 }
Source : <0x000d0aea> { _dst_destroy + 0xe2 } 0x0031
5 Target : <0x000d0ad8> { _dst_destroy + 0xd0 }
Source : <0x000d0a1a> { _dst_destroy + 0x12 } JUMP.S
6 Target : <0x000d0a08> { _dst_destroy + 0x0 }
Source : <0x000dc95a> { _dst_rcu_free + 0x26 } CALL pcrel
7 Target : <0x000dc958> { _dst_rcu_free + 0x24 }
Source : <0x000dc94c> { _dst_rcu_free + 0x18 } IF CC JUMP
8 Target : <0x000dc946> { _dst_rcu_free + 0x12 }
Source : <0x000dc93e> { _dst_rcu_free + 0xa } IF !CC JUMP
9 Target : <0x000dc934> { _dst_rcu_free + 0x0 }
Source : <0x0002e760> { ___rcu_process_callbacks + 0xd0 } CALL (P2)
10 Target : <0x0002e74e> { ___rcu_process_callbacks + 0xbe }
Source : <0x0002e766> { ___rcu_process_callbacks + 0xd6 } IF CC JUMP
11 Target : <0x0002e762> { ___rcu_process_callbacks + 0xd2 }
Source : <0x000dc944> { _dst_rcu_free + 0x10 } RTS
12 Target : <0x000dc940> { _dst_rcu_free + 0xc }
Source : <0x000dc962> { _dst_rcu_free + 0x2e } IF !CC JUMP
13 Target : <0x000dc95e> { _dst_rcu_free + 0x2a }
Source : <0x000d0b1c> { _dst_destroy + 0x114 } RTS
14 Target : <0x000d0b12> { _dst_destroy + 0x10a }
Source : <0x000d0aa6> { _dst_destroy + 0x9e } IF !CC JUMP
15 Target : <0x000d0aa4> { _dst_destroy + 0x9c }
Source : <0x0003c262> { _kmem_cache_free + 0x36 } RTS
Kernel Stack
Stack info:
SP: [0x00191f54] <0x00191f54> /* kernel dynamic memory */
Memory from 0x00191f50 to 00192000
00191f50: 00000020 [03eebe18] 00186cec 00000040 00000300 00192000 0017e910 ffa00248
00191f70: 00190000 0016d5b4 0017e910 00190000 ffa00810 0016cd14 00000000 00000000
00191f90: 00000000 00000001 00000002 0000ffff 0000ffff 0000ffff ffa00810 00000006
00191fb0: 0016cd14 00000000 00000000 001926c6 00176adc 001aa4e4 0016cd20 0016cd14
00191fd0: 00000000 001aa4e4 0016ca64 00000022 00192098 001acf34 00192000 0019f5d4
00191ff0: 00000000 00000000 00000000 ffb00000 b9b8b934
Return addresses in stack:
Modules linked in:
Kernel panic - not syncing: Kernel exception
QuoteReplyEditDelete
2009-04-06 18:38:41 Re: Power management can't wakeup
Mike Frysinger (UNITED STATES)
Message: 72280
you should use 2008.10 as that is the next version we plan on using in our next release, but that shouldnt cause a problem here. 2008R1.5 certainly would not support waking up.
in your rtcwake test, if u-boot starts up rather than the kernel, run `md.b 0` and post the output.
i seem to recall there being some problems with the bf527-ezkit board in that the memory pins were not wired perfectly and so it could lead to random memory corruption during suspend/resume. not anything software can do about that ...
QuoteReplyEditDelete
2009-04-06 19:27:02 Re: Power management can't wakeup
Adam Dershowitz (UNITED STATES)
Message: 72282
This is strange, but I just tried it again, and now I can't recreate the problem. Now it seems to be working fine.
Perhaps it needed a full reset, which happened in after the old test. But all seems good now.
QuoteReplyEditDelete
2009-04-14 10:45:28 Re: Power management can't wakeup
Michael Hennerich (GERMANY)
Message: 72641 Are you still having problems with suspend standby?
-Michael
QuoteReplyEditDelete
2009-04-14 13:24:34 Re: Power management can't wakeup
Adam Dershowitz (UNITED STATES)
Message: 72645
No.
Now it seems to be working fine. I did upgrade to a newer u-boot. At first it didn't work, but now it is working fine. I don't understand why I continued to have problems after the initial upgrade, but for now it is fine. It might be that it needed a full hardware reset after I went to the newer u-boot?
Anyway, problem solved.
Thanks for the help.
--Adam