Cannot wake-up from standby with MPC8313

[Scott Wood]

On 01/17/2012 10:56 AM, Norbert van Bolhuis wrote:
> 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.

Why is a reset needed in order to examine physical memory?

> SDRAM contents (for physical memory "unknown" to u-boot and linux) seems to
> survive such a soft-reset.

And all register and device state is as Linux left it?

>>> 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 ?

I can't help you with the hardware side of it, other than to say that it
sounds similar to an issue we had on early revs of mpc8313erdb.  Could
you make sure that TRST (JTAG Test Reset) is not being asserted except
while PORESET is asserted?

If that's not it, I'm wondering what the relevant difference is on the
software side to differentiate the case where you go through all the
motions but don't set MSR[POW] from the case where you don't try to
suspend at all (just take the interrupt during normal execution).  Are
you sure that you're making it to mpc6xx_enter_standby, and that it's
not hanging on a PMC register access?

> 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.

Is it 0xe0000bXX?  A hang when accessing the PMC registers is what I saw
with the mpc8313erdb bug.

-Scott