[ECOS] RedBoot/GDB-stub questions

Grant Edwards grante@visi.com
Tue Mar 6 07:14:00 GMT 2001

On Mon, Mar 05, 2001 at 04:00:50PM -0700, Gary Thomas wrote:

> On 05-Mar-2001 Grant Edwards wrote:
> > My support routines for RedBoot use a hardware timer for the
> > us_delay() functionality.  Now I need to dedicate that timer
> > for use by an eCos device driver.
> > 
> > I assume that this will be a problem if I try to use the GDB
> > stubs in RedBoot to debug an application that uses the driver
> > in question?
> > 
> > If I use GDB stubs in the application rather than RedBoot, will
> > it need a us_delay() routine also?  (Same problem then.)
> For non-standalone (i.e. "normal" applications), 'us_delay' is
> normally defined to use the standard system timer.  Can't you
> do this as well?

Sure.  I don't have a delay routine currently (except for

> > I believe I read somewhere that if you want to debug via TCP,
> > you need separate IP address for RedBoot and for the
> > application, but I can't find where I saw that, nor can I
> > figure out where in the stack that GDB packets are passed to
> > the GDB stubs via the virtual vector stuff.  (I'd prefer to
> > dedicate a port to GDB rather than a whole different IP
> > address, but that's something I'll worry about later.)
> This whole area is pure magic, some of which is still rather
> fragile. Trust me though, if you ever are to get this working,
> you will need to have a separate IP address for GDB and for the
> eCos application.

OK. Is it possible to have RedBoot and the application use one
IP address and GDB stubs use a different one?

My product requirements are such that the boot-loader and the
application have to use the same IP address.  Customers expect
the box to use a single IP address -- that's the way all our
current products work.  We may have to forego network debugging
if it requires allocating two IP addresses per device (I'm not
even sure how we would do that for people using DHCP). Assuming
I can get serial debugging to work, they'd still have that as
an option.

> The magic takes place in the ethernet driver code:
>    io/eth/current/src/net/eth_drv.c

Thanks.  I was looking in the network stack code.

Grant Edwards

More information about the Ecos-discuss mailing list