From: Norbert van Bolhuis <nvbolhuis@aimvalley•nl>
To: Scott Wood <scottwood@freescale•com>
Cc: "linuxppc-dev@ozlabs•org" <linuxppc-dev@ozlabs•org>
Subject: Re: Cannot wake-up from standby with MPC8313
Date: Tue, 17 Jan 2012 17:56:28 +0100 [thread overview]
Message-ID: <4F15A83C.7020805@aimvalley.nl> (raw)
In-Reply-To: <4F1486F1.7000406@freescale.com>
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
next prev parent reply other threads:[~2012-01-17 16:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-04 16:19 Cannot wake-up from standby with MPC8313 Norbert van Bolhuis
2012-01-04 21:08 ` Scott Wood
2012-01-05 15:58 ` Norbert van Bolhuis
2012-01-05 18:22 ` Scott Wood
2012-01-06 13:53 ` Norbert van Bolhuis
2012-01-06 21:03 ` Scott Wood
2012-01-13 14:13 ` Norbert van Bolhuis
2012-01-16 20:22 ` Scott Wood
2012-01-17 16:56 ` Norbert van Bolhuis [this message]
2012-01-17 22:09 ` Scott Wood
2012-01-18 10:16 ` Norbert van Bolhuis
2012-01-20 20:05 ` Scott Wood
2012-01-23 10:08 ` ehodys
-- strict thread matches above, loose matches on Subject: below --
2012-01-23 9:34 nvbolhuis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F15A83C.7020805@aimvalley.nl \
--to=nvbolhuis@aimvalley$(echo .)nl \
--cc=linuxppc-dev@ozlabs$(echo .)org \
--cc=scottwood@freescale$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox