public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] GDB with redboot
@ 2001-01-31  3:57 Tong Chi Wa
  2001-01-31  9:26 ` Jonathan Larmour
  0 siblings, 1 reply; 2+ messages in thread
From: Tong Chi Wa @ 2001-01-31  3:57 UTC (permalink / raw)
  To: ecos-discuss

Hi,

  I'm working to get Redboot to work a SPARC based system
and so far I've been able to get the serial console and the
Ethernet chip to work.

  I'm now getting a problem in having GDB to work with the target
system over the Ethernet link. The host is able to make a 
connection with the target but is stucked when doing a memory
examine(x 0x0).

  What I observed:

1. The host GDB will get "remote packets too long" when
   connecting, over both serial and ethernet link. This should
   be from the register dump command.

2. On a serial link, the response time of the first memory dump
   is longer than the following memory dumps. Snooping on the
   serial link, I've found that there are two request packets
   sent from the host for the first memory dump. It looks like
   there is some kind of timeout mechanism on the host side.

3. On the ethernet link, host GDB will stuck in the first memory
   dump. I've checked that the target did respond to the 'm'
   GDB command and send out the response packet. The target
   still responds to ping packets so the target should not 
   miss any retry request packets from the host. Unlike the case
   with the serial link, there is only one request packet sent
   from the host.

  I'm not sure if this problem is on Redboot or GDB. Is there
something need to configured differently for GDB to work with
the eCos GDB stubs?

  My configuration:
    eCos cvs snapshot on 11/28/00
    insight 5.0 configured for sparclite-elf on a Win2k host

  Any advice on this?

Thanks.
cwtong


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [ECOS] GDB with redboot
  2001-01-31  3:57 [ECOS] GDB with redboot Tong Chi Wa
@ 2001-01-31  9:26 ` Jonathan Larmour
  0 siblings, 0 replies; 2+ messages in thread
From: Jonathan Larmour @ 2001-01-31  9:26 UTC (permalink / raw)
  To: Tong Chi Wa; +Cc: ecos-discuss

Tong Chi Wa wrote:
> 1. The host GDB will get "remote packets too long" when
>    connecting, over both serial and ethernet link. This should
>    be from the register dump command.
> 
> 2. On a serial link, the response time of the first memory dump
>    is longer than the following memory dumps. Snooping on the
>    serial link, I've found that there are two request packets
>    sent from the host for the first memory dump. It looks like
>    there is some kind of timeout mechanism on the host side.
> 
> 3. On the ethernet link, host GDB will stuck in the first memory
>    dump. I've checked that the target did respond to the 'm'
>    GDB command and send out the response packet. The target
>    still responds to ping packets so the target should not
>    miss any retry request packets from the host. Unlike the case
>    with the serial link, there is only one request packet sent
>    from the host.
> 
>   I'm not sure if this problem is on Redboot or GDB. Is there
> something need to configured differently for GDB to work with
> the eCos GDB stubs?

There shouldn't be. In the serial case, have you been able to determine
whether the stub actually received the data, and hence why the timeout
seems to happen?

The "remote packets too long" does sound like the register format that GDB
expects now is different from what it used to expect; or it may be a bug. I
can't give any more specific advice than that. Perhaps
gdb@sources.redhat.com may be helpful :-/.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2001-01-31  9:26 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-01-31  3:57 [ECOS] GDB with redboot Tong Chi Wa
2001-01-31  9:26 ` Jonathan Larmour

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).