On 10/31/2012 05:45:00 PM, McClintock Matthew-B29882 wrote:
On Wed, Oct 31, 2012 at 5:43 PM, Matthew McClintock
<[email protected]> wrote:
> On Wed, Oct 31, 2012 at 5:08 PM, Scott Wood
<[email protected]> 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
_______________________________________________
U-Boot mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot
