RE: [ECOS] gdb over ethernet network support for ECOS RAMapplication

RE: [ECOS] gdb over ethernet network support for ECOS RAMapplication

[George Sosnowski]

>It is only possible to initiate a network GDB connection before the
>program starts.  However, you can load and execute a program via a 
>serial connection and later start up a serial GDB session, but not a
>network one.

why is there this difference between a serial and network gdb session?
One of the things I wanted to do is keep gdb support always available
(preferrably via network). Normally, redboot would come up and start the
application by default through its script. So while the application is
running, if I wanted to examine it for some reason, then I could connect
and do so. But it sounds like this is not possible for network gdb
sessions? How about for serial sessions, is it possible to connect after
an application is running? Or must an application be started by gdb in
order for it to be debugged by it? One thought I had was merging the
Redboot functionality into the application, does this not make sense?

>There's nothing to keep you from doing this, but alas, at this time 
>there's not much to help you either.  The FIS directory is laid out so
>that finding things should be straight forward, but there aren't any
>support routines (or a supported API) for doing so.  Of course, if you
>wanted to contribute such support, we'd be more than happy :-)

I actually did a quick and dirty in this case and stole the lookup
function and entry structure to just retrieve the location and size of
the file. I noticed there was packages/fs/rom. Is this a different
fuller rom file system than FIS or a framework of some sort?


-----Original Message-----
From: Gary Thomas [mailto:gary@chez-thomas.org] 
Sent: Tuesday, June 18, 2002 5:06 PM
To: George Sosnowski
Cc: eCos Discussion
Subject: RE: [ECOS] gdb over ethernet network support for ECOS
RAMapplication


On Tue, 2002-06-18 at 16:13, George Sosnowski wrote:
> Thanks for the replies they've been very inciteful.
> I am running ecos that I download via anonymous CVS back in December.
> I've been afraid to get the 2.0 alpha code because I wasn't sure how
> much reconfiguration and lost changes there might be on my part.
> 

There would be few, if any, such impacts.  The version number belies
the code changes (they are major, but still incremental).  The main
reason for a major version number jump was the change in licensing.

> Does a gdb session have to be already established via network or
serial
> before the RAM application runs? Or can one connect via gdb even after
> the application image is loaded and running? Showing my ignorance of
> gdb, if connected after the application image is running, can it still
> be debugged or does it have to be rerun?
> 

It is only possible to initiate a network GDB connection before the
program starts.  However, you can load and execute a program via a 
serial connection and later start up a serial GDB session, but not a
network one.

> On a somewhat related issue, can RAM applications somehow access the
> FIS? I have some fpga images that I want to store there and wasn't
sure
> if there was an interface that provided the RedBoot functionality of
> lookup, create, load, etc.
> 

There's nothing to keep you from doing this, but alas, at this time 
there's not much to help you either.  The FIS directory is laid out so
that finding things should be straight forward, but there aren't any
support routines (or a supported API) for doing so.  Of course, if you
wanted to contribute such support, we'd be more than happy :-)

> Thanks again!
> 
> -----Original Message-----
> From: Gary Thomas [mailto:gary@chez-thomas.org] 
> Sent: Tuesday, June 18, 2002 11:30 AM
> To: George Sosnowski
> Cc: eCos Discussion
> Subject: RE: [ECOS] gdb over ethernet network support for ECOS
> RAMapplication
> 
> 
> On Tue, 2002-06-18 at 11:52, George Sosnowski wrote:
> > I was using a target based on powerpc mbx and viper boards which has

> > an 860T.
> > 
> > The thing I'm not clear about is that my ECOS 1.3.1 application is 
> > using the NET package which is a fuller version IP stack than what 
> > Redboot has. Do these stacks run concurrently somehow? Or are the 
> > ethernet (fec) driver and IP stack in the ecos application
inheriting 
> > the Redboot driver and stack?
> > 
> 
> Actually neither.
> 
> The network stacks are split into a logical and physical driver.
Which
> logical driver is in use depends on the mode; there is a separate
driver
> for RedBoot than from an eCos application.  However, the physical
driver
> is the same for both environments (or at least equivalent).  What
> happens is the physical driver in RedBoot is used until the eCos
> application takes over.  Once that happens, only the physical driver
in
> the eCos application is used, but it gets shared by both the eCos
stack
> (xxxBSD based) and the RedBoot stack.  When there is network activity
> (incoming packets primarily), both logical stacks get a chance to
> process the data/packet.  In this way, both the eCos stack and the
> RedBoot stack can run, more or less in tandem.
> 
> It's all rather complicated, but it does work, because of how the
> drivers are structured.
> 
> BTW - I assume you mean by 1.3.1 that you are using anonymous CVS,
> possibly before the 2.0 alpha was announced.  I would suggest that you
> update to the latest code base since there have been significant
changes
> since 1.3.1 was officially relased *in March of 2000*!
> 
> > -----Original Message-----
> > From: Gary Thomas [mailto:gary@chez-thomas.org]
> > Sent: Tuesday, June 18, 2002 10:40 AM
> > To: George Sosnowski
> > Cc: eCos Discussion
> > Subject: Re: [ECOS] gdb over ethernet network support for ECOS
> > RAMapplication
> > 
> > 
> > On Tue, 2002-06-18 at 11:20, George Sosnowski wrote:
> > > I'm running RedBoot on my target (powerpc 860T based) from flash,
> > > which has both serial and network (TCP 9000) support for GDB. When

> > > RedBoot loads an ECOS
> > > (v1.3) RAM
> > > application, what's the best way to configure the ecos ram
> application
> > 
> > > to have support/ maintain support for GDB over the
network/ethernet
> > > (fec) , as well as serial?
> > >  
> > > >From what I understand it looks like RAM applications are only
> > > >supposed
> > > to inherit
> > > serial gdb functionality?  Although the Redboot documentation says
> > "ecos
> > > contains
> > > special network sharing code to allow for this situation". I
didn't 
> > > notice anything at the ethernet (fec) or IP stack level. Have I 
> > > overlooked this?
> > >  
> > > One thought I had on doing this was to merge in the Redboot RAM
> > > functionality into
> > > my application.  This wouldn't maintain a gdb session over the
> network
> > > from the ROM
> > > Redboot, but would give gdb support over the network in RAM
> > application
> > > at least.
> > 
> > If you're running RedBoot from ROM, any network GDB connection will 
> > remain, even after the eCos application starts up.  One caveat is
that
> 
> > RedBoot and your eCos application have to use unique IP addresses.  
> > This is normally done by giving RedBoot a static address and then 
> > letting the eCos application either use a different static address
or 
> > get an address dynamically via DHCP.
> > 
> > Also note that once you start debugging via the network, the serial
is
> 
> > no longer part of the GDB "path".  Your application can do things
with
> 
> > it directly, e.g. by accessing it via the serial device drivers, but

> > only the network will be used for GDB control and/or output.
> > 
> > What platform are you using (just for my information)?
> > 
> > 
> > --
> > Before posting, please read the FAQ:
> http://sources.redhat.com/fom/ecos
> > and search the list archive:
http://sources.redhat.com/ml/ecos-discuss
> 
> 
> 
> -- 
> Before posting, please read the FAQ:
http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss



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

RE: [ECOS] gdb over ethernet network support for ECOS RAMapplication

[Gary Thomas]

On Wed, 2002-06-19 at 10:14, George Sosnowski wrote:
> >It is only possible to initiate a network GDB connection before the
> >program starts.  However, you can load and execute a program via a 
> >serial connection and later start up a serial GDB session, but not a
> >network one.
> 
> why is there this difference between a serial and network gdb session?
> One of the things I wanted to do is keep gdb support always available
> (preferrably via network). Normally, redboot would come up and start the
> application by default through its script. So while the application is
> running, if I wanted to examine it for some reason, then I could connect
> and do so. But it sounds like this is not possible for network gdb
> sessions? How about for serial sessions, is it possible to connect after
> an application is running? Or must an application be started by gdb in
> order for it to be debugged by it? One thought I had was merging the
> Redboot functionality into the application, does this not make sense?
> 

As I said earlier, yes it is possible to establish a GDB session using
the serial port even when the program was not started via GDB.  You 
could let RedBoot start up your application and then at any later time,
break into the program and start using GDB.  It's even possible to later
disconnect GDB and allow the program to carry on its merry way.

The only reason it works for serial connections is that it's possible
(i.e. relatively easy) to detect the presence of a ^C (the interrupt 
sequence) on a serial line, even while the system is running, perhaps
using that same serial device.  On the other hand, to detect a TCP open
operation on the network would require that incoming network data be
processed, then some how magically decide that this is an open destined
for the GDB code, etc.  It would also mean that you'd need the whole
RedBoot/GDB network stack available.  It all seems not only expensive,
messy and fragile, but really hard to make work.

> >There's nothing to keep you from doing this, but alas, at this time 
> >there's not much to help you either.  The FIS directory is laid out so
> >that finding things should be straight forward, but there aren't any
> >support routines (or a supported API) for doing so.  Of course, if you
> >wanted to contribute such support, we'd be more than happy :-)
> 
> I actually did a quick and dirty in this case and stole the lookup
> function and entry structure to just retrieve the location and size of
> the file. I noticed there was packages/fs/rom. Is this a different
> fuller rom file system than FIS or a framework of some sort?
> 

It's completely different and not related.

> 
> -----Original Message-----
> From: Gary Thomas [mailto:gary@chez-thomas.org] 
> Sent: Tuesday, June 18, 2002 5:06 PM
> To: George Sosnowski
> Cc: eCos Discussion
> Subject: RE: [ECOS] gdb over ethernet network support for ECOS
> RAMapplication
> 
> 
> On Tue, 2002-06-18 at 16:13, George Sosnowski wrote:
> > Thanks for the replies they've been very inciteful.
> > I am running ecos that I download via anonymous CVS back in December.
> > I've been afraid to get the 2.0 alpha code because I wasn't sure how
> > much reconfiguration and lost changes there might be on my part.
> > 
> 
> There would be few, if any, such impacts.  The version number belies
> the code changes (they are major, but still incremental).  The main
> reason for a major version number jump was the change in licensing.
> 
> > Does a gdb session have to be already established via network or
> serial
> > before the RAM application runs? Or can one connect via gdb even after
> > the application image is loaded and running? Showing my ignorance of
> > gdb, if connected after the application image is running, can it still
> > be debugged or does it have to be rerun?
> > 
> 
> It is only possible to initiate a network GDB connection before the
> program starts.  However, you can load and execute a program via a 
> serial connection and later start up a serial GDB session, but not a
> network one.
> 
> > On a somewhat related issue, can RAM applications somehow access the
> > FIS? I have some fpga images that I want to store there and wasn't
> sure
> > if there was an interface that provided the RedBoot functionality of
> > lookup, create, load, etc.
> > 
> 
> There's nothing to keep you from doing this, but alas, at this time 
> there's not much to help you either.  The FIS directory is laid out so
> that finding things should be straight forward, but there aren't any
> support routines (or a supported API) for doing so.  Of course, if you
> wanted to contribute such support, we'd be more than happy :-)
> 
> > Thanks again!
> > 
> > -----Original Message-----
> > From: Gary Thomas [mailto:gary@chez-thomas.org] 
> > Sent: Tuesday, June 18, 2002 11:30 AM
> > To: George Sosnowski
> > Cc: eCos Discussion
> > Subject: RE: [ECOS] gdb over ethernet network support for ECOS
> > RAMapplication
> > 
> > 
> > On Tue, 2002-06-18 at 11:52, George Sosnowski wrote:
> > > I was using a target based on powerpc mbx and viper boards which has
> 
> > > an 860T.
> > > 
> > > The thing I'm not clear about is that my ECOS 1.3.1 application is 
> > > using the NET package which is a fuller version IP stack than what 
> > > Redboot has. Do these stacks run concurrently somehow? Or are the 
> > > ethernet (fec) driver and IP stack in the ecos application
> inheriting 
> > > the Redboot driver and stack?
> > > 
> > 
> > Actually neither.
> > 
> > The network stacks are split into a logical and physical driver.
> Which
> > logical driver is in use depends on the mode; there is a separate
> driver
> > for RedBoot than from an eCos application.  However, the physical
> driver
> > is the same for both environments (or at least equivalent).  What
> > happens is the physical driver in RedBoot is used until the eCos
> > application takes over.  Once that happens, only the physical driver
> in
> > the eCos application is used, but it gets shared by both the eCos
> stack
> > (xxxBSD based) and the RedBoot stack.  When there is network activity
> > (incoming packets primarily), both logical stacks get a chance to
> > process the data/packet.  In this way, both the eCos stack and the
> > RedBoot stack can run, more or less in tandem.
> > 
> > It's all rather complicated, but it does work, because of how the
> > drivers are structured.
> > 
> > BTW - I assume you mean by 1.3.1 that you are using anonymous CVS,
> > possibly before the 2.0 alpha was announced.  I would suggest that you
> > update to the latest code base since there have been significant
> changes
> > since 1.3.1 was officially relased *in March of 2000*!
> > 
> > > -----Original Message-----
> > > From: Gary Thomas [mailto:gary@chez-thomas.org]
> > > Sent: Tuesday, June 18, 2002 10:40 AM
> > > To: George Sosnowski
> > > Cc: eCos Discussion
> > > Subject: Re: [ECOS] gdb over ethernet network support for ECOS
> > > RAMapplication
> > > 
> > > 
> > > On Tue, 2002-06-18 at 11:20, George Sosnowski wrote:
> > > > I'm running RedBoot on my target (powerpc 860T based) from flash,
> > > > which has both serial and network (TCP 9000) support for GDB. When
> 
> > > > RedBoot loads an ECOS
> > > > (v1.3) RAM
> > > > application, what's the best way to configure the ecos ram
> > application
> > > 
> > > > to have support/ maintain support for GDB over the
> network/ethernet
> > > > (fec) , as well as serial?
> > > >  
> > > > >From what I understand it looks like RAM applications are only
> > > > >supposed
> > > > to inherit
> > > > serial gdb functionality?  Although the Redboot documentation says
> > > "ecos
> > > > contains
> > > > special network sharing code to allow for this situation". I
> didn't 
> > > > notice anything at the ethernet (fec) or IP stack level. Have I 
> > > > overlooked this?
> > > >  
> > > > One thought I had on doing this was to merge in the Redboot RAM
> > > > functionality into
> > > > my application.  This wouldn't maintain a gdb session over the
> > network
> > > > from the ROM
> > > > Redboot, but would give gdb support over the network in RAM
> > > application
> > > > at least.
> > > 
> > > If you're running RedBoot from ROM, any network GDB connection will 
> > > remain, even after the eCos application starts up.  One caveat is
> that
> > 
> > > RedBoot and your eCos application have to use unique IP addresses.  
> > > This is normally done by giving RedBoot a static address and then 
> > > letting the eCos application either use a different static address
> or 
> > > get an address dynamically via DHCP.
> > > 
> > > Also note that once you start debugging via the network, the serial
> is
> > 
> > > no longer part of the GDB "path".  Your application can do things
> with
> > 
> > > it directly, e.g. by accessing it via the serial device drivers, but
> 
> > > only the network will be used for GDB control and/or output.
> > > 
> > > What platform are you using (just for my information)?
> > > 
> > > 
> > > --
> > > Before posting, please read the FAQ:
> > http://sources.redhat.com/fom/ecos
> > > and search the list archive:
> http://sources.redhat.com/ml/ecos-discuss
> > 
> > 
> > 
> > -- 
> > Before posting, please read the FAQ:
> http://sources.redhat.com/fom/ecos
> > and search the list archive: http://sources.redhat.com/ml/ecos-discuss
> 



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

RE: [ECOS] gdb over ethernet network support for ECOS RAMapplication

[George Sosnowski]

One thought I had about this was possibly the use of some select() api
which would block (actually sleep the thread) until a read on Stdin was 
possible. Is something like this supported in Ecos? 

It seems like otherwise a getc from a thread will not let other lower
priority 
threads have time since the getc is an active poll and not put the
thread to
sleep until some data is available. Is this a correct assessment?


>Given the scenario, where RedBoot and the application start up on their

>own and at a later time a serial gdb session is initiated where the gdb

>stubs of the ROM monitor are used. I wanted to implement a sort of
shell 
>in the application on the one serial port on the platform (SMC1 for the

>860T). Currently my shell uses fgetc which down to the calling chain
finally 
>calls cyg_hal_plf_serial_getc in ROM which does a hard poll. It was
called 
>indirectly by hal_if_diag_read_char in RAM via macro
CYGACC_COMM_IF_GETC that 
>executed ENTER_MONITOR which disabled interrupts and locked the
scheduler. 
>Thus when a Ctrl-C or any other character is typed to the serial port
the 
>thing doing the fgetc gets the character, but this character didn't go
through 
>hal_ctrlc_isr in RAM and cyg_hal_plf_serial_isr in ROM which check for
Ctrl-C 
>to initiate gdb. In fact, hal_ctrlc_isr in RAM and
cyg_hal_plf_serial_isr in 
>ROM still execute after interrupts get reenabled when EXIT_MONITOR is
executed 
>because the Rx Char interrupt was not cleared is still pending, but
there's no 
>more data in the receive buffers.

>So my question is under this configuration, what's the best serial
character 
>read interface to use for the shell so all Rxed characters are gotten
through 
>interrupt (cyg_hal_plf_serial_isr) and a Ctrl-C is intercepted and gdb
initiated?

>Thanks for your suggestions!



-----Original Message-----
From: Gary Thomas [mailto:gary@chez-thomas.org] 
Sent: Wednesday, June 19, 2002 11:48 AM
To: George Sosnowski
Cc: eCos Discussion
Subject: RE: [ECOS] gdb over ethernet network support for ECOS
RAMapplication


On Wed, 2002-06-19 at 12:34, George Sosnowski wrote:
> >As I said earlier, yes it is possible to establish a GDB session
> >using
> >the serial port even when the program was not started via GDB.  You 
> >could let RedBoot start up your application and then at any later
time,
> 
> >break into the program and start using GDB.  It's even possible to
> later
> >disconnect GDB and allow the program to carry on its merry way.
> 
> I'm sorry to be such a pain on this topic. ;-) I'm not very familiar
> with the workings of gdb, but I think I'm understanding, thanks to 
> your responses! One last (hopefully) question I had regarding the 
> scenario you describe above, where RedBoot and the application start 
> up on their own and at a later time a serial gdb session is initiated.

> What would be the proper configuration for the application in this
> situation? Would it still use the gdb stubs of the ROM monitor or 
> should it have its own gdb stubs that would take over?
> 

