public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: "Woodruff, Richard" <r-woodruff2@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"Shilimkar, Santosh" <santosh.shilimkar@ti.com>
Subject: Re: State of LDP3430 platform
Date: Mon, 17 Jan 2011 09:34:54 -0800	[thread overview]
Message-ID: <20110117173454.GX4957@atomide.com> (raw)
In-Reply-To: <13B9B4C6EF24D648824FF11BE896716203EAE6F3AA@dlee02.ent.ti.com>

* Woodruff, Richard <r-woodruff2@ti.com> [110115 15:48]:
> 
> > From: Tony Lindgren [mailto:tony@atomide.com]
> > Sent: Friday, January 14, 2011 6:03 PM
> 
> > I've been seeing this on my omap4 panda. While debugging it, I left
> > u-boot console only running for a few minutes to see if that stays up.
> > It did.. And after doing that somehow now my panda boots all the way
> > and stays up. Weird.
> 
> That is a bit weird.  U-boot doesn't do much of anything but spin waiting for characters on serial.  The watchdog normally isn't used.
> 
> Thinking back I have experienced goofiness along these lines before.  This had to do with some bad timer initial state assumptions.  The timer's count values and states entering the kernel have caused a trip up.  I had fixed some of these years back.  Its possible some could have snuck back with all the recoding.  Many times the simple have some unanticipated twist.
> 
> The watchdog is something which the old kernel used to fall on also.  There were a couple simple trip ups:
>         -1- people forgot to turn clock on all together
>         -2- next, it was touched before clock frame work was initialized
>         -1+2- some code only 'wrote' to watchdog registers.  When memory attribute is device, generally the imprecise abort is ignored by the arm.  But some times weirdness slipped in around memory weak memory attribute mishandling.
> 
> Sounds like a fun bug/puzzle which good ole Lauterbach would help in.

This happened for a few days both with 2.6.37 and current mainline
kernel. After I started debugging it went away with no changes to
anything.. So can't debug any further at this point unfortunately.

Regards,

Tony

  reply	other threads:[~2011-01-17 17:35 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-06 12:55 State of LDP3430 platform Russell King - ARM Linux
2010-12-06 15:59 ` Tony Lindgren
2010-12-06 17:22   ` Russell King - ARM Linux
2010-12-06 18:02     ` Tony Lindgren
2010-12-06 18:19 ` Tony Lindgren
2010-12-06 18:27   ` Paul Walmsley
2010-12-07  8:37     ` Russell King - ARM Linux
2010-12-08  0:50       ` Paul Walmsley
2010-12-08  3:40         ` Paul Walmsley
2011-01-15  0:03           ` Tony Lindgren
2011-01-15 19:38             ` Paul Walmsley
2011-01-15 23:37               ` Russell King - ARM Linux
2011-01-16  0:04                 ` Russell King - ARM Linux
2011-01-16  0:05                 ` Woodruff, Richard
2011-01-16  0:30                   ` Russell King - ARM Linux
2011-01-16  1:09                   ` Paul Walmsley
2011-01-16  4:32                 ` Paul Walmsley
2011-01-16 15:08                   ` Thomas Weber
2011-01-18 19:36                     ` Paul Walmsley
2011-01-18 22:26                       ` [PATCH] omap1: Fix sched_clock for the MPU timer (Re: State of LDP3430 platform) Tony Lindgren
2011-01-18 22:35                         ` [PATCH] omap1: Fix booting for 15xx and 730 with omap1_defconfig " Tony Lindgren
2011-01-18 23:21                           ` Tony Lindgren
2011-01-19 18:43                             ` [PATCH] omap1: Fix sched_clock implementation when both MPU timer and 32K timer are used " Tony Lindgren
2011-01-19 18:44                         ` [PATCH] omap1: Fix sched_clock for the MPU timer " Tony Lindgren
2011-01-19 13:43                       ` State of LDP3430 platform Jarkko Nikula
2011-01-18  1:25                   ` Tony Lindgren
2011-01-18 19:24                     ` Paul Walmsley
2011-01-15 23:47             ` Woodruff, Richard
2011-01-17 17:34               ` Tony Lindgren [this message]
2011-01-17 17:44                 ` Woodruff, Richard
2011-02-12 16:02 ` Russell King - ARM Linux
2011-02-12 16:10   ` Russell King - ARM Linux
2011-02-23 22:50     ` Tony Lindgren
2011-02-23 23:22       ` Woodruff, Richard
2011-02-24  7:08         ` Rajendra Nayak
2011-02-24 13:07           ` Rajendra Nayak
2011-02-24  8:21       ` Janorkar, Mayuresh
2011-02-24  8:47         ` Russell King - ARM Linux

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=20110117173454.GX4957@atomide.com \
    --to=tony@atomide.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=paul@pwsan.com \
    --cc=r-woodruff2@ti.com \
    --cc=santosh.shilimkar@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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