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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