Either way works.  If you use things as they are normally setup, then
you don't need to include the GDB stubs code in your application, that's
only required if your application make it so that RedBoot can no longer
execute (e.g. erase all of it's memory).

> -----Original Message-----
> From: Gary Thomas [mailto:gary@chez-thomas.org]
> Sent: Wednesday, June 19, 2002 9:24 AM
> To: George Sosnowski
> Cc: eCos Discussion
> Subject: RE: [ECOS] gdb over ethernet network support for ECOS
> RAMapplication
> 
> 
> On Wed, 2002-06-19 at 10:14, George Sosnowski wrote:
> > >It is only possible to initiate a network GDB connection before the
> > >program starts.  However, you can load and execute a program via a 
> > >serial connection and later start up a serial GDB session, but not
a 
> > >network one.
> > 
> > why is there this difference between a serial and network gdb 
> > session?
> 
> > One of the things I wanted to do is keep gdb support always 
> > available
> > (preferrably via network). Normally, redboot would come up and start

> > the application by default through its script. So while the 
> > application is running, if I wanted to examine it for some reason, 
> > then I could connect and do so. But it sounds like this is not 
> > possible for network gdb sessions? How about for serial sessions, is

> > it possible to connect after an application is running? Or must an 
> > application be started by gdb in order for it to be debugged by it? 
> > One thought I had was merging the Redboot functionality into the 
> > application, does this not make sense?
> > 
> 
> As I said earlier, yes it is possible to establish a GDB session using

> the serial port even when the program was not started via GDB.  You 
> could let RedBoot start up your application and then at any later 
> time, break into the program and start using GDB.  It's even possible 
> to later disconnect GDB and allow the program to carry on its merry 
> way.
> 
> The only reason it works for serial connections is that it's possible 
> (i.e. relatively easy) to detect the presence of a ^C (the interrupt
> sequence) on a serial line, even while the system is running, perhaps 
> using that same serial device.  On the other hand, to detect a TCP 
> open operation on the network would require that incoming network data

> be processed, then some how magically decide that this is an open 
> destined for the GDB code, etc.  It would also mean that you'd need 
> the whole RedBoot/GDB network stack available.  It all seems not only 
> expensive, messy and fragile, but really hard to make work.
> 
> > >There's nothing to keep you from doing this, but alas, at this time

> > >there's not much to help you either.  The FIS directory is laid out
> so
> > >that finding things should be straight forward, but there aren't 
> > >any support routines (or a supported API) for doing so.  Of course,

> > >if
> you
> > >wanted to contribute such support, we'd be more than happy :-)
> > 
> > I actually did a quick and dirty in this case and stole the lookup
> > function and entry structure to just retrieve the location and size
of
> 
> > the file. I noticed there was packages/fs/rom. Is this a different
> > fuller rom file system than FIS or a framework of some sort?
> > 
> 
> It's completely different and not related.
> 
> > 
> > -----Original Message-----
> > From: Gary Thomas [mailto:gary@chez-thomas.org]
> > Sent: Tuesday, June 18, 2002 5:06 PM
> > To: George Sosnowski
> > Cc: eCos Discussion
> > Subject: RE: [ECOS] gdb over ethernet network support for ECOS 
> > RAMapplication
> > 
> > 
> > On Tue, 2002-06-18 at 16:13, George Sosnowski wrote:
> > > Thanks for the replies they've been very inciteful.
> > > I am running ecos that I download via anonymous CVS back in
> > > December. I've been afraid to get the 2.0 alpha code because I 
> > > wasn't sure how much reconfiguration and lost changes there might
be
> 
> > > on my part.
> > > 
> > 
> > There would be few, if any, such impacts.  The version number belies
> > the code changes (they are major, but still incremental).  The main 
> > reason for a major version number jump was the change in licensing.
> > 
> > > Does a gdb session have to be already established via network or
> > serial
> > > before the RAM application runs? Or can one connect via gdb even
> > > after the application image is loaded and running? Showing my 
> > > ignorance of gdb, if connected after the application image is 
> > > running, can it still be debugged or does it have to be rerun?
> > > 
> > 
> > It is only possible to initiate a network GDB connection before the
> > program starts.  However, you can load and execute a program via a 
> > serial connection and later start up a serial GDB session, but not a

> > network one.
> > 
> > > On a somewhat related issue, can RAM applications somehow access 
> > > the
> 
> > > FIS? I have some fpga images that I want to store there and wasn't
> > sure
> > > if there was an interface that provided the RedBoot functionality 
> > > of
> 
> > > lookup, create, load, etc.
> > > 
> > 
> > There's nothing to keep you from doing this, but alas, at this time 
> > there's not much to help you either.  The FIS directory is laid out 
> > so that finding things should be straight forward, but there aren't 
> > any support routines (or a supported API) for doing so.  Of course, 
> > if you wanted to contribute such support, we'd be more than happy 
> > :-)
> > 
> > > Thanks again!
> > > 
> > > -----Original Message-----
> > > From: Gary Thomas [mailto:gary@chez-thomas.org]
> > > Sent: Tuesday, June 18, 2002 11:30 AM
> > > To: George Sosnowski
> > > Cc: eCos Discussion
> > > Subject: RE: [ECOS] gdb over ethernet network support for ECOS 
> > > RAMapplication
> > > 
> > > 
> > > On Tue, 2002-06-18 at 11:52, George Sosnowski wrote:
> > > > I was using a target based on powerpc mbx and viper boards which
> > > > has
> > 
> > > > an 860T.
> > > > 
> > > > The thing I'm not clear about is that my ECOS 1.3.1 application 
> > > > is using the NET package which is a fuller version IP stack than

> > > > what
> 
> > > > Redboot has. Do these stacks run concurrently somehow? Or are 
> > > > the
> > > > ethernet (fec) driver and IP stack in the ecos application
> > inheriting
> > > > the Redboot driver and stack?
> > > > 
> > > 
> > > Actually neither.
> > > 
> > > The network stacks are split into a logical and physical driver.
> > Which
> > > logical driver is in use depends on the mode; there is a separate
> > driver
> > > for RedBoot than from an eCos application.  However, the physical
> > driver
> > > is the same for both environments (or at least equivalent).  What
> > > happens is the physical driver in RedBoot is used until the eCos 
> > > application takes over.  Once that happens, only the physical
driver
> > in
> > > the eCos application is used, but it gets shared by both the eCos
> > stack
> > > (xxxBSD based) and the RedBoot stack.  When there is network
> > > activity (incoming packets primarily), both logical stacks get a 
> > > chance to process the data/packet.  In this way, both the eCos
stack
> 
> > > and the RedBoot stack can run, more or less in tandem.
> > > 
> > > It's all rather complicated, but it does work, because of how the
> > > drivers are structured.
> > > 
> > > BTW - I assume you mean by 1.3.1 that you are using anonymous CVS,
> > > possibly before the 2.0 alpha was announced.  I would suggest that

> > > you update to the latest code base since there have been
significant
> > changes
> > > since 1.3.1 was officially relased *in March of 2000*!
> > > 
> > > > -----Original Message-----
> > > > From: Gary Thomas [mailto:gary@chez-thomas.org]
> > > > Sent: Tuesday, June 18, 2002 10:40 AM
> > > > To: George Sosnowski
> > > > Cc: eCos Discussion
> > > > Subject: Re: [ECOS] gdb over ethernet network support for ECOS
> > > > RAMapplication
> > > > 
> > > > 
> > > > On Tue, 2002-06-18 at 11:20, George Sosnowski wrote:
> > > > > I'm running RedBoot on my target (powerpc 860T based) from
> > > > > flash, which has both serial and network (TCP 9000) support
for 
> > > > > GDB. When
> > 
> > > > > RedBoot loads an ECOS
> > > > > (v1.3) RAM
> > > > > application, what's the best way to configure the ecos ram
> > > application
> > > > 
> > > > > to have support/ maintain support for GDB over the
> > network/ethernet
> > > > > (fec) , as well as serial?
> > > > >  
> > > > > >From what I understand it looks like RAM applications are 
> > > > > >only
> > > > > >supposed
> > > > > to inherit
> > > > > serial gdb functionality?  Although the Redboot documentation
> > > > > says
> > > > "ecos
> > > > > contains
> > > > > special network sharing code to allow for this situation". I
> > didn't
> > > > > notice anything at the ethernet (fec) or IP stack level. Have 
> > > > > I overlooked this?
> > > > >  
> > > > > One thought I had on doing this was to merge in the Redboot 
> > > > > RAM
> > > > > functionality into my application.  This wouldn't maintain a
gdb
> 
> > > > > session over the
> > > network
> > > > > from the ROM
> > > > > Redboot, but would give gdb support over the network in RAM
> > > > application
> > > > > at least.
> > > > 
> > > > If you're running RedBoot from ROM, any network GDB connection
> > > > will
> > > > remain, even after the eCos application starts up.  One caveat
is
> > that
> > > 
> > > > RedBoot and your eCos application have to use unique IP 
> > > > addresses. This is normally done by giving RedBoot a static 
> > > > address and then letting the eCos application either use a 
> > > > different static address
> > or
> > > > get an address dynamically via DHCP.
> > > > 
> > > > Also note that once you start debugging via the network, the
> > > > serial
> > is
> > > 
> > > > no longer part of the GDB "path".  Your application can do 
> > > > things
> > with
> > > 
> > > > it directly, e.g. by accessing it via the serial device drivers,
> > > > but
> > 
> > > > only the network will be used for GDB control and/or output.
> > > > 
> > > > What platform are you using (just for my information)?
> > > > 
> > > > 
> > > > --
> > > > Before posting, please read the FAQ:
> > > http://sources.redhat.com/fom/ecos
> > > > and search the list archive:
> > http://sources.redhat.com/ml/ecos-discuss
> > > 
> > > 
> > > 
> > > --
> > > Before posting, please read the FAQ:
> > http://sources.redhat.com/fom/ecos
> > > and search the list archive:
> > > http://sources.redhat.com/ml/ecos-discuss
> > 
> 
> 
> 
> --
> Before posting, please read the FAQ:
http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss



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


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

RE: [ECOS] gdb over ethernet network support for ECOS RAMapplication

[George Sosnowski]

