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
