Re: [ECOS] sharing the ethernet port for Redboot/GDB/diagnostics

[Gary Thomas <gary at mlbassoc dot com>]

On Fri, 2005-09-23 at 09:14 -0700, Andrew Voelkel wrote:
> I been confused for some time now about what facilities are available for
> sharing the Ethernet port, both (1) between redboot and an application, and
> (2) between different redboot activities, namely redboot command interaction
> and GDB debugging. 
> 
> The first issue confuses me because I don't understand the operation of
> virtual vectors well enough, I think. I'm assuming that a fully threaded
> application has to take over operation of the Ethernet and use it in an
> interrupt driven fashion, and somehow allow redboot to get in and do its
> thing too. If anyone who can shed some light on the mechanics of how all
> this works, I'd much appreciate it.
> 
> The second issue confuses me because the documentation is all spread out and
> I really don't understand what is being said as a result. From reading
> Massa's book, it sounds as if I should be able to set up redboot to use
> separate "channels" for redboot command interactions and gdb debugging. This
> certainly sounds like a good idea to me, and avoid the GDB "mangling" issue,
> which seems like something to avoid if one can. So I imagine a situation
> where one uses two different TCP/IP ports to accomplish this goal, and it
> makes good sense to me.
> 
> However, after reading the redboot docs, and trying to understand why the
> configuration options in Massa's book (which are still a little confusing)
> don't seem to correspond exactly to those that I see in configtool, I don't
> know how to do this. In fact, I don't even know whether it is possible.
> 
> In short, it is possible to use different TCP/IP port numbers for redboot
> command interaction and GDB operation? If so, how do I do it? Or do I have
> the whole model mixed up in my head.

RedBoot can only handle a single connection - this would be either
via a serial port or ethernet.  Once connected, that connection is
used exclusively until broken.  Similarly, RedBoot either operates
in command mode or in GDB mode.  Once in GDB mode, only GDB protocol
is used until a "return" command ($k) is sent.  This will then return
to the command mode.

In other words, you only get one way of talking to RedBoot.  Because
of this, only a single port is used to connect via ethernet, either
in command mode or in GDB mode.

As far as sharing the ethernet between RedBoot and an application, there
is some major magic going on under the covers.  It requires cooperation
between the network stack used by the application and RedBoot.  
Basically the way it works is when a packet arrives on the network
interface and RedBoot had a valid connection via ethernet when the
application started, then RedBoot is given a chance to look at the
packet before the application.  RedBoot can then process this if it
was destined for it (that's why separate IP addresses are used for
application code and RedBoot - it's simpler to determine if the 
packet belongs to RedBoot).  If the packet is not for RedBoot, it
gets handled by the normal network stack.  Network output packets
are handled synchronously (i.e. when RedBoot needs to send one out,
it simply pushes it through the driver), so this part of the sharing
is much simpler.


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


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