Given the scenario, where RedBoot and the application start up on their
own and at a later time a serial gdb session is initiated where the gdb
stubs of the ROM monitor are used. I wanted to implement a sort of shell
in the application on the one serial port on the platform (SMC1 for the
860T). Currently my shell uses fgetc which down to the calling chain
finally calls cyg_hal_plf_serial_getc in ROM which does a hard poll. It
was called indirectly by hal_if_diag_read_char in RAM via macro
CYGACC_COMM_IF_GETC that executed ENTER_MONITOR which disabled
interrupts and locked the scheduler. Thus when a Ctrl-C or any other
character is typed to the serial port the thing doing the fgetc gets the
character, but this character didn't go through hal_ctrlc_isr in RAM and
cyg_hal_plf_serial_isr in ROM which check for Ctrl-C to initiate gdb. In
fact, hal_ctrlc_isr in RAM and cyg_hal_plf_serial_isr in ROM still
execute after interrupts get reenabled when EXIT_MONITOR is executed
because the Rx Char interrupt was not cleared is still pending, but
there's no more data in the receive buffers.

So my question is under this configuration, what's the best serial
character read interface to use for the shell so all Rxed characters are
gotten through interrupt (cyg_hal_plf_serial_isr) and a Ctrl-C is
intercepted and gdb initiated?

Thanks for your suggestions!



-----Original Message-----
From: Gary Thomas [mailto:gary@chez-thomas.org] 
Sent: Wednesday, June 19, 2002 11:48 AM
To: George Sosnowski
Cc: eCos Discussion
Subject: RE: [ECOS] gdb over ethernet network support for ECOS
RAMapplication


On Wed, 2002-06-19 at 12:34, George Sosnowski wrote:
> >As I said earlier, yes it is possible to establish a GDB session 
> >using
> >the serial port even when the program was not started via GDB.  You 
> >could let RedBoot start up your application and then at any later
time,
> 
> >break into the program and start using GDB.  It's even possible to
> later
> >disconnect GDB and allow the program to carry on its merry way.
> 
> I'm sorry to be such a pain on this topic. ;-) I'm not very familiar 
> with the workings of gdb, but I think I'm understanding, thanks to 
> your responses! One last (hopefully) question I had regarding the 
> scenario you describe above, where RedBoot and the application start 
> up on their own and at a later time a serial gdb session is initiated.

> What would be the proper configuration for the application in this 
> situation? Would it still use the gdb stubs of the ROM monitor or 
> should it have its own gdb stubs that would take over?
> 

Either way works.  If you use things as they are normally setup, then
you don't need to include the GDB stubs code in your application, that's
only required if your application make it so that RedBoot can no longer
execute (e.g. erase all of it's memory).

> -----Original Message-----
> From: Gary Thomas [mailto:gary@chez-thomas.org]
> Sent: Wednesday, June 19, 2002 9:24 AM
> To: George Sosnowski
> Cc: eCos Discussion
> Subject: RE: [ECOS] gdb over ethernet network support for ECOS
> RAMapplication
> 
> 
> On Wed, 2002-06-19 at 10:14, George Sosnowski wrote:
> > >It is only possible to initiate a network GDB connection before the
> > >program starts.  However, you can load and execute a program via a 
> > >serial connection and later start up a serial GDB session, but not
a 
> > >network one.
> > 
> > why is there this difference between a serial and network gdb 
> > session?
> 
> > One of the things I wanted to do is keep gdb support always 
> > available
> > (preferrably via network). Normally, redboot would come up and start

> > the application by default through its script. So while the 
> > application is running, if I wanted to examine it for some reason, 
> > then I could connect and do so. But it sounds like this is not 
> > possible for network gdb sessions? How about for serial sessions, is

> > it possible to connect after an application is running? Or must an 
> > application be started by gdb in order for it to be debugged by it? 
> > One thought I had was merging the Redboot functionality into the 
> > application, does this not make sense?
> > 
> 
> As I said earlier, yes it is possible to establish a GDB session using

> the serial port even when the program was not started via GDB.  You 
> could let RedBoot start up your application and then at any later 
> time, break into the program and start using GDB.  It's even possible 
> to later disconnect GDB and allow the program to carry on its merry 
> way.
> 
> The only reason it works for serial connections is that it's possible 
> (i.e. relatively easy) to detect the presence of a ^C (the interrupt
> sequence) on a serial line, even while the system is running, perhaps 
> using that same serial device.  On the other hand, to detect a TCP 
> open operation on the network would require that incoming network data

> be processed, then some how magically decide that this is an open 
> destined for the GDB code, etc.  It would also mean that you'd need 
> the whole RedBoot/GDB network stack available.  It all seems not only 
> expensive, messy and fragile, but really hard to make work.
> 
> > >There's nothing to keep you from doing this, but alas, at this time

> > >there's not much to help you either.  The FIS directory is laid out
> so
> > >that finding things should be straight forward, but there aren't 
> > >any support routines (or a supported API) for doing so.  Of course,

> > >if
> you
> > >wanted to contribute such support, we'd be more than happy :-)
> > 
> > I actually did a quick and dirty in this case and stole the lookup
> > function and entry structure to just retrieve the location and size
of
> 
> > the file. I noticed there was packages/fs/rom. Is this a different
> > fuller rom file system than FIS or a framework of some sort?
> > 
> 
> It's completely different and not related.
> 
> > 
> > -----Original Message-----
> > From: Gary Thomas [mailto:gary@chez-thomas.org]
> > Sent: Tuesday, June 18, 2002 5:06 PM
> > To: George Sosnowski
> > Cc: eCos Discussion
> > Subject: RE: [ECOS] gdb over ethernet network support for ECOS 
> > RAMapplication
> > 
> > 
> > On Tue, 2002-06-18 at 16:13, George Sosnowski wrote:
> > > Thanks for the replies they've been very inciteful.
> > > I am running ecos that I download via anonymous CVS back in
> > > December. I've been afraid to get the 2.0 alpha code because I 
> > > wasn't sure how much reconfiguration and lost changes there might
be
> 
> > > on my part.
> > > 
> > 
> > There would be few, if any, such impacts.  The version number belies
> > the code changes (they are major, but still incremental).  The main 
> > reason for a major version number jump was the change in licensing.
> > 
> > > Does a gdb session have to be already established via network or
> > serial
> > > before the RAM application runs? Or can one connect via gdb even
> > > after the application image is loaded and running? Showing my 
> > > ignorance of gdb, if connected after the application image is 
> > > running, can it still be debugged or does it have to be rerun?
> > > 
> > 
> > It is only possible to initiate a network GDB connection before the
> > program starts.  However, you can load and execute a program via a 
> > serial connection and later start up a serial GDB session, but not a

> > network one.
> > 
> > > On a somewhat related issue, can RAM applications somehow access 
> > > the
> 
> > > FIS? I have some fpga images that I want to store there and wasn't
> > sure
> > > if there was an interface that provided the RedBoot functionality 
> > > of
> 
> > > lookup, create, load, etc.
> > > 
> > 
> > There's nothing to keep you from doing this, but alas, at this time 
> > there's not much to help you either.  The FIS directory is laid out 
> > so that finding things should be straight forward, but there aren't 
> > any support routines (or a supported API) for doing so.  Of course, 
> > if you wanted to contribute such support, we'd be more than happy 
> > :-)
> > 
> > > Thanks again!
> > > 
> > > -----Original Message-----
> > > From: Gary Thomas [mailto:gary@chez-thomas.org]
> > > Sent: Tuesday, June 18, 2002 11:30 AM
> > > To: George Sosnowski
> > > Cc: eCos Discussion
> > > Subject: RE: [ECOS] gdb over ethernet network support for ECOS 
> > > RAMapplication
> > > 
> > > 
> > > On Tue, 2002-06-18 at 11:52, George Sosnowski wrote:
> > > > I was using a target based on powerpc mbx and viper boards which
> > > > has
> > 
> > > > an 860T.
> > > > 
> > > > The thing I'm not clear about is that my ECOS 1.3.1 application 
> > > > is using the NET package which is a fuller version IP stack than

> > > > what
> 
> > > > Redboot has. Do these stacks run concurrently somehow? Or are 
> > > > the
> > > > ethernet (fec) driver and IP stack in the ecos application
> > inheriting
> > > > the Redboot driver and stack?
> > > > 
> > > 
> > > Actually neither.
> > > 
> > > The network stacks are split into a logical and physical driver.
> > Which
> > > logical driver is in use depends on the mode; there is a separate
> > driver
> > > for RedBoot than from an eCos application.  However, the physical
> > driver
> > > is the same for both environments (or at least equivalent).  What
> > > happens is the physical driver in RedBoot is used until the eCos 
> > > application takes over.  Once that happens, only the physical
driver
> > in
> > > the eCos application is used, but it gets shared by both the eCos
> > stack
> > > (xxxBSD based) and the RedBoot stack.  When there is network
> > > activity (incoming packets primarily), both logical stacks get a 
> > > chance to process the data/packet.  In this way, both the eCos
stack
> 
> > > and the RedBoot stack can run, more or less in tandem.
> > > 
> > > It's all rather complicated, but it does work, because of how the
> > > drivers are structured.
> > > 
> > > BTW - I assume you mean by 1.3.1 that you are using anonymous CVS,
> > > possibly before the 2.0 alpha was announced.  I would suggest that

