Re: [ECOS] GDB frame

["David Lewin" <david dot lewin at europe-technologies dot com>]

Yes you are right, as Andrew Lunn said in a previous post :

 "Its the gdb stub trying to talk to gdb. Redboot has crashed and its
trying to tell gdb where its crashed. Use gdb with the redboot elf
image and it will tell you more about the crash."

And your are right again Redboot run on a specific Arm 
Chip.
But as I'm connected with a terminal to send
commands to redboot, if I connect to a JTAG to 
talk with GDB, Redboot is frozen and do not respond
any more. 

But on top of this, this could be because I changed the
flash driver and made a fis init.

Thanks for the gdb decoding ... it helps

----- Original Message ----- 
From: "Gary Thomas" <gary@mlbassoc.com>
To: "David Lewin" <david.lewin@europe-technologies.com>
Cc: <ecos-discuss@sources.redhat.com>
Sent: Wednesday, June 30, 2004 3:51 PM
Subject: Re: [ECOS] GDB frame


> On Wed, 2004-06-30 at 07:48, David Lewin wrote:
> > Does someone knows how to retrieve a human
> > readable string instead a gdb like one, on error
> > I always have an answer like this from redboot :
> > 
> > $T0a0f:00000801;0d:f8050060;#4b
> 
> Sadly, this is architecture specific.
> 
> My guess is that you're running on ARM.  IIRC, this says that
> register 15 (PC?) is at 0x01080000 and 13 (SP?) is 0x600005F8.
> (I might have those swapped).
> 
> Anyway, the best way to attack this is to disconnect minicom (or
> whatever you use) and then attach via GDB.  For example:
>   (gdb) tar rem /dev/ttyS0
>   (gdb) info reg
>   (gdb) bt
> 
> -- 
> Gary Thomas <gary@mlbassoc.com>
> MLB Associates

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss