Kernel Debugging on the DBAu1500

Kernel Debugging on the DBAu1500

[Jeff Baitis]

Hi all:

I've been trying to get a kernel debugger running on my AMD DBAu1500.  It boots
up over a serial console. I enable "Remote GDB kernel debugging," and "Console
output to GDB."

Here's what I tell YAMON to do:

    go . gdb gdbttyS=0 gdbbaud=115200

And on my x86 machine, I:

    stty ispeed 115200 ospeed 115200 < /dev/ttyS1

    /opt/hardhat/devkit/mips/fp_le/bin/mips_fp_le-gdb vmlinux
    (gdb) target remote /dev/ttyS1 

GDB seems not to communicate. Here's what it says:

    Ignoring packet error, continuing...
    Ignoring packet error, continuing...
    Ignoring packet error, continuing...
    Couldn't establish connection to remote target
    Malformed response to offset query, timeout

Suggestions?

Thanks in advance!

-Jeff

-- 
         Jeffrey Baitis - Associate Software Engineer

                    Evolution Robotics, Inc.
                     130 West Union Street
                       Pasadena CA 91103

 tel: 626.535.2776  |  fax: 626.535.2777  |  baitisj@evolution.com 

Re: Kernel Debugging on the DBAu1500

[Juan Quintela]

>>>>> "jeff" == Jeff Baitis <baitisj@evolution.com> writes:

Hi
        perhaps don't help, but try using 57600 bauds.  Some
        chipsets don't like 115200 bauds.

I have never used gdb on MIPS, but at least on intel, you need run a
program in your MIPS board (in intel it is gdbstart called).

Later, Juan.

jeff> Hi all:
jeff> I've been trying to get a kernel debugger running on my AMD DBAu1500.  It boots
jeff> up over a serial console. I enable "Remote GDB kernel debugging," and "Console
jeff> output to GDB."

jeff> Here's what I tell YAMON to do:

jeff> go . gdb gdbttyS=0 gdbbaud=115200

jeff> And on my x86 machine, I:

jeff> stty ispeed 115200 ospeed 115200 < /dev/ttyS1

jeff> /opt/hardhat/devkit/mips/fp_le/bin/mips_fp_le-gdb vmlinux
jeff> (gdb) target remote /dev/ttyS1 

jeff> GDB seems not to communicate. Here's what it says:

jeff> Ignoring packet error, continuing...
jeff> Ignoring packet error, continuing...
jeff> Ignoring packet error, continuing...
jeff> Couldn't establish connection to remote target
jeff> Malformed response to offset query, timeout

jeff> Suggestions?

jeff> Thanks in advance!




-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

Re: Kernel Debugging on the DBAu1500

[Pete Popov]

Jeff,

Take a look at the board and remind me if the second serial port is
actually uart2, where the first is uart0. I think it might be. If that's
the case, arch/mips/au1000/common/dbg_io.c has this define if kgdb is
defined:

#define DEBUG_BASE  UART2_ADDR

That needs to get fixed. It would be better to parse the command line
for something like "kgdb=ttyS2,115200".

Pete

On Thu, 2003-03-06 at 18:53, Jeff Baitis wrote:
> Hi all:
> 
> I've been trying to get a kernel debugger running on my AMD DBAu1500.  It boots
> up over a serial console. I enable "Remote GDB kernel debugging," and "Console
> output to GDB."
> 
> Here's what I tell YAMON to do:
> 
>     go . gdb gdbttyS=0 gdbbaud=115200
> 
> And on my x86 machine, I:
> 
>     stty ispeed 115200 ospeed 115200 < /dev/ttyS1
> 
>     /opt/hardhat/devkit/mips/fp_le/bin/mips_fp_le-gdb vmlinux
>     (gdb) target remote /dev/ttyS1 
> 
> GDB seems not to communicate. Here's what it says:
> 
>     Ignoring packet error, continuing...
>     Ignoring packet error, continuing...
>     Ignoring packet error, continuing...
>     Couldn't establish connection to remote target
>     Malformed response to offset query, timeout
> 
> Suggestions?
> 
> Thanks in advance!
> 
> -Jeff

Re: Kernel Debugging on the DBAu1500

[Pete Popov]

On Fri, 2003-03-07 at 05:23, Pete Popov wrote:
> Jeff,
> 
> Take a look at the board and remind me if the second serial port is
> actually uart2, where the first is uart0. 

Sorry, I meant uart3, which would be a reason why the UART2_ADDR define
below wouldn't work.

Pete

> I think it might be. If that's
> the case, arch/mips/au1000/common/dbg_io.c has this define if kgdb is
> defined:
> 
> #define DEBUG_BASE  UART2_ADDR
> 
> That needs to get fixed. It would be better to parse the command line
> for something like "kgdb=ttyS2,115200".
> 
> Pete
> 
> On Thu, 2003-03-06 at 18:53, Jeff Baitis wrote:
> > Hi all:
> > 
> > I've been trying to get a kernel debugger running on my AMD DBAu1500.  It boots
> > up over a serial console. I enable "Remote GDB kernel debugging," and "Console
> > output to GDB."
> > 
> > Here's what I tell YAMON to do:
> > 
> >     go . gdb gdbttyS=0 gdbbaud=115200
> > 
> > And on my x86 machine, I:
> > 
> >     stty ispeed 115200 ospeed 115200 < /dev/ttyS1
> > 
> >     /opt/hardhat/devkit/mips/fp_le/bin/mips_fp_le-gdb vmlinux
> >     (gdb) target remote /dev/ttyS1 
> > 
> > GDB seems not to communicate. Here's what it says:
> > 
> >     Ignoring packet error, continuing...
> >     Ignoring packet error, continuing...
> >     Ignoring packet error, continuing...
> >     Couldn't establish connection to remote target
> >     Malformed response to offset query, timeout
> > 
> > Suggestions?
> > 
> > Thanks in advance!
> > 
> > -Jeff
> 
> 
> 

Re: Kernel Debugging on the DBAu1500

[Jeff Baitis]

Pete wrote wrote:
> > Take a look at the board and remind me if the second serial port is
> > actually uart2, where the first is uart0. 
Pete wrote:
> Sorry, I meant uart3, which would be a reason why the UART2_ADDR define
> below wouldn't work.

Hrm. The DBAu1500 seems to lock up when I execute:
    echo "please, no freeze" > /dev/ttyS2
I can't even get SysRq to work after that command.

/dev/ttyS3 works fine, though.

> > I think it might be. If that's
> > the case, arch/mips/au1000/common/dbg_io.c has this define if kgdb is
> > defined:
> > 
> > #define DEBUG_BASE  UART2_ADDR

I changed it to:
#define  DEBUG_BASE  UART3_ADDR

Debugging seems to work great now! Thanks!


-JB


-- 
         Jeffrey Baitis - Associate Software Engineer

                    Evolution Robotics, Inc.
                     130 West Union Street
                       Pasadena CA 91103

 tel: 626.535.2776  |  fax: 626.535.2777  |  baitisj@evolution.com 

Re: Kernel Debugging on the DBAu1500

[Pete Popov]

On Fri, 2003-03-07 at 12:36, Jeff Baitis wrote:
> Pete wrote wrote:
> > > Take a look at the board and remind me if the second serial port is
> > > actually uart2, where the first is uart0. 
> Pete wrote:
> > Sorry, I meant uart3, which would be a reason why the UART2_ADDR define
> > below wouldn't work.
> 
> Hrm. The DBAu1500 seems to lock up when I execute:
>     echo "please, no freeze" > /dev/ttyS2
> I can't even get SysRq to work after that command.

You're just a troublemaker ;) I'll take a look and fix it. I suspect I
know what the problem is.

> /dev/ttyS3 works fine, though.
> 
> > > I think it might be. If that's
> > > the case, arch/mips/au1000/common/dbg_io.c has this define if kgdb is
> > > defined:
> > > 
> > > #define DEBUG_BASE  UART2_ADDR
> 
> I changed it to:
> #define  DEBUG_BASE  UART3_ADDR
> 
> Debugging seems to work great now! Thanks!

No problem.

Pete

Re: Kernel Debugging on the DBAu1500

[Jeff Baitis]

Earlier I wrote:

> > Debugging seems to work great now! Thanks!

Well, not quite great. I've abandoned the old Monta Vista gdb-5.0 debugger
since it's been segfaulting.

I've tried building cross-debuggers from the current gdb release (5.3) and
from the March 3 CVS snapshot. Both lock up as soon as I 's'tep, just after
the GDB stub. (./configure --target=mipsel).

Perhaps someone could suggest a version of GDB that I should be using?

I also tried to disable CPU caching, but my kernel wouldn't boot.

Thanks again!

-Jeff


-- 
         Jeffrey Baitis - Associate Software Engineer

                    Evolution Robotics, Inc.
                     130 West Union Street
                       Pasadena CA 91103

 tel: 626.535.2776  |  fax: 626.535.2777  |  baitisj@evolution.com 

Re: Kernel Debugging on the DBAu1500

[Daniel Jacobowitz]

On Fri, Mar 07, 2003 at 04:27:33PM -0800, Jeff Baitis wrote:
> Earlier I wrote:
> 
> > > Debugging seems to work great now! Thanks!
> 
> Well, not quite great. I've abandoned the old Monta Vista gdb-5.0 debugger
> since it's been segfaulting.

Wow, that's from a pretty old product...

> I've tried building cross-debuggers from the current gdb release (5.3) and
> from the March 3 CVS snapshot. Both lock up as soon as I 's'tep, just after
> the GDB stub. (./configure --target=mipsel).
> 
> Perhaps someone could suggest a version of GDB that I should be using?

Those should both work correctly; they do here.  Try configuring it for
the right target (mipsel-linux) and seeing if that helps?  I'd be
surprised if it made a difference though.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

RE: Kernel Debugging on the DBAu1500

[Dhananjay R. Deshpande]

Hi,

Try 
(gdb) set remotebaud 115200

before 

(gdb) target remote /dev/ttyS1 


- Dhananjay

> -----Original Message-----
> From: Juan Quintela [mailto:quintela@mandrakesoft.com]
> Sent: Friday, March 07, 2003 5:33 PM
> To: baitisj@evolution.com
> Cc: linux-mips@linux-mips.org
> Subject: Re: Kernel Debugging on the DBAu1500
> 
> 
> >>>>> "jeff" == Jeff Baitis <baitisj@evolution.com> writes:
> 
> Hi
>         perhaps don't help, but try using 57600 bauds.  Some
>         chipsets don't like 115200 bauds.
> 
> I have never used gdb on MIPS, but at least on intel, you need run a
> program in your MIPS board (in intel it is gdbstart called).
> 
> Later, Juan.
> 
> jeff> Hi all:
> jeff> I've been trying to get a kernel debugger running on my 
> AMD DBAu1500.  It boots
> jeff> up over a serial console. I enable "Remote GDB kernel 
> debugging," and "Console
> jeff> output to GDB."
> 
> jeff> Here's what I tell YAMON to do:
> 
> jeff> go . gdb gdbttyS=0 gdbbaud=115200
> 
> jeff> And on my x86 machine, I:
> 
> jeff> stty ispeed 115200 ospeed 115200 < /dev/ttyS1
> 
> jeff> /opt/hardhat/devkit/mips/fp_le/bin/mips_fp_le-gdb vmlinux
> jeff> (gdb) target remote /dev/ttyS1 
> 
> jeff> GDB seems not to communicate. Here's what it says:
> 
> jeff> Ignoring packet error, continuing...
> jeff> Ignoring packet error, continuing...
> jeff> Ignoring packet error, continuing...
> jeff> Couldn't establish connection to remote target
> jeff> Malformed response to offset query, timeout
> 
> jeff> Suggestions?
> 
> jeff> Thanks in advance!
> 
> 
> 
> 
> -- 
> In theory, practice and theory are the same, but in practice they 
> are different -- Larry McVoy
> 
> 

RE: Kernel Debugging on the DBAu1500

[Dhananjay R. Deshpande]

Hi,

Try 
(gdb) set remotebaud 115200

before 

(gdb) target remote /dev/ttyS1 


- Dhananjay

> -----Original Message-----
> From: Juan Quintela [mailto:quintela@mandrakesoft.com]
> Sent: Friday, March 07, 2003 5:33 PM
> To: baitisj@evolution.com
> Cc: linux-mips@linux-mips.org
> Subject: Re: Kernel Debugging on the DBAu1500
> 
> 
> >>>>> "jeff" == Jeff Baitis <baitisj@evolution.com> writes:
> 
> Hi
>         perhaps don't help, but try using 57600 bauds.  Some
>         chipsets don't like 115200 bauds.
> 
> I have never used gdb on MIPS, but at least on intel, you need run a
> program in your MIPS board (in intel it is gdbstart called).
> 
> Later, Juan.
> 
> jeff> Hi all:
> jeff> I've been trying to get a kernel debugger running on my 
> AMD DBAu1500.  It boots
> jeff> up over a serial console. I enable "Remote GDB kernel 
> debugging," and "Console
> jeff> output to GDB."
> 
> jeff> Here's what I tell YAMON to do:
> 
> jeff> go . gdb gdbttyS=0 gdbbaud=115200
> 
> jeff> And on my x86 machine, I:
> 
> jeff> stty ispeed 115200 ospeed 115200 < /dev/ttyS1
> 
> jeff> /opt/hardhat/devkit/mips/fp_le/bin/mips_fp_le-gdb vmlinux
> jeff> (gdb) target remote /dev/ttyS1 
> 
> jeff> GDB seems not to communicate. Here's what it says:
> 
> jeff> Ignoring packet error, continuing...
> jeff> Ignoring packet error, continuing...
> jeff> Ignoring packet error, continuing...
> jeff> Couldn't establish connection to remote target
> jeff> Malformed response to offset query, timeout
> 
> jeff> Suggestions?
> 
> jeff> Thanks in advance!
> 
> 
> 
> 
> -- 
> In theory, practice and theory are the same, but in practice they 
> are different -- Larry McVoy
> 
>