Cannot wake-up from standby with MPC8313

[Norbert van Bolhuis]

On 01/17/12 23:09, Scott Wood wrote:

...

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


Because CPU is stuck in sleep and I use the CPU to dump the physical memory
(which contains the log entries made just before CPU got stuck).


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


Probably not, but at least the physical memory contents seems to survive
the 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 ?
>
> 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
>
>

Yes this is it!
You mentioned mpc8313erdb bug before, I guess you had to mention it twice before
I looked at mpc8313erdb bug description.

The mpc8313erdb bug is described as follows:

3.5 Power management control (PMC) registers cannot be
accessed?
The PMC registers range from IMMR + 0x0B00 to IMMR + 0x0BFF. When this
area is accessed in u-boot,
the RDB hangs up. It appears that the PMC block is related to the JTAG
interface; TRST must not be pulled
down for normal operation of the PMC block. Possible workarounds are as
follows:
• Attach a debugger to drive TRST high during normal operation.
• Remove the pull-down resistor (R37) for TRST. Although this tested on
some RDBs without any
problem, it violates the hardware specification. If it does not work on
your RDB, use another workaround.


I guess this is an MPC8313 problem rather than an MPC8313E-RDB problem ?
and I would expect it to be mentioned in MPC8313E Errata (which isn't the
case).

Anyway, thanks a lot for all help!

---
NvBolhuis