On 01/16/12 21:22, Scott Wood wrote:
On 01/13/2012 08:13 AM, Norbert van Bolhuis wrote:
I dumped SIPNR/SIMSR and uart IIR/EIR (since console triggers wake-up)
but they do not change just before entering standby (via
mpc6xx_enter_standby
which omits setting MSR_POW). uart IRQ is always enabled, unmasked and
not pending.

I tried to log to physical memory to see what's going on whenever the
board fails to wake-up.
(I can examine physical memory after CPU is stuck in sleep, by connecting
  a JTAG debugger, start u-boot and stop after DDR2 SDRAM ctrl is
  re-configured)

Are you sure this isn't going to disturb anything?  Why does U-Boot need
to be involved, and the SDRAM reconfigured?



If CPU is stuck in sleep, JTAG will send HRESET or SRESET (i'm nor sure
which one it is) and u-boot is needed to reconfigure CPU and DDR2 SDRAM ctrl.
SDRAM contents (for physical memory "unknown" to u-boot and linux) seems to
survive such a soft-reset.


It looks like an interupt does occur, but do_IRQ seems to be stuck
in ppc_md.get_irq=ipic_get_irq where it reads SIVCR.

Stuck as in the load never completes, or as in ipic_get_irq() gets
called repeatedly?  If the latter, what value is it reading out?  Is the
interrupt pending in SIPNR at this point?



I think I was wrong. I enabled tracing do_IRQ just a little bit too soon
(in suspend_enter). The interrupt I saw was probably one that occured
just before CPU entered sleep (mpc6xx_enter_standby).

Right now I see no external interrupt happening, so that brings us back
where we were before: I'm not getting an interrupt regardless of low-power 
state.
So now my main question is: how can JTAG and/or any other external signal
cause this ?

Another weird thing I noticed is that whenever I dump CPU memmap
(which starts at 0xe0000000) under linux it always crashes with a "check stop"
when it is displaying somewhere at 0xe0000800-0xe0001000
If I connect our JTAG debugger it never crashes and dumping CPU memmap
always works.


---
NvBolhuis
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Reply via email to