> > > you update to the latest code base since there have been
significant
> > changes
> > > since 1.3.1 was officially relased *in March of 2000*!
> > > 
> > > > -----Original Message-----
> > > > From: Gary Thomas [mailto:gary@chez-thomas.org]
> > > > Sent: Tuesday, June 18, 2002 10:40 AM
> > > > To: George Sosnowski
> > > > Cc: eCos Discussion
> > > > Subject: Re: [ECOS] gdb over ethernet network support for ECOS
> > > > RAMapplication
> > > > 
> > > > 
> > > > On Tue, 2002-06-18 at 11:20, George Sosnowski wrote:
> > > > > I'm running RedBoot on my target (powerpc 860T based) from
> > > > > flash, which has both serial and network (TCP 9000) support
for 
> > > > > GDB. When
> > 
> > > > > RedBoot loads an ECOS
> > > > > (v1.3) RAM
> > > > > application, what's the best way to configure the ecos ram
> > > application
> > > > 
> > > > > to have support/ maintain support for GDB over the
> > network/ethernet
> > > > > (fec) , as well as serial?
> > > > >  
> > > > > >From what I understand it looks like RAM applications are 
> > > > > >only
> > > > > >supposed
> > > > > to inherit
> > > > > serial gdb functionality?  Although the Redboot documentation
> > > > > says
> > > > "ecos
> > > > > contains
> > > > > special network sharing code to allow for this situation". I
> > didn't
> > > > > notice anything at the ethernet (fec) or IP stack level. Have 
> > > > > I overlooked this?
> > > > >  
> > > > > One thought I had on doing this was to merge in the Redboot 
> > > > > RAM
> > > > > functionality into my application.  This wouldn't maintain a
gdb
> 
> > > > > session over the
> > > network
> > > > > from the ROM
> > > > > Redboot, but would give gdb support over the network in RAM
> > > > application
> > > > > at least.
> > > > 
> > > > If you're running RedBoot from ROM, any network GDB connection
> > > > will
> > > > remain, even after the eCos application starts up.  One caveat
is
> > that
> > > 
> > > > RedBoot and your eCos application have to use unique IP 
> > > > addresses. This is normally done by giving RedBoot a static 
> > > > address and then letting the eCos application either use a 
> > > > different static address
> > or
> > > > get an address dynamically via DHCP.
> > > > 
> > > > Also note that once you start debugging via the network, the
> > > > serial
> > is
> > > 
> > > > no longer part of the GDB "path".  Your application can do 
> > > > things
> > with
> > > 
> > > > it directly, e.g. by accessing it via the serial device drivers,
> > > > but
> > 
> > > > only the network will be used for GDB control and/or output.
> > > > 
> > > > What platform are you using (just for my information)?
> > > > 
> > > > 
> > > > --
> > > > Before posting, please read the FAQ:
> > > http://sources.redhat.com/fom/ecos
> > > > and search the list archive:
> > http://sources.redhat.com/ml/ecos-discuss
> > > 
> > > 
> > > 
> > > --
> > > Before posting, please read the FAQ:
> > http://sources.redhat.com/fom/ecos
> > > and search the list archive:
> > > http://sources.redhat.com/ml/ecos-discuss
> > 
> 
> 
> 
> --
> Before posting, please read the FAQ:
http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss



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

RE: [ECOS] gdb over ethernet network support for ECOS RAMapplication

[Gary Thomas]

On Wed, 2002-06-19 at 12:34, George Sosnowski wrote:
> >As I said earlier, yes it is possible to establish a GDB session using 
> >the serial port even when the program was not started via GDB.  You 
> >could let RedBoot start up your application and then at any later time,
> 
> >break into the program and start using GDB.  It's even possible to
> later 
> >disconnect GDB and allow the program to carry on its merry way.
> 
> I'm sorry to be such a pain on this topic. ;-) I'm not very familiar
> with the workings of gdb, but I think I'm understanding, thanks to your
> responses! One last (hopefully) question I had regarding the scenario
> you describe above, where RedBoot and the application start up on their
> own and at a later time a serial gdb session is initiated. What would be
> the proper configuration for the application in this situation? Would it
> still use the gdb stubs of the ROM monitor or should it have its own gdb
> stubs that would take over?
> 

