[U-Boot] [PATCH v2 03/22] powerpc/mpc85xx: move debug tlb entry after TLB is in known state

Scott Wood scottwood at freescale.com
Wed Oct 31 23:51:09 CET 2012


On 10/31/2012 05:45:00 PM, McClintock Matthew-B29882 wrote:
> On Wed, Oct 31, 2012 at 5:43 PM, Matthew McClintock  
> <msm at freescale.com> wrote:
> > On Wed, Oct 31, 2012 at 5:08 PM, Scott Wood  
> <scottwood at freescale.com> wrote:
> >> On 10/31/2012 01:17:31 AM, Prabhakar Kushwaha wrote:
> >>>
> >>> On 10/31/2012 02:37 AM, Scott Wood wrote:
> >>>>
> >>>> On 10/30/2012 04:26:16 AM, Prabhakar Kushwaha wrote:
> >>>> I'd rather not see this split this up.  This file is too much of  
> a
> >>>> complicated ifdef mess already.
> >>>>
> >>>> The window during which you won't be able to use breakpoints is  
> not that
> >>>> large.
> >>>> There are other debugging techniques that can be used.
> >>>
> >>>
> >>> Can you please share the other techniques. It will help us in  
> future.
> >>
> >>
> >> For debugging early boot hangs I usually put a branch-to-self  
> somewhere in
> >> the sequence, and use CCS to see if we're spinning there or if we  
> went off
> >> to some exception or other badness.  Then I do a binary search,  
> moving the
> >> branch to self around, to determine where things went wrong.
> >
> > LR can be handy to look at too to see what the calling function /  
> branch was.
> 
> And to add more... It's even more helpful when you did not instrument
> your code with a branch to self yet, since sometimes you can find out
> a good starting point for placing the branch to self in the first
> place.

Sure, what I wrote was meant for situations where the register dump  
after you get in a bad state is not very useful, as was often the case  
when debugging this code (infrequent use of LR, stuck in an exception  
handler that repeatedly raises itself, obliterating the original  
SRR0).  Sometimes I've seen the chip get stuck so hard that you can't  
even get register info out.

-Scott


More information about the U-Boot mailing list