Either way works.  If you use things as they are normally setup, then
you don't need to include the GDB stubs code in your application, that's
only required if your application make it so that RedBoot can no longer
execute (e.g. erase all of it's memory).

> -----Original Message-----
> From: Gary Thomas [mailto:gary@chez-thomas.org] 
> Sent: Wednesday, June 19, 2002 9:24 AM
> To: George Sosnowski
> Cc: eCos Discussion
> Subject: RE: [ECOS] gdb over ethernet network support for ECOS
> RAMapplication
> 
> 
> On Wed, 2002-06-19 at 10:14, George Sosnowski wrote:
> > >It is only possible to initiate a network GDB connection before the 
> > >program starts.  However, you can load and execute a program via a 
> > >serial connection and later start up a serial GDB session, but not a 
> > >network one.
> > 
> > why is there this difference between a serial and network gdb session?
> 
> > One of the things I wanted to do is keep gdb support always available 
> > (preferrably via network). Normally, redboot would come up and start 
> > the application by default through its script. So while the 
> > application is running, if I wanted to examine it for some reason, 
> > then I could connect and do so. But it sounds like this is not 
> > possible for network gdb sessions? How about for serial sessions, is 
> > it possible to connect after an application is running? Or must an 
> > application be started by gdb in order for it to be debugged by it? 
> > One thought I had was merging the Redboot functionality into the 
> > application, does this not make sense?
> > 
> 
> As I said earlier, yes it is possible to establish a GDB session using
> the serial port even when the program was not started via GDB.  You 
> could let RedBoot start up your application and then at any later time,
> break into the program and start using GDB.  It's even possible to later
> disconnect GDB and allow the program to carry on its merry way.
> 
> The only reason it works for serial connections is that it's possible
> (i.e. relatively easy) to detect the presence of a ^C (the interrupt 
> sequence) on a serial line, even while the system is running, perhaps
> using that same serial device.  On the other hand, to detect a TCP open
> operation on the network would require that incoming network data be
> processed, then some how magically decide that this is an open destined
> for the GDB code, etc.  It would also mean that you'd need the whole
> RedBoot/GDB network stack available.  It all seems not only expensive,
> messy and fragile, but really hard to make work.
> 
> > >There's nothing to keep you from doing this, but alas, at this time
> > >there's not much to help you either.  The FIS directory is laid out
> so
> > >that finding things should be straight forward, but there aren't any
> > >support routines (or a supported API) for doing so.  Of course, if
> you
> > >wanted to contribute such support, we'd be more than happy :-)
> > 
> > I actually did a quick and dirty in this case and stole the lookup 
> > function and entry structure to just retrieve the location and size of
> 
> > the file. I noticed there was packages/fs/rom. Is this a different 
> > fuller rom file system than FIS or a framework of some sort?
> > 
> 
> It's completely different and not related.
> 
> > 
> > -----Original Message-----
> > From: Gary Thomas [mailto:gary@chez-thomas.org]
> > Sent: Tuesday, June 18, 2002 5:06 PM
> > To: George Sosnowski
> > Cc: eCos Discussion
> > Subject: RE: [ECOS] gdb over ethernet network support for ECOS
> > RAMapplication
> > 
> > 
> > On Tue, 2002-06-18 at 16:13, George Sosnowski wrote:
> > > Thanks for the replies they've been very inciteful.
> > > I am running ecos that I download via anonymous CVS back in 
> > > December. I've been afraid to get the 2.0 alpha code because I 
> > > wasn't sure how much reconfiguration and lost changes there might be
> 
> > > on my part.
> > > 
> > 
> > There would be few, if any, such impacts.  The version number belies 
> > the code changes (they are major, but still incremental).  The main 
> > reason for a major version number jump was the change in licensing.
> > 
> > > Does a gdb session have to be already established via network or
> > serial
> > > before the RAM application runs? Or can one connect via gdb even 
> > > after the application image is loaded and running? Showing my 
> > > ignorance of gdb, if connected after the application image is 
> > > running, can it still be debugged or does it have to be rerun?
> > > 
> > 
> > It is only possible to initiate a network GDB connection before the 
> > program starts.  However, you can load and execute a program via a 
> > serial connection and later start up a serial GDB session, but not a 
> > network one.
> > 
> > > On a somewhat related issue, can RAM applications somehow access the
> 
> > > FIS? I have some fpga images that I want to store there and wasn't
> > sure
> > > if there was an interface that provided the RedBoot functionality of
> 
> > > lookup, create, load, etc.
> > > 
> > 
> > There's nothing to keep you from doing this, but alas, at this time
> > there's not much to help you either.  The FIS directory is laid out so
> > that finding things should be straight forward, but there aren't any
> > support routines (or a supported API) for doing so.  Of course, if you
> > wanted to contribute such support, we'd be more than happy :-)
> > 
> > > Thanks again!
> > > 
> > > -----Original Message-----
> > > From: Gary Thomas [mailto:gary@chez-thomas.org]
> > > Sent: Tuesday, June 18, 2002 11:30 AM
> > > To: George Sosnowski
> > > Cc: eCos Discussion
> > > Subject: RE: [ECOS] gdb over ethernet network support for ECOS
> > > RAMapplication
> > > 
> > > 
> > > On Tue, 2002-06-18 at 11:52, George Sosnowski wrote:
> > > > I was using a target based on powerpc mbx and viper boards which 
> > > > has
> > 
> > > > an 860T.
> > > > 
> > > > The thing I'm not clear about is that my ECOS 1.3.1 application is
> > > > using the NET package which is a fuller version IP stack than what
> 
> > > > Redboot has. Do these stacks run concurrently somehow? Or are the 
> > > > ethernet (fec) driver and IP stack in the ecos application
> > inheriting
> > > > the Redboot driver and stack?
> > > > 
> > > 
> > > Actually neither.
> > > 
> > > The network stacks are split into a logical and physical driver.
> > Which
> > > logical driver is in use depends on the mode; there is a separate
> > driver
> > > for RedBoot than from an eCos application.  However, the physical
> > driver
> > > is the same for both environments (or at least equivalent).  What 
> > > happens is the physical driver in RedBoot is used until the eCos 
> > > application takes over.  Once that happens, only the physical driver
> > in
> > > the eCos application is used, but it gets shared by both the eCos
> > stack
> > > (xxxBSD based) and the RedBoot stack.  When there is network 
> > > activity (incoming packets primarily), both logical stacks get a 
> > > chance to process the data/packet.  In this way, both the eCos stack
> 
> > > and the RedBoot stack can run, more or less in tandem.
> > > 
> > > It's all rather complicated, but it does work, because of how the 
> > > drivers are structured.
> > > 
> > > BTW - I assume you mean by 1.3.1 that you are using anonymous CVS, 
> > > possibly before the 2.0 alpha was announced.  I would suggest that 
> > > you update to the latest code base since there have been significant
> > changes
> > > since 1.3.1 was officially relased *in March of 2000*!
> > > 
> > > > -----Original Message-----
> > > > From: Gary Thomas [mailto:gary@chez-thomas.org]
> > > > Sent: Tuesday, June 18, 2002 10:40 AM
> > > > To: George Sosnowski
> > > > Cc: eCos Discussion
> > > > Subject: Re: [ECOS] gdb over ethernet network support for ECOS 
> > > > RAMapplication
> > > > 
> > > > 
> > > > On Tue, 2002-06-18 at 11:20, George Sosnowski wrote:
> > > > > I'm running RedBoot on my target (powerpc 860T based) from 
> > > > > flash, which has both serial and network (TCP 9000) support for 
> > > > > GDB. When
> > 
> > > > > RedBoot loads an ECOS
> > > > > (v1.3) RAM
> > > > > application, what's the best way to configure the ecos ram
> > > application
> > > > 
> > > > > to have support/ maintain support for GDB over the
> > network/ethernet
> > > > > (fec) , as well as serial?
> > > > >  
> > > > > >From what I understand it looks like RAM applications are only 
> > > > > >supposed
> > > > > to inherit
> > > > > serial gdb functionality?  Although the Redboot documentation 
> > > > > says
> > > > "ecos
> > > > > contains
> > > > > special network sharing code to allow for this situation". I
> > didn't
> > > > > notice anything at the ethernet (fec) or IP stack level. Have I
> > > > > overlooked this?
> > > > >  
> > > > > One thought I had on doing this was to merge in the Redboot RAM 
> > > > > functionality into my application.  This wouldn't maintain a gdb
> 
> > > > > session over the
> > > network
> > > > > from the ROM
> > > > > Redboot, but would give gdb support over the network in RAM
> > > > application
> > > > > at least.
> > > > 
> > > > If you're running RedBoot from ROM, any network GDB connection 
> > > > will
> > > > remain, even after the eCos application starts up.  One caveat is
> > that
> > > 
> > > > RedBoot and your eCos application have to use unique IP addresses.
> > > > This is normally done by giving RedBoot a static address and then 
> > > > letting the eCos application either use a different static address
> > or
> > > > get an address dynamically via DHCP.
> > > > 
> > > > Also note that once you start debugging via the network, the 
> > > > serial
> > is
> > > 
> > > > no longer part of the GDB "path".  Your application can do things
> > with
> > > 
> > > > it directly, e.g. by accessing it via the serial device drivers, 
> > > > but
> > 
> > > > only the network will be used for GDB control and/or output.
> > > > 
> > > > What platform are you using (just for my information)?
> > > > 
> > > > 
> > > > --
> > > > Before posting, please read the FAQ:
> > > http://sources.redhat.com/fom/ecos
> > > > and search the list archive:
> > http://sources.redhat.com/ml/ecos-discuss
> > > 
> > > 
> > > 
> > > --
> > > Before posting, please read the FAQ:
> > http://sources.redhat.com/fom/ecos
> > > and search the list archive: 
> > > http://sources.redhat.com/ml/ecos-discuss
> > 
> 
> 
> 
> -- 
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss



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

RE: [ECOS] gdb over ethernet network support for ECOS RAMapplication

[George Sosnowski]

>As I said earlier, yes it is possible to establish a GDB session using 
>the serial port even when the program was not started via GDB.  You 
>could let RedBoot start up your application and then at any later time,

>break into the program and start using GDB.  It's even possible to
later 
>disconnect GDB and allow the program to carry on its merry way.

I'm sorry to be such a pain on this topic. ;-) I'm not very familiar
with the workings of gdb, but I think I'm understanding, thanks to your
responses! One last (hopefully) question I had regarding the scenario
you describe above, where RedBoot and the application start up on their
own and at a later time a serial gdb session is initiated. What would be
the proper configuration for the application in this situation? Would it
still use the gdb stubs of the ROM monitor or should it have its own gdb
stubs that would take over?

-----Original Message-----
From: Gary Thomas [mailto:gary@chez-thomas.org] 
Sent: Wednesday, June 19, 2002 9:24 AM
To: George Sosnowski
Cc: eCos Discussion
Subject: RE: [ECOS] gdb over ethernet network support for ECOS
RAMapplication


On Wed, 2002-06-19 at 10:14, George Sosnowski wrote:
> >It is only possible to initiate a network GDB connection before the 
> >program starts.  However, you can load and execute a program via a 
> >serial connection and later start up a serial GDB session, but not a 
> >network one.
> 
> why is there this difference between a serial and network gdb session?

> One of the things I wanted to do is keep gdb support always available 
> (preferrably via network). Normally, redboot would come up and start 
> the application by default through its script. So while the 
> application is running, if I wanted to examine it for some reason, 
> then I could connect and do so. But it sounds like this is not 
> possible for network gdb sessions? How about for serial sessions, is 
> it possible to connect after an application is running? Or must an 
> application be started by gdb in order for it to be debugged by it? 
> One thought I had was merging the Redboot functionality into the 
> application, does this not make sense?
> 

As I said earlier, yes it is possible to establish a GDB session using
the serial port even when the program was not started via GDB.  You 
could let RedBoot start up your application and then at any later time,
break into the program and start using GDB.  It's even possible to later
disconnect GDB and allow the program to carry on its merry way.

The only reason it works for serial connections is that it's possible
(i.e. relatively easy) to detect the presence of a ^C (the interrupt 
sequence) on a serial line, even while the system is running, perhaps
using that same serial device.  On the other hand, to detect a TCP open
operation on the network would require that incoming network data be
processed, then some how magically decide that this is an open destined
for the GDB code, etc.  It would also mean that you'd need the whole
RedBoot/GDB network stack available.  It all seems not only expensive,
messy and fragile, but really hard to make work.

> >There's nothing to keep you from doing this, but alas, at this time
> >there's not much to help you either.  The FIS directory is laid out
so
> >that finding things should be straight forward, but there aren't any
> >support routines (or a supported API) for doing so.  Of course, if
you
> >wanted to contribute such support, we'd be more than happy :-)
> 
> I actually did a quick and dirty in this case and stole the lookup 
> function and entry structure to just retrieve the location and size of

> the file. I noticed there was packages/fs/rom. Is this a different 
> fuller rom file system than FIS or a framework of some sort?
> 

It's completely different and not related.

> 
> -----Original Message-----
> From: Gary Thomas [mailto:gary@chez-thomas.org]
> Sent: Tuesday, June 18, 2002 5:06 PM
> To: George Sosnowski
> Cc: eCos Discussion
> Subject: RE: [ECOS] gdb over ethernet network support for ECOS
> RAMapplication
> 
> 
> On Tue, 2002-06-18 at 16:13, George Sosnowski wrote:
> > Thanks for the replies they've been very inciteful.
> > I am running ecos that I download via anonymous CVS back in 
> > December. I've been afraid to get the 2.0 alpha code because I 
> > wasn't sure how much reconfiguration and lost changes there might be

> > on my part.
> > 
> 
> There would be few, if any, such impacts.  The version number belies 
> the code changes (they are major, but still incremental).  The main 
> reason for a major version number jump was the change in licensing.
> 
> > Does a gdb session have to be already established via network or
> serial
> > before the RAM application runs? Or can one connect via gdb even 
> > after the application image is loaded and running? Showing my 
> > ignorance of gdb, if connected after the application image is 
> > running, can it still be debugged or does it have to be rerun?
> > 
> 
> It is only possible to initiate a network GDB connection before the 
> program starts.  However, you can load and execute a program via a 
> serial connection and later start up a serial GDB session, but not a 
> network one.
> 
> > On a somewhat related issue, can RAM applications somehow access the

> > FIS? I have some fpga images that I want to store there and wasn't
> sure
> > if there was an interface that provided the RedBoot functionality of

> > lookup, create, load, etc.
> > 
> 
> There's nothing to keep you from doing this, but alas, at this time
> there's not much to help you either.  The FIS directory is laid out so
> that finding things should be straight forward, but there aren't any
> support routines (or a supported API) for doing so.  Of course, if you
> wanted to contribute such support, we'd be more than happy :-)
> 
> > Thanks again!
> > 
> > -----Original Message-----
> > From: Gary Thomas [mailto:gary@chez-thomas.org]
> > Sent: Tuesday, June 18, 2002 11:30 AM
> > To: George Sosnowski
> > Cc: eCos Discussion
> > Subject: RE: [ECOS] gdb over ethernet network support for ECOS
> > RAMapplication
> > 
> > 
> > On Tue, 2002-06-18 at 11:52, George Sosnowski wrote:
> > > I was using a target based on powerpc mbx and viper boards which 
> > > has
> 
> > > an 860T.
> > > 
> > > The thing I'm not clear about is that my ECOS 1.3.1 application is
> > > using the NET package which is a fuller version IP stack than what

> > > Redboot has. Do these stacks run concurrently somehow? Or are the 
> > > ethernet (fec) driver and IP stack in the ecos application
> inheriting
> > > the Redboot driver and stack?
> > > 
> > 
> > Actually neither.
> > 
> > The network stacks are split into a logical and physical driver.
> Which
> > logical driver is in use depends on the mode; there is a separate
> driver
> > for RedBoot than from an eCos application.  However, the physical
> driver
> > is the same for both environments (or at least equivalent).  What 
> > happens is the physical driver in RedBoot is used until the eCos 
> > application takes over.  Once that happens, only the physical driver
> in
> > the eCos application is used, but it gets shared by both the eCos
> stack
> > (xxxBSD based) and the RedBoot stack.  When there is network 
> > activity (incoming packets primarily), both logical stacks get a 
> > chance to process the data/packet.  In this way, both the eCos stack

> > and the RedBoot stack can run, more or less in tandem.
> > 
> > It's all rather complicated, but it does work, because of how the 
> > drivers are structured.
> > 
> > BTW - I assume you mean by 1.3.1 that you are using anonymous CVS, 
> > possibly before the 2.0 alpha was announced.  I would suggest that 
> > you update to the latest code base since there have been significant
> changes
> > since 1.3.1 was officially relased *in March of 2000*!
> > 
> > > -----Original Message-----
> > > From: Gary Thomas [mailto:gary@chez-thomas.org]
> > > Sent: Tuesday, June 18, 2002 10:40 AM
> > > To: George Sosnowski
> > > Cc: eCos Discussion
> > > Subject: Re: [ECOS] gdb over ethernet network support for ECOS 
> > > RAMapplication
> > > 
> > > 
> > > On Tue, 2002-06-18 at 11:20, George Sosnowski wrote:
> > > > I'm running RedBoot on my target (powerpc 860T based) from 
> > > > flash, which has both serial and network (TCP 9000) support for 
> > > > GDB. When
> 
> > > > RedBoot loads an ECOS
> > > > (v1.3) RAM
> > > > application, what's the best way to configure the ecos ram
> > application
> > > 
> > > > to have support/ maintain support for GDB over the
> network/ethernet
> > > > (fec) , as well as serial?
> > > >  
> > > > >From what I understand it looks like RAM applications are only 
> > > > >supposed
> > > > to inherit
> > > > serial gdb functionality?  Although the Redboot documentation 
> > > > says
> > > "ecos
> > > > contains
> > > > special network sharing code to allow for this situation". I
> didn't
> > > > notice anything at the ethernet (fec) or IP stack level. Have I
> > > > overlooked this?
> > > >  
> > > > One thought I had on doing this was to merge in the Redboot RAM 
> > > > functionality into my application.  This wouldn't maintain a gdb

> > > > session over the
> > network
> > > > from the ROM
> > > > Redboot, but would give gdb support over the network in RAM
> > > application
> > > > at least.
> > > 
> > > If you're running RedBoot from ROM, any network GDB connection 
> > > will
> > > remain, even after the eCos application starts up.  One caveat is
> that
> > 
> > > RedBoot and your eCos application have to use unique IP addresses.
> > > This is normally done by giving RedBoot a static address and then 
> > > letting the eCos application either use a different static address
> or
> > > get an address dynamically via DHCP.
> > > 
> > > Also note that once you start debugging via the network, the 
> > > serial
> is
> > 
> > > no longer part of the GDB "path".  Your application can do things
> with
> > 
> > > it directly, e.g. by accessing it via the serial device drivers, 
> > > but
> 
> > > only the network will be used for GDB control and/or output.
> > > 
> > > What platform are you using (just for my information)?
> > > 
> > > 
> > > --
> > > Before posting, please read the FAQ:
> > http://sources.redhat.com/fom/ecos
> > > and search the list archive:
> http://sources.redhat.com/ml/ecos-discuss
> > 
> > 
> > 
> > --
> > Before posting, please read the FAQ:
> http://sources.redhat.com/fom/ecos
> > and search the list archive: 
> > http://sources.redhat.com/ml/ecos-discuss
> 



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

RE: [ECOS] gdb over ethernet network support for ECOS RAMapplication

[Gary Thomas]

On Tue, 2002-06-18 at 16:13, George Sosnowski wrote:
> Thanks for the replies they've been very inciteful. 
> I am running ecos that I download via anonymous CVS back in December.
> I've been afraid to get the 2.0 alpha code because I wasn't sure how
> much reconfiguration and lost changes there might be on my part.
> 

There would be few, if any, such impacts.  The version number belies
the code changes (they are major, but still incremental).  The main
reason for a major version number jump was the change in licensing.

> Does a gdb session have to be already established via network or serial
> before the RAM application runs? Or can one connect via gdb even after
> the application image is loaded and running? Showing my ignorance of
> gdb, if connected after the application image is running, can it still
> be debugged or does it have to be rerun?
> 

It is only possible to initiate a network GDB connection before the
program starts.  However, you can load and execute a program via a 
serial connection and later start up a serial GDB session, but not a
network one.

> On a somewhat related issue, can RAM applications somehow access the
> FIS? I have some fpga images that I want to store there and wasn't sure
> if there was an interface that provided the RedBoot functionality of
> lookup, create, load, etc.
> 

There's nothing to keep you from doing this, but alas, at this time 
there's not much to help you either.  The FIS directory is laid out so
that finding things should be straight forward, but there aren't any
support routines (or a supported API) for doing so.  Of course, if you
wanted to contribute such support, we'd be more than happy :-)

> Thanks again!
> 
> -----Original Message-----
> From: Gary Thomas [mailto:gary@chez-thomas.org] 
> Sent: Tuesday, June 18, 2002 11:30 AM
> To: George Sosnowski
> Cc: eCos Discussion
> Subject: RE: [ECOS] gdb over ethernet network support for ECOS
> RAMapplication
> 
> 
> On Tue, 2002-06-18 at 11:52, George Sosnowski wrote:
> > I was using a target based on powerpc mbx and viper boards which has 
> > an 860T.
> > 
> > The thing I'm not clear about is that my ECOS 1.3.1 application is 
> > using the NET package which is a fuller version IP stack than what 
> > Redboot has. Do these stacks run concurrently somehow? Or are the 
> > ethernet (fec) driver and IP stack in the ecos application inheriting 
> > the Redboot driver and stack?
> > 
> 
> Actually neither.
> 
> The network stacks are split into a logical and physical driver.  Which
> logical driver is in use depends on the mode; there is a separate driver
> for RedBoot than from an eCos application.  However, the physical driver
> is the same for both environments (or at least equivalent).  What
> happens is the physical driver in RedBoot is used until the eCos
> application takes over.  Once that happens, only the physical driver in
> the eCos application is used, but it gets shared by both the eCos stack
> (xxxBSD based) and the RedBoot stack.  When there is network activity
> (incoming packets primarily), both logical stacks get a chance to
> process the data/packet.  In this way, both the eCos stack and the
> RedBoot stack can run, more or less in tandem.
> 
> It's all rather complicated, but it does work, because of how the
> drivers are structured.
> 
> BTW - I assume you mean by 1.3.1 that you are using anonymous CVS,
> possibly before the 2.0 alpha was announced.  I would suggest that you
> update to the latest code base since there have been significant changes
> since 1.3.1 was officially relased *in March of 2000*!
> 
> > -----Original Message-----
> > From: Gary Thomas [mailto:gary@chez-thomas.org]
> > Sent: Tuesday, June 18, 2002 10:40 AM
> > To: George Sosnowski
> > Cc: eCos Discussion
> > Subject: Re: [ECOS] gdb over ethernet network support for ECOS
> > RAMapplication
> > 
> > 
> > On Tue, 2002-06-18 at 11:20, George Sosnowski wrote:
> > > I'm running RedBoot on my target (powerpc 860T based) from flash,
> > > which has both serial and network (TCP 9000) support for GDB. When 
> > > RedBoot loads an ECOS
> > > (v1.3) RAM
> > > application, what's the best way to configure the ecos ram
> application
> > 
> > > to have support/ maintain support for GDB over the network/ethernet
> > > (fec) , as well as serial?
> > >  
> > > >From what I understand it looks like RAM applications are only
> > > >supposed
> > > to inherit
> > > serial gdb functionality?  Although the Redboot documentation says
> > "ecos
> > > contains
> > > special network sharing code to allow for this situation". I didn't 
> > > notice anything at the ethernet (fec) or IP stack level. Have I 
> > > overlooked this?
> > >  
> > > One thought I had on doing this was to merge in the Redboot RAM
> > > functionality into
> > > my application.  This wouldn't maintain a gdb session over the
> network
> > > from the ROM
> > > Redboot, but would give gdb support over the network in RAM
> > application
> > > at least.
> > 
> > If you're running RedBoot from ROM, any network GDB connection will 
> > remain, even after the eCos application starts up.  One caveat is that
> 
> > RedBoot and your eCos application have to use unique IP addresses.  
> > This is normally done by giving RedBoot a static address and then 
> > letting the eCos application either use a different static address or 
> > get an address dynamically via DHCP.
> > 
> > Also note that once you start debugging via the network, the serial is
> 
> > no longer part of the GDB "path".  Your application can do things with
> 
> > it directly, e.g. by accessing it via the serial device drivers, but 
> > only the network will be used for GDB control and/or output.
> > 
> > What platform are you using (just for my information)?
> > 
> > 
> > --
> > Before posting, please read the FAQ:
> http://sources.redhat.com/fom/ecos
> > and search the list archive: http://sources.redhat.com/ml/ecos-discuss
> 
> 
> 
> -- 
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss



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

RE: [ECOS] gdb over ethernet network support for ECOS RAMapplication

[George Sosnowski]

Thanks for the replies they've been very inciteful. 
I am running ecos that I download via anonymous CVS back in December.
I've been afraid to get the 2.0 alpha code because I wasn't sure how
much reconfiguration and lost changes there might be on my part.

Does a gdb session have to be already established via network or serial
before the RAM application runs? Or can one connect via gdb even after
the application image is loaded and running? Showing my ignorance of
gdb, if connected after the application image is running, can it still
be debugged or does it have to be rerun?

On a somewhat related issue, can RAM applications somehow access the
FIS? I have some fpga images that I want to store there and wasn't sure
if there was an interface that provided the RedBoot functionality of
lookup, create, load, etc.

Thanks again!

-----Original Message-----
From: Gary Thomas [mailto:gary@chez-thomas.org] 
Sent: Tuesday, June 18, 2002 11:30 AM
To: George Sosnowski
Cc: eCos Discussion
Subject: RE: [ECOS] gdb over ethernet network support for ECOS
RAMapplication


On Tue, 2002-06-18 at 11:52, George Sosnowski wrote:
> I was using a target based on powerpc mbx and viper boards which has 
> an 860T.
> 
> The thing I'm not clear about is that my ECOS 1.3.1 application is 
> using the NET package which is a fuller version IP stack than what 
> Redboot has. Do these stacks run concurrently somehow? Or are the 
> ethernet (fec) driver and IP stack in the ecos application inheriting 
> the Redboot driver and stack?
> 

Actually neither.

The network stacks are split into a logical and physical driver.  Which
logical driver is in use depends on the mode; there is a separate driver
for RedBoot than from an eCos application.  However, the physical driver
is the same for both environments (or at least equivalent).  What
happens is the physical driver in RedBoot is used until the eCos
application takes over.  Once that happens, only the physical driver in
the eCos application is used, but it gets shared by both the eCos stack
(xxxBSD based) and the RedBoot stack.  When there is network activity
(incoming packets primarily), both logical stacks get a chance to
process the data/packet.  In this way, both the eCos stack and the
RedBoot stack can run, more or less in tandem.

It's all rather complicated, but it does work, because of how the
drivers are structured.

BTW - I assume you mean by 1.3.1 that you are using anonymous CVS,
possibly before the 2.0 alpha was announced.  I would suggest that you
update to the latest code base since there have been significant changes
since 1.3.1 was officially relased *in March of 2000*!

> -----Original Message-----
> From: Gary Thomas [mailto:gary@chez-thomas.org]
> Sent: Tuesday, June 18, 2002 10:40 AM
> To: George Sosnowski
> Cc: eCos Discussion
> Subject: Re: [ECOS] gdb over ethernet network support for ECOS
> RAMapplication
> 
> 
> On Tue, 2002-06-18 at 11:20, George Sosnowski wrote:
> > I'm running RedBoot on my target (powerpc 860T based) from flash,
> > which has both serial and network (TCP 9000) support for GDB. When 
> > RedBoot loads an ECOS
> > (v1.3) RAM
> > application, what's the best way to configure the ecos ram
application
> 
> > to have support/ maintain support for GDB over the network/ethernet
> > (fec) , as well as serial?
> >  
> > >From what I understand it looks like RAM applications are only
> > >supposed
> > to inherit
> > serial gdb functionality?  Although the Redboot documentation says
> "ecos
> > contains
> > special network sharing code to allow for this situation". I didn't 
> > notice anything at the ethernet (fec) or IP stack level. Have I 
> > overlooked this?
> >  
> > One thought I had on doing this was to merge in the Redboot RAM
> > functionality into
> > my application.  This wouldn't maintain a gdb session over the
network
> > from the ROM
> > Redboot, but would give gdb support over the network in RAM
> application
> > at least.
> 
> If you're running RedBoot from ROM, any network GDB connection will 
> remain, even after the eCos application starts up.  One caveat is that

> RedBoot and your eCos application have to use unique IP addresses.  
> This is normally done by giving RedBoot a static address and then 
> letting the eCos application either use a different static address or 
> get an address dynamically via DHCP.
> 
> Also note that once you start debugging via the network, the serial is

> no longer part of the GDB "path".  Your application can do things with

> it directly, e.g. by accessing it via the serial device drivers, but 
> only the network will be used for GDB control and/or output.
> 
> What platform are you using (just for my information)?
> 
> 
> --
> Before posting, please read the FAQ:
http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss



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

RE: [ECOS] gdb over ethernet network support for ECOS RAMapplication

[Gary Thomas]

On Tue, 2002-06-18 at 11:52, George Sosnowski wrote:
> I was using a target based on powerpc mbx and viper boards which has an
> 860T.
> 
> The thing I'm not clear about is that my ECOS 1.3.1 application is using
> the NET package which is a fuller version IP stack than what Redboot
> has. Do these stacks run concurrently somehow? Or are the ethernet (fec)
> driver and IP stack in the ecos application inheriting the Redboot
> driver and stack?
> 

Actually neither.

The network stacks are split into a logical and physical driver.  Which
logical driver is in use depends on the mode; there is a separate driver
for RedBoot than from an eCos application.  However, the physical driver
is the same for both environments (or at least equivalent).  What happens
is the physical driver in RedBoot is used until the eCos application takes
over.  Once that happens, only the physical driver in the eCos application
is used, but it gets shared by both the eCos stack (xxxBSD based) and the
RedBoot stack.  When there is network activity (incoming packets primarily),
both logical stacks get a chance to process the data/packet.  In this way,
both the eCos stack and the RedBoot stack can run, more or less in tandem.

It's all rather complicated, but it does work, because of how the drivers
are structured.

BTW - I assume you mean by 1.3.1 that you are using anonymous CVS, possibly
before the 2.0 alpha was announced.  I would suggest that you update to the
latest code base since there have been significant changes since 1.3.1 was
officially relased *in March of 2000*!

> -----Original Message-----
> From: Gary Thomas [mailto:gary@chez-thomas.org] 
> Sent: Tuesday, June 18, 2002 10:40 AM
> To: George Sosnowski
> Cc: eCos Discussion
> Subject: Re: [ECOS] gdb over ethernet network support for ECOS
> RAMapplication
> 
> 
> On Tue, 2002-06-18 at 11:20, George Sosnowski wrote:
> > I'm running RedBoot on my target (powerpc 860T based) from flash, 
> > which has both serial and network (TCP 9000) support for GDB. When 
> > RedBoot loads an ECOS
> > (v1.3) RAM
> > application, what's the best way to configure the ecos ram application
> 
> > to have support/ maintain support for GDB over the network/ethernet 
> > (fec) , as well as serial?
> >  
> > >From what I understand it looks like RAM applications are only 
> > >supposed
> > to inherit
> > serial gdb functionality?  Although the Redboot documentation says
> "ecos
> > contains
> > special network sharing code to allow for this situation". I didn't
> > notice anything at the
> > ethernet (fec) or IP stack level. Have I overlooked this? 
> >  
> > One thought I had on doing this was to merge in the Redboot RAM 
> > functionality into
> > my application.  This wouldn't maintain a gdb session over the network
> > from the ROM
> > Redboot, but would give gdb support over the network in RAM
> application
> > at least. 
> 
> If you're running RedBoot from ROM, any network GDB connection will
> remain, even after the eCos application starts up.  One caveat is that
> RedBoot and your eCos application have to use unique IP addresses.  This
> is normally done by giving RedBoot a static address and then letting the
> eCos application either use a different static address or get an address
> dynamically via DHCP.
> 
> Also note that once you start debugging via the network, the serial is
> no longer part of the GDB "path".  Your application can do things with 
> it directly, e.g. by accessing it via the serial device drivers, but 
> only the network will be used for GDB control and/or output.
> 
> What platform are you using (just for my information)?
> 
> 
> -- 
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss



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

RE: [ECOS] gdb over ethernet network support for ECOS RAMapplication

[George Sosnowski]

I was using a target based on powerpc mbx and viper boards which has an
860T.

The thing I'm not clear about is that my ECOS 1.3.1 application is using
the NET package which is a fuller version IP stack than what Redboot
has. Do these stacks run concurrently somehow? Or are the ethernet (fec)
driver and IP stack in the ecos application inheriting the Redboot
driver and stack?

-----Original Message-----
From: Gary Thomas [mailto:gary@chez-thomas.org] 
Sent: Tuesday, June 18, 2002 10:40 AM
To: George Sosnowski
Cc: eCos Discussion
Subject: Re: [ECOS] gdb over ethernet network support for ECOS
RAMapplication


On Tue, 2002-06-18 at 11:20, George Sosnowski wrote:
> I'm running RedBoot on my target (powerpc 860T based) from flash, 
> which has both serial and network (TCP 9000) support for GDB. When 
> RedBoot loads an ECOS
> (v1.3) RAM
> application, what's the best way to configure the ecos ram application

> to have support/ maintain support for GDB over the network/ethernet 
> (fec) , as well as serial?
>  
> >From what I understand it looks like RAM applications are only 
> >supposed
> to inherit
> serial gdb functionality?  Although the Redboot documentation says
"ecos
> contains
> special network sharing code to allow for this situation". I didn't
> notice anything at the
> ethernet (fec) or IP stack level. Have I overlooked this? 
>  
> One thought I had on doing this was to merge in the Redboot RAM 
> functionality into
> my application.  This wouldn't maintain a gdb session over the network
> from the ROM
> Redboot, but would give gdb support over the network in RAM
application
> at least. 

If you're running RedBoot from ROM, any network GDB connection will
remain, even after the eCos application starts up.  One caveat is that
RedBoot and your eCos application have to use unique IP addresses.  This
is normally done by giving RedBoot a static address and then letting the
eCos application either use a different static address or get an address
dynamically via DHCP.

Also note that once you start debugging via the network, the serial is
no longer part of the GDB "path".  Your application can do things with 
it directly, e.g. by accessing it via the serial device drivers, but 
only the network will be used for GDB control and/or output.

What platform are you using (just for my information)